Post-quantum certificate issuance as an API

Platform

Five components, and the seams between them

One library implements the primitives. One control plane decides what may be issued. One overlay carries identity on the wire. One ledger records every state change. One storefront is how the whole thing is bought. Nothing here is a bundle of the others under a new name.

Enterprise arc 1.3.6.1.4.1.65953Key agreement ML-KEM-768Signature, level 5 ML-DSA-87Transport TLS 1.3

Control plane

Cygnus

The control plane. Every issuance, rotation and revocation in the estate is an operation Cygnus authorises and records.

Partial

What it is

Cygnus is the registration authority and policy engine in front of the certificate authorities. It holds the issuance profiles, decides whether a request satisfies the profile it names, and is the only component permitted to ask a CA for a signature. Tenants are isolated at the policy layer rather than by convention, which is the requirement written up in the multi-tenant PKI draft.

What it does

Holds issuance profiles as versioned policy and enforces them at request time, not at review time
Federates multi-tenant nodes over a composite trust channel rather than a shared bearer secret
Emits one record per state change, in the same vocabulary the API verbs use
Fronts classical, post-quantum and composite lineages through one issuance path

Composes Cygnus calls CygnetLib for every primitive, writes every state change to sanctum-chain, and is the component CygnetSSL orders through. QZT gets its node identities from it.

Transport overlay

QZT overlay

A quantum-safe zero-trust overlay in which identity is carried by the certificate rather than by the network position.

Partial

What it is

QZT terminates mutual authentication at the edge of each workload. A peer is trusted because it presents a composite certificate Cygnus issued under a named profile, not because it arrived from an address on a list. Rekeying is continuous and cheap by design — an overlay rekey is a sub-millisecond operation, which is what makes short-lived node identities practical rather than aspirational.

What it does

Mutual authentication on every connection, with the certificate as the sole identity claim
Continuous rekeying, so a stolen session key has a useful lifetime measured in seconds
TLS 1.3 with FIPS cipher suites end to end; no downgrade path exists to be negotiated
Per-workload policy, so a compromised node reaches only what its own certificate names

Composes QZT consumes identities Cygnus issues and primitives CygnetLib implements. It writes connection-authority events to sanctum-chain where an evidence trail is required.

Cryptographic library

CygnetLib

The cryptographic library every other component links against. One implementation, one validated module boundary.

Partial

What it is

CygnetLib is where ML-KEM, ML-DSA and SLH-DSA actually live, alongside the classical primitives a composite still needs. It exists so the estate has exactly one answer to "which implementation signed this" — a platform with four components and four crypto stacks has four validation boundaries and cannot state a FIPS posture at all.

What it does

FIPS 203 ML-KEM, FIPS 204 ML-DSA and FIPS 205 SLH-DSA behind one interface
Composite construction and parsing, so a composite is a first-class object rather than two certificates in a trench coat
Classical lineage: ECDSA P-256 and P-384, RSA-3072 and above, SHA-2 family digests, AES-256-GCM
Hardware key custody paths, so a private key can be generated in and never leave a validated module

Composes Everything links against it. CygnetLib depends on nothing else in the platform, which is the property that makes it the validation boundary.

Evidence ledger

sanctum-chain

An append-only evidence ledger. Every state change becomes a leaf; the tree head is signed on hardware and anchored to a public chain.

Running

What it is

A certificate proves a key was authorised. It does not say who ordered it, who approved it, or what changed afterwards. sanctum-chain is the record that does. Events are append-only at the database level rather than by policy, they accumulate into a Merkle tree, the tree head is signed by a key held on a hardware token, and the signed head is anchored daily to a public chain so the history is fixed in time against a witness the operator does not control.

What it does

Append-only event log with the tenant, the operation and the authorisation that justified it
Merkle accumulation, so any single event can be proven to belong without disclosing any other
Signed tree heads, signed by a P-256 key on hardware and failing closed when the token is absent
Daily anchoring to a public chain, with the anchor reference published for independent checking

Composes Cygnus, QZT and CygnetSSL all append to it. It reads nothing back into the issuance path, which is deliberate: an evidence layer that can influence the decision it is recording is not evidence.

Issuance and storefront

CygnetSSL

The purchasable surface: in-house quantum issuance, the ALBIREO composite, and a reseller storefront for the certificates the web runs on today.

