Post-quantum certificates issued through 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.

Rolling out

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.

Rolling out

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.

Rolling out

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.

Rolling out

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 across the cryptographic core, chain and operations tracks, each with its current status so scope is clear before work starts.

6 offerings

Cryptographic core

Issuance, transport and policy. Composite post-quantum certificates produced at issuance rather than retrofitted, and a declarative policy that governs 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.

Rolling out

Status: In service, with further capability in development.
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.

In development

Status: Built and in final engineering before release.
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.

Rolling out

Status: In service, with further capability in development.
Where it lives: sanctumsecops.io

Delivered within a Sanctum SecOps engagement.

Scryptorium and CygnusScrypt

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

Rolling out

Status: In service, with further capability in development.
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.

Rolling out

Status: In service, with further capability in development.
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.

Planned

Status: Designed and specified, on the product roadmap.
Where it lives: No public surface. Delivered inside an engagement.

Delivered within a Sanctum SecOps engagement.

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.

Rolling out

Status: In service, with further capability in development.
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.

Available

Status: In service today.
Where it lives: web3.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

Open timestamp receipts

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

Planned

Status: Designed and specified, on the product roadmap.
Where it lives: sanctumsecops.org

Delivered within a Sanctum SecOps engagement.

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.

Rolling out

Status: In service, with further capability in development.
Where it lives: web3.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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.

Rolling out

Status: In service, with further capability in development.
Where it lives: web3.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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.

Rolling out

Status: In service, with further capability in development.
Where it lives: web3.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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.

Rolling out

Status: In service, with further capability in development.
Where it lives: web3.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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.

Rolling out

Status: In service, with further capability in development.
Where it lives: web3.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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.

Planned

Status: Designed and specified, on the product roadmap.
Where it lives: web3.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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.

Available

Status: In service today.
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.

Available

Status: In service today.
Where it lives: sanctumsecops.net

Delivered within a Sanctum SecOps engagement.

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.

Available

Status: In service today.
Where it lives: sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

Sanctum Intel

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

Rolling out

Status: In service, with further capability in development.
Where it lives: sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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.

Available

Status: In service today.
Where it lives: support.sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

Enterprise Control Center

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

Available

Status: In service today.
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.

Rolling out

Status: In service, with further capability in development.
Where it lives: sanctumsecops.com

Delivered within a Sanctum SecOps engagement.

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