Post-quantum certificate issuance as an API

Services

Six engagements, each one measured by the artifact it leaves behind

Every line below states what is in scope, what is handed over when it closes, and what it is not. Engagements are bought in one of four shapes and the shape is named on each entry; the commercial mechanics are on the pricing page. Nothing here is priced on this site.

Post-quantum migration

An inventory of every place your estate signs, agrees a key or pins a trust anchor, and a sequenced plan to move each one to ML-KEM, ML-DSA and SLH-DSA without a flag day.

Fixed-scope project

Scope

Cryptographic inventory across TLS termination, service mesh, code signing, device enrolment and internal CA hierarchies
Per-asset classification against FIPS 203, 204 and 205, and against the CNSA 2.0 federal baseline
Dependency ordering: what has to move before what, and which cutovers can run concurrently
Composite lineage design so a classical and a post-quantum key travel in one certificate through the migration window
Rollback design for every cutover, since a migration without a reverse path is a change freeze in disguise

Delivered

A machine-readable inventory, one row per signing or key-agreement surface, keyed by hostname and by certificate serial
A sequenced migration plan with the dependency graph, not a phase-numbered slide
Composite issuance profiles ready to load into the issuing CA
A gap register naming each asset that cannot move yet and the specific reason

Carried by Convergence. This engagement does not run your cutovers for you. It produces the inventory, the profiles and the order; execution is either your platform team or a separate retained engagement.

PKI and certificate lifecycle

Certificate authority design, issuance policy, and the automation that makes renewal a scheduled operation rather than an outage postmortem.

Fixed-scope project

Scope

Root and issuing CA hierarchy design, including offline root ceremony scripting and hardware key custody
Certificate policy and certification practice statement drafted against the profiles you actually issue
Issuance profiles expressed as code and enforced at the CA rather than reviewed in a ticket
Renewal, rotation, reissue and revocation automation, with revocation distribution and status responder placement
Multi-tenant isolation where one CA serves more than one organisation

Delivered

Signed CA hierarchy with documented key custody and a witnessed ceremony record
Certificate policy and CPS as versioned documents under your OID arc
Issuance profiles in the policy-as-code format, in your repository
A lifecycle runbook naming the operation, the verb, the authorisation required and the record it writes

Carried by Cygnus PQC PKI/PKE/RA/SSL Foundry. A hierarchy we design and hand over is yours to operate. Where you would rather not operate it, the monitoring retainer covers the running CA instead.

CMMC readiness

Practice-by-practice readiness against CMMC 2.0 Level 2, with the evidence produced as artifacts a C3PAO can read rather than as an assertion in a spreadsheet.

Fixed-scope project

Scope

Scoping: which enclaves handle controlled unclassified information and which are carved out, written down before any assessment work starts
Practice-by-practice assessment against the 110 NIST SP 800-171 requirements in the Level 2 set
System security plan and plan of action and milestones, drafted rather than reviewed
Cryptographic practices assessed against FIPS-validated module use, which is where most engineering-led organisations actually fail
Evidence collection wired to the systems that generate it, so the evidence is current on the day of assessment

Delivered

A scoping document with the enclave boundary drawn and justified
A per-practice assessment with the finding, the evidence reference and the residual gap
A system security plan and a POA&M with owners and dates
An evidence index mapping each practice to the artifact that satisfies it

Carried by Convergence. Sanctum is not an authorised third-party assessment organisation and does not certify. This engagement prepares you for an assessment somebody else conducts, and says plainly where you would fail one today.

Fractional CISO

A named security executive on retainer: architecture decisions, vendor and customer security review, board and audit reporting, and ownership of the risk register.

Retainer

Scope

Ownership of the risk register, with severity assigned by consequence rather than by discomfort
Architecture review authority on changes that touch identity, cryptography or the trust boundary
Customer security questionnaires, vendor assessments and diligence responses answered by the person accountable for the answer
Board and audit committee reporting on a fixed cadence
Standing incident authority, so escalation does not begin with finding out who decides