Partial

What it is

CygnetSSL is how the platform is bought rather than deployed. It carries three lines on one storefront — quantum-safe issuance from the Sanctum hierarchy, the ALBIREO composite whose every state change lands on the evidence ledger, and resold DV, OV, EV, wildcard, multi-domain and signing certificates from the public CAs. A buyer who needs a certificate today and a composite next quarter does not need two vendors.

What it does

Quantum-safe issuance under the Sanctum profiles, including the CYGNET-L5-Triple composition
The ALBIREO composite under OID 1.3.6.1.4.1.65953.8.1, with evidence appended per state change
Reseller ordering, renewal, reissue and cancellation across DigiCert, Sectigo, GeoTrust, Thawte and RapidSSL
One order path and one evidence trail across both the resold and the in-house lines

Composes CygnetSSL orders through Cygnus for the in-house lines and through the partner API for resold ones. Both paths append to sanctum-chain, which is the only thing the two lines genuinely share.

Catalogue

22 offerings, 7 backed by a deposited work

22 offerings. Each one states what runs and what does not, in the catalogue's own words rather than a summary of them, because an offering shown without its status is the specific defect this catalogue exists to prevent. A line marked as not built is designed and specified and nothing more, and saying so here is cheaper than being found out later.

6 offerings

Cryptographic core

Issuance, transport and policy. Composite post-quantum certificates produced at issuance rather than retrofitted, and a declarative policy that gates them.

CygnetLib and Cygnet Provider

A cryptographic provider with native post-quantum primitives, so a composite certificate is what issuance produces by default rather than the output of a migration project.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Provider and library implemented. The hybrid X25519 + ML-KEM-768 suite still needs an OID under the Sanctum private enterprise arc; the candidate 1.3.6.1.4.1.65953.9.1 is not yet assigned, so composite artefacts are not wire-stable across implementations.
Where it lives: sanctumsecops.com

Implemented by a deposited work: CygnetLib Cryptographic LibraryPython · 20 source files · completed 2026 · claimant Brian Vicente

The cryptographic core the rest of the platform is built on: post-quantum key establishment, post-quantum signatures, and the two composite profiles that combine them with a classical algorithm so a certificate stays valid under either assumption.

ML-KEM key establishment at all three parameter sets
ML-DSA signatures at all three parameter sets
ECDSA over P-256 and P-384 for the classical half of a composite
SHA-2 family digests
The ALBIREO and CYGNET-L5-Triple composite profiles, addressable directly rather than assembled by the caller

FIPS 203FIPS 204FIPS 186-5FIPS 180-4CNSA 2.0

Implemented by a deposited work: Cygnus Cryptographic EngineGo and Shell · 159 source files · completed 2026 · claimant Brian Vicente

The compiled engine and its build harness: the performance-sensitive half of the cryptographic core, produced through a reproducible build that reports what it validated on the machine that built it.

Compiled implementations of the post-quantum primitives used at issuance
A build harness that validates each target and reports pass, fail or skip
Reproducible builds across the supported operating systems
A build report retained as evidence for the artefact produced

FIPS 203FIPS 204FIPS 205FIPS 140-3

Cygnus Foundry — cloud PKI

Certificate issuance as an API: one verb per operation, an offline root, intermediates under policy, and SCEP or ACME enrolment at the edge.

Blocked

What the status means: Code exists but a specific defect prevents it from performing its function.
Evidence: The service, routes and policy layer exist, but cygnus-cloud-pki cannot currently issue a certificate: certificates.py line 113 returns a placeholder PEM rather than signing a CSR. Until that is replaced the API answers, and the answer is not a certificate.
Where it lives: sanctumsecops.com

Implemented by a deposited work: Cygnus Foundry Cloud PKIPython · 39 source files · completed 2026 · claimant Brian Vicente

The multi-tenant certificate authority control plane: tenants, issuing profiles, enrolment and revocation, with identity federated to an external provider rather than held locally.

Tenant isolation with per-tenant issuing profiles
Certificate issuance, renewal and revocation lifecycle
Federated administrator identity through an external identity provider
Revocation status published for relying parties
Every lifecycle action recorded for later audit

RFC 5280RFC 6960FIPS 140-3FIPS 203FIPS 204

Implemented by a deposited work: Sanctum PKI StackGo and Shell · 102 source files · completed 2026 · claimant Brian Vicente

The deployable form of the certificate authority: the installer, service definitions and secret-management wiring that stand a hardened issuing stack up on customer-controlled infrastructure.

Repeatable installation onto a customer-controlled host
Secrets held in a dedicated secret manager rather than in configuration
Services defined so they restart into a known state
Host firewalling applied as part of the install

FIPS 140-3RFC 5280NIST SP 800-171

Sanctum AEGIS

A canonicalisation and tier compiler: policy in, deterministic DER and a resolved algorithm tier out, so two parties compiling the same policy get byte-identical artefacts.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Canonicaliser, DER encoder, OID registry, tier resolver and an intermediate-representation compiler at IR version 1 are implemented. Filed as a provisional under docket SANCTUM-AEGIS-PPA-2026-06-10; the non-provisional is not yet prepared.
Where it lives: sanctumsecops.io

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Scryptorium and CygnusScrypt

The policy language. One declarative document describes how an estate issues, gates, rotates and audits, and compiles to the configuration each component actually enforces.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Compiler and language implemented with a deterministic intermediate representation. The gap is authorship, not code: the standard library of policies an operator would start from is not written.
Where it lives: sanctumsecops.io

Implemented by a deposited work: CygnScrypt Compiler and RuntimePython · 34 source files · completed 2026 · claimant Brian Vicente

A compiler for a policy language in which cryptographic rules are written once and checked before anything is emitted. The compiler refuses to produce output when a blocking invariant fails, and there is deliberately no override.

Parses and validates policy source, reporting every violated invariant rather than the first
Refuses to emit when a blocking invariant fails, with no override path
Produces an intermediate representation plus the evidence for the decisions taken
Reports a cryptographic asset inventory drawn from the policy set
Produces a deterministic digest of the source it compiled

CycloneDX 1.5FIPS 203FIPS 204

Implemented by a deposited work: Scryptorium CompilerJavaScript · 5 source files · completed 2026 · claimant Brian Vicente

The browser-side compiler for the same policy language, so a policy can be authored and checked interactively before it is ever applied to a live trust store.

Compiles policy source in the browser with no server round trip
Reports violated invariants against the source as written
Ingests a cryptographic bill of materials as a policy input
Expresses live transport state as a policy predicate

CycloneDX 1.5IPFIXTLS 1.3

QZT — quantum-safe zero-trust overlay

A transport overlay where every peer holds an attested identity and a session is quantum-safe end to end, with an operator surface that shows each node sealed, attesting, warded or quelled.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Node runtime, control panel and the desktop tray are built; the panel renders live node state. ALBIREO handshake resumption is unimplemented at crates/qzt-node/src/runtime.rs line 435, so a dropped session renegotiates in full, and qzt-node does not yet expose GET /pulse.
Where it lives: qzt.sanctumsecops.com

Implemented by a deposited work: CygnduitZT TransportGo and Python · 53 source files · completed 2026 · claimant Brian Vicente

The zero-trust transport layer: authenticated, post-quantum protected channels between nodes, where a peer is admitted on a verified assertion about itself rather than on its position in the network.

Post-quantum protected channels between enrolled peers
Admission on a verified device and identity assertion, not on network location
Periodic re-establishment of channel keys
Policy enforced at the transport boundary

FIPS 203FIPS 204TLS 1.3CNSA 2.0

Sanctum LINK — attested enrolment

Device enrolment where the credential is bound to hardware at the moment of issue, so an enrolment record proves which device holds the key rather than which account requested it.

Not built

What the status means: Designed and specified. No implementation exists.
Evidence: Specified end to end, including the billing model where the successful enrolment is the billable event. No implementation exists.
Where it lives: No public surface. Delivered inside an engagement.

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

9 offerings

Chain and web3

An append-only evidence ledger and the settlement layer on top of it. Authority is a hardware signature; the chain records it and anyone can check the record.

sanctum-chain — evidence ledger