Delivered

A maintained risk register with a named owner and a named action per entry
Architecture decision records for every reviewed change
A reporting pack per cadence period, written for the audience that receives it
A completed and maintained security questionnaire corpus you can reuse per deal

Carried by Sanctum Standards. This is an executive engagement, not staff augmentation. It does not include implementation hours; those are scoped as their own project.

Incident response

Retained response for cryptographic and identity incidents: key compromise, mis-issuance, CA compromise, credential exposure and certificate-driven outage.

Retainer

Scope

Pre-agreed engagement terms and contact path, so an incident does not start with a procurement conversation
Containment for key and credential compromise, including emergency revocation and re-issuance at scale
Mis-issuance investigation: what was issued, under what authority, and to whom it was presented
Forensic reconstruction from issuance records and the evidence ledger where one is in place
Written post-incident report with the timeline, the root cause and the specific control that failed

Delivered

A signed retainer with a named contact path and agreed severity definitions before the incident
An incident timeline reconstructed from records rather than from recollection
A revocation and re-issuance record covering every affected subject
A post-incident report naming the failed control and the change that closes it

Carried by Sanctum Orchestrate. Response covers the cryptographic and identity blast radius. Endpoint forensics, legal notification and insurer negotiation stay with your existing providers, and we coordinate rather than replace them.

MSSP monitoring

Continuous monitoring of the certificate and identity estate: expiry, unexpected issuance, revocation status, policy drift and trust-anchor change.

Retainer

Scope

Expiry and renewal monitoring across every issuing hierarchy and every external CA in use
Unexpected-issuance detection against certificate transparency and against your own issuance records
Revocation status monitoring, including responder availability and distribution point freshness
Policy drift detection: a certificate issued outside its declared profile is an alert, not a report line
Trust-anchor change detection across managed fleets and enrolment paths

Delivered

A monitored inventory kept current by the monitoring itself rather than by a quarterly re-survey
Alerting into your existing on-call path with the severity definitions agreed at onboarding
A recorded monthly posture summary, dated, with the drift and expiry position stated as of that date
An escalation path into the retained incident response engagement where one is held

Carried by Sanctum Endpoint. This is monitoring of the cryptographic estate, not a general security operations centre. Network and endpoint detection stay with whoever runs them today.

Mapping

Which product carries which service

The eight service lines of record, each paired with the product that delivers it. An engagement above is a commercial shape over one or more of these; it is not a ninth product.

Service to product mapping
#	Service	Product	What it is
01	Post-Quantum PKI & Certificate Authority Design	`Cygnus PQC PKI/PKE/RA/SSL Foundry`	A certificate authority you call over HTTP. Classical, post-quantum and composite lineages from one issuance path.
02	PQC Readiness Assessment & Audit Evidence	`Convergence`	An inventory of what your estate signs with today, and the order in which to move it. Evidence produced as artifacts, not slides.
03	Hardware-Rooted Composite Certificates	`Cygnet`	Keys generated and held in hardware, with the composite certificate bound to the device that will use it.
04	Compliance Policy as Code	`QuantaScript`	Certificate and key policy expressed as code, versioned in your repository and enforced at issuance.
05	Cryptographic Standards & Spec Review	`Sanctum Standards`	Review of a protocol, profile or migration plan by the people who write the drafts.
06	Security Operations Automation	`Sanctum Orchestrate`	Renewal, rotation and revocation as scheduled operations rather than incidents.
07	PQC-Native Endpoint & Device Management	`Sanctum Endpoint`	Enrollment and lifecycle for devices whose certificates are post-quantum from first boot.
08	Zero-Trust Edge Architecture	`Sanctum Edge qZT`	Mutual authentication at the edge, with identity carried by the certificate rather than by the network.

The mapping is generated from the same typed module the home page renders, so the two cannot drift. Product detail is on the platform page.