An append-only ledger of PKI events: OID provenance, hardware attestations and Merkle tree heads, with the append-only property enforced by the database rather than by convention.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Seven tables with an append-only trigger on the event table, a Merkle leaf store, signed tree heads and anchor records, on PostgreSQL behind a typed API. Verified against a real Postgres 18 instance: 356 tests pass, append-only triggers fire, and total supply is conserved on every path. Signed-tree-head signing fails closed when the YubiKey is absent, which means a cloud deployment produces no signatures at all rather than weak ones — correct, and a deployment constraint worth stating. The hardening sits on an unmerged branch, so the default branch still carries the older behaviour.
Where it lives: web3.sanctumsecops.com

Implemented by a deposited work: Cygnus ConvergencePython · 30 source files · completed 2026 · claimant Brian Vicente

The decision and evidence layer that ties the rest together: it classifies the cryptographic posture it observes, decides what level of access that posture earns, and writes the decision into an append-only log whose contents can be proved to a third party.

Classifies signature and transport posture from observed state
Derives an access level from that posture and records why
Appends every decision to a verifiable log
Produces inclusion and consistency proofs over that log
Assembles a control-mapped compliance pack from the recorded evidence

RFC 6962RFC 9162NIST SP 800-171FIPS 204

Anchoring and proof of existence

Periodic publication of a signed tree head to a public chain, so a record held privately can still be shown to have existed at a point in time.

Live

What the status means: Running in production and reachable today.
Evidence: Deployed and exercised on Sanctum PEN, chain 65953. YSTPAnchor is at 0x606f5b677234d5d912ac8fcda4db3bccb1611515, carrying 3,653 runtime bytes — the deployed code length matches the compiled size exactly — and it verifies the YubiKey P-256 signature on-chain through the P256VERIFY precompile standardised in RIP-7212 and EIP-7951, so authority rests in the signature and not in the sending account. The precompile was probed on the live chain before deployment and returns empty on invalid input, which is the specified behaviour. The authority key is registered: P-256 on YubiKey serial 37290121, PIV slot 8E, transaction status 0x1 in block 72,737, and getKey reads back active. The contract confirms SANCTUM_PEN as 65953, agreeing with the 1.3.6.1.4.1.65953 arc. Read-back rather than receipt: owner, SANCTUM_PEN and getKey were all queried after the fact. What is still not true is external checkability — the RPC does not answer from outside the perimeter, so a reader cannot repeat these calls. Anchor cadence stays once per 24 hours by design: anchoring costs roughly 66 ms against 0.50 ms for a rekey, a 177-fold ratio that argues for infrequent anchors and frequent rekeys.
Where it lives: web3.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Open timestamp receipts

Free, open, verifiable timestamping whose receipts a third-party client can check without contacting Sanctum at all.

Not built

What the status means: Designed and specified. No implementation exists.
Evidence: No receipt serialisation exists anywhere in the codebase; the format is named in two README files and nowhere else. Compatibility with standard clients is not claimed and will not be claimed until a receipt produced here verifies in one.
Where it lives: sanctumsecops.org

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

SCN — settlement and tokenomics

The unit that meters chain work: a mint schedule with halving, vesting with a cliff, burn on consumption, governance weight, and a multi-signature treasury.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Mint, vesting, burn, governance voting and treasury modules are implemented and covered by the suite. The two defects previously published here — conflicting 002 migrations, and contract execution committing partial state — are both fixed and regression-tested on a branch that has not been merged. The on-chain unit is deployed: SanctumCoinX at 0xfedd5a48895eca9d7ad1a637ee7db2d8d4266d52 on chain 65953, an 8-decimal ERC-20 with a one-billion cap and a YubiKey-gated bridge-in, 5,391 runtime bytes on chain against 5,391 compiled. It reads back symbol SCNX, 8 decimals, and its anchor bound to the deployed YSTPAnchor. The off-chain mint schedule, vesting and treasury modules that meter it remain on an unmerged branch, which is why this is partial rather than live.
Where it lives: web3.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Deterministic contract execution

Contracts expressed as a typed intermediate representation and executed by a deterministic interpreter with gas metering, so the same input yields the same state transition everywhere.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Interpreter, gas accounting and the state model are implemented, and the execution path has been rewritten to run inside one Postgres transaction: the contract row and every reachable balance row are locked in sorted order, the engine runs copy-on-write, and on failure no state and no contract-driven ledger movement commits while the payer still pays for gas consumed. Nine defects were fixed, one critical — a threshold condition that did not deduplicate signatures by address, letting a single signer satisfy an N-of-M rule by replaying one signature. 58 regression tests plus 30 against real Postgres. All of it is still on an unmerged branch, which is the gap: the on-chain suite this meters is deployed on chain 65953, the interpreter that meters it is not merged.
Where it lives: web3.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Attested collectibles

Non-fungible records whose provenance is a hardware attestation in the ledger rather than a claim in metadata, with collections, transfers and listings.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Collections, tokens, transfers and marketplace listings exist in schema and routes, and the on-chain pair is deployed: SanctumComposites at 0x11620f6a2f092d062ef8efed6cec0736237a52f3, an ERC-721 with ERC-2981 royalties and immutable provenance, 7,518 runtime bytes, reading back symbol SCOMP; and SanctumMarketplace at 0x7f277208a180dce0bc89d86d5e9ba55831ef6604, 5,203 bytes, with paymentToken bound to the deployed SCNX and a protocol fee of 250 basis points against a contract cap of 1,000. What keeps this partial is not the code: no collection has been issued, and the treasury, validator and staker sinks all still point at the deployer address, so the split is nominal until they are separated.
Where it lives: web3.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Chain as a service

A tenant gets its own ledger with its own anchor schedule and fee policy, metered per transaction with a monthly floor, across three tiers.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Tenant provisioning, per-tenant usage accounting, the fee schedule and the three tiers are implemented. The tenant dashboard single sign-on is forgeable as written: the token is verified against an environment variable that defaults to the empty string, which lets anyone mint a valid session for any tenant. That must be fixed before a tenant is onboarded.
Where it lives: web3.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Validator set and reputation

A recorded validator set with per-validator reputation, so the question of who attested to a block has a durable answer.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Validator set, reputation scoring and block records are implemented. The set is not distributed: it runs as a single operator today, which means the reputation model is instrumentation rather than consensus.
Where it lives: web3.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Machine-payable verification

A verification call an autonomous agent can pay for with no signup, no API key and no prior relationship, so the client stays open-source while the call is still billed.

Not built

What the status means: Designed and specified. No implementation exists.
Evidence: The commercial design is settled — bill the successful verification, keep the client permissively licensed — and the payment rails exist externally. Nothing is wired up on the Sanctum side.
Where it lives: web3.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

7 offerings

Operations and compliance

The practice that funds the platform: migration readiness, assessment evidence, monitoring and response, delivered vendor-agnostically.

Post-quantum migration readiness

Cryptographic asset inventory, a bill of materials for what your estate actually uses, harvest-now-decrypt-later exposure, and a sequenced migration plan against the federal deadlines.

Live

What the status means: Running in production and reachable today.
Evidence: Delivered as an engagement today. This is the offering that Executive Order 14412 and OMB M-26-15 turned from advisory work into a dated obligation, including a cryptographic bill of materials whose stated purpose is automated assessment of cryptographic assets.
Where it lives: sanctumsecops.com

Implemented by a deposited work: Sanctum PQC ValidatorPython · 2 source files · completed 2026 · claimant Brian Vicente

A validation harness that checks post-quantum certificate artefacts against their specifications and produces a reviewer-facing report, deliberately reduced to pass or fail by artefact so that publishing the report discloses nothing about the environment that produced it.

Validates artefacts by kind and reports pass or fail per artefact
Separates the reviewer-facing report from the complete diagnostic record
Strips environment context, temporary paths and diagnostic detail from the published form
Emits both a machine-readable and a human-readable report

FIPS 203FIPS 204FIPS 205RFC 5280

NIST SP 800-171 assessment evidence

Control-by-control traceability from requirement to artefact to owner, built so a self-assessment score is defensible rather than asserted.

Live

What the status means: Running in production and reachable today.
Evidence: Delivered as an engagement. Repositioned in July 2026: with third-party certification suspended and self-assessment against NIST SP 800-171 Revision 2 the operative requirement, the deliverable is the evidence index rather than assessor readiness.
Where it lives: sanctumsecops.net

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Fractional CISO

A risk register that is maintained rather than produced once, board-legible reporting on a fixed cadence, and the quick wins identified before the roadmap.

Live

What the status means: Running in production and reachable today.
Evidence: Delivered on retainer today. The register, the reporting cadence and the insurance-readiness review are all manual work product; none of it is generated from the platform yet, so the engagement scales with hours rather than with software.
Where it lives: sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Sanctum Intel