Build status

Every line below carries its build status.

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 lines

Cryptographic core

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

Cryptographic core: status and evidence per offering
Offering	Status	Evidence for that status	Implementation
CygnetLib and Cygnet Providercygnetlib	Partial	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.	CygnetLib Cryptographic LibraryPython · 20 source files · deposited 2026Cygnus Cryptographic EngineGo and Shell · 159 source files · deposited 2026
Cygnus Foundry — cloud PKIfoundry	Blocked	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.	Cygnus Foundry Cloud PKIPython · 39 source files · deposited 2026Sanctum PKI StackGo and Shell · 102 source files · deposited 2026
Sanctum AEGISaegis	Partial	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.	No deposited work names this line
Scryptorium and CygnusScryptscryptorium	Partial	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.	CygnScrypt Compiler and RuntimePython · 34 source files · deposited 2026Scryptorium CompilerJavaScript · 5 source files · deposited 2026
QZT — quantum-safe zero-trust overlayqzt	Partial	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.	CygnduitZT TransportGo and Python · 53 source files · deposited 2026
Sanctum LINK — attested enrolmentlink	Not built	Specified end to end, including the billing model where the successful enrolment is the billable event. No implementation exists.	No deposited work names this line

9 lines

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.

Chain and web3: status and evidence per offering
Offering	Status	Evidence for that status	Implementation
sanctum-chain — evidence ledgerledger	Partial	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.	Cygnus ConvergencePython · 30 source files · deposited 2026
Anchoring and proof of existenceanchor	Live	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.	No deposited work names this line
Open timestamp receiptsots	Not built	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.	No deposited work names this line
SCN — settlement and tokenomicsscn	Partial	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.	No deposited work names this line
Deterministic contract executioncontracts	Partial	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.	No deposited work names this line
Attested collectiblescollectibles	Partial	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.	No deposited work names this line
Chain as a servicecaas	Partial	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.	No deposited work names this line
Validator set and reputationvalidators	Partial	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.	No deposited work names this line
Machine-payable verificationx402	Not built	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.	No deposited work names this line

7 lines

Operations and compliance

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

Operations and compliance: status and evidence per offering
Offering	Status	Evidence for that status	Implementation
Post-quantum migration readinesspqc-readiness	Live	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.	Sanctum PQC ValidatorPython · 2 source files · deposited 2026
NIST SP 800-171 assessment evidenceassessment	Live	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.	No deposited work names this line
Fractional CISOvciso	Live	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.	No deposited work names this line
Sanctum Intelintel	Partial	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.	No deposited work names this line
Service desk and MDR triagedesk	Live	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.	No deposited work names this line
Enterprise Control Centerecc	Live	Deployed and serving. Node deployment from the console is the next capability and is not yet wired.	Cygnary Control PlanePython and TypeScript · 186 source files · deposited 2026
Endpoint and device operationsendpoint	Partial	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.	No deposited work names this line

All 22 lines are listed, in the order the catalogue holds them. Nothing is filtered by status and nothing is reordered to lead with the working ones. The same dataset renders on the platform page in expanded form.

How an engagement starts

Three steps before anything is signed

Scoping is unpaid and produces a written boundary. A quote against an unwritten scope is a number nobody can hold either party to.

Send the profile, not the problem statement

The fastest scoping input is the certificate profile you issue today, or the list of hostnames and device classes you have to cover. It says more in one file than a discovery call says in an hour.

We return a written boundary

A scope document naming what is inside, what is outside, what has to exist on your side before work starts, and which capabilities the engagement depends on that are not yet built.

The quote is written against that boundary

One engagement shape, one scope document, one number. Changing the scope changes the quote, which is the point of writing the scope down first.

Scope the engagement before pricing it

Send the certificate profile, the hostname inventory or the assessment scope you are working against. You get a written boundary back, and a quote against that boundary.

Start scoping +1 (607) 378-8287