Continuous vulnerability triage against your actual inventory: advisories in, prioritised and ticketed work out, with exploitation likelihood weighed rather than severity alone.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Sources and scoring are defined and the ticketing integration is designed. The poller that closes the loop from advisory to ticket is not yet deployed, so triage runs on request rather than continuously.
Where it lives: sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Service desk and MDR triage

Ten queues with per-queue automation ceilings, where incident response and detection queues assist a human and never resolve on their own.

Live

What the status means: Running in production and reachable today.
Evidence: Running on a hosted desk with ten queues, ten seats and published resolution targets. The two security queues are deliberately capped at zero automated resolution: a human signs every incident.
Where it lives: support.sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Enterprise Control Center

One operator surface for the whole estate: node inventory and enrolment, tunnel state, certificate expiry, desk load and the fault register.

Live

What the status means: Running in production and reachable today.
Evidence: Deployed and serving. Node deployment from the console is the next capability and is not yet wired.
Where it lives: ecc.sanctumsecops.com

Implemented by a deposited work: Cygnary Control PlanePython and TypeScript · 186 source files · completed 2026 · claimant Brian Vicente

The operator console for the estate: the administrative surface through which tenants, certificates, nodes and evidence are inspected and acted on, with access decided by the identity layer at the edge rather than by the application.

Administrative surface over tenants, certificates and nodes
Access decided by an edge identity layer, verified per request
Falls back to an application session only where the edge assertion is absent
Operator actions recorded as auditable events

OIDCJWTFIPS 140-3

Endpoint and device operations

Remote monitoring, patch state and mobile device management extended from the same policy that governs issuance, rather than a separate tool with a separate truth.

Partial

What the status means: Implemented and exercised by tests, with a named gap that is not yet closed.
Evidence: Enablement is in place on the managed platform and device enrolment works. The join to Sanctum policy is not built, so today it is a competent RMM rather than a control-plane extension.
Where it lives: sanctumsecops.com

No deposited software work names this offering. That is a statement about the registration record, not about the status above.

Composition

How the five fit together

Read bottom-up. The interesting claim in a platform is never the component list; it is what crosses each boundary and what deliberately does not.

Seams
From	To	What crosses
CygnetLib	Cygnus	Primitives and composite construction. Cygnus never implements a primitive itself, so the validated module boundary stays in one place.
Cygnus	QZT	Node identities as composite certificates under a named profile. QZT trusts the certificate, never the address it arrived from.
Cygnus	CygnetSSL	The in-house issuance path. The storefront places an order; the control plane decides whether the profile permits it.
Cygnus, QZT and CygnetSSL	sanctum-chain	One append per state change. The ledger is write-only from the platform side and readable by anyone.
sanctum-chain	A public chain	A signed tree head, once every twenty-four hours, so provenance survives the operator disappearing.

One direction is missing on purpose: the ledger never reads back into the issuance decision. An evidence layer that can influence what it is recording is not evidence.

Composite issuance profile — as issued by Cygnus

{
  "profile":   "albireo-composite",
  "oid":       "1.3.6.1.4.1.65953.8.1",
  "kem":       ["ML-KEM-768", "ML-KEM-512"],
  "classical": "ECDSA-P-384",
  "issued_by": "cygnus",
  "evidence":  "sanctum-chain:append per state change"
}

Boundaries

What the platform deliberately does not do

A platform page that lists only capabilities is a brochure. These are the constraints an operator will hit.

One validated module, not four

Every component links against CygnetLib rather than carrying its own cryptographic implementation. That is a constraint as much as a design: a component cannot adopt a primitive the library does not implement, and it does not get to make an exception under deadline pressure.

The benefit is that the FIPS posture is a property of one boundary. Four stacks would mean four boundaries and no single answer to which implementation signed a given artifact.

Evidence fails closed

Signed tree heads are signed by a key on hardware. When the token is absent, no signature is produced — the ledger does not fall back to a software key so the pipeline can keep moving. That is the correct failure direction, and it is a real deployment constraint: a cloud-only deployment currently produces no signed heads at all.

Take the profile, not the platform

Adoption starts with one issuance profile rather than a deployment. Send what you issue today; you get back the composite lineage that replaces it and the order to cut over in. Service shapes are on the services page.

Send a profile API reference