Sanctum SecOps
Documented interface — issuance not yet live

Post-quantum certificates, issued by an API call

Composite certificates at issuance rather than as a migration project. One endpoint per operation, one verb per state change, and an evidence record for every one of them. Built for the platform team that already has post-quantum on the roadmap and no appetite for a two-year programme.

Request API accessRead the API reference
Signature ML-DSA-65Key agreement ML-KEM-768Classical lineage ECDSA P-384Transparency RFC 6962
POST /v1/min — min certificate
curl -X POST https://api.sanctumsecops.io/v1/min \
  -H "X-API-Key: $SANCTUM_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "profile": "tls-server-composite",
    "subject":  { "cn": "edge-07.internal" },
    "lineage":  ["ecdsa-p384", "ml-dsa-65"],
    "validity": "P90D"
  }'

Positioning

Three pillars, in the order the pressure arrives

Lifecycle automation first, because the maximum validity of a publicly trusted TLS certificate is already falling on a published schedule. Post-quantum readiness second. Signed evidence third, on the hooks that are actually enforceable.

01

Certificates now expire faster than anyone renews them by hand

Certificate lifecycle automation

The maximum life of a public TLS certificate is 200 days today and 47 days by March 2029 — roughly 7 renewals a year, per certificate. We automate enrollment, inventory and expiry so that stops being a person's job.

  • ACME enrollment against your existing CAs, so renewal is a scheduled event and not a ticket
  • A certificate inventory that finds what is already deployed, including the certificates nobody documented
  • Expiry monitoring with lead time measured against the ladder in force, not against a 398-day habit
  • Reissue, rekey and revocation through one interface across every CA on the shelf
02

Know what cryptography you run before you are asked to replace it

Post-quantum readiness

A cryptographic inventory and a migration position aligned to CNSA 2.0 and the FIPS 203, 204 and 205 algorithms — with composite issuance available where the requirement is already live.

  • Cryptographic asset inventory: algorithms, key sizes, certificate profiles and where each one terminates
  • Harvest-now-decrypt-later exposure review across the traffic that has to stay confidential for years
  • CNSA 2.0 and FIPS 203 / 204 / 205 alignment, stated per system rather than as a programme
  • Composite issuance — ML-KEM with a retained classical signature line — so classical lineage survives migration
03

Signed SBOM and attestation artifacts, on the hooks that are enforceable

Evidence add-on

Signed SBOM and attestation artifacts attached to the certificate and migration work above — driven by CRA Annex I, FD&C Act 524B, and whatever your contract actually says, and producible as the CISA form when an agency asks for it.

  • SBOM in a commonly used machine-readable format, signed, regenerated per release
  • Attestation artifacts mapped to the CISA Secure Software Development Attestation Form, ready when an agency requests them
  • CRA Annex I Part II(1) component documentation for products sold into the EU
  • FD&C Act 524B(b)(3) submission material for cyber devices
  • Every artifact appended to the sanctum-chain evidence ledger, so provenance is checkable rather than asserted
Maximum validity for a publicly trusted TLS certificate
EffectiveMaximum daysStatus
2025-03-15398superseded
2026-03-15200in force
2027-03-15100scheduled
2029-03-1547scheduled

In force today: 200 days. 47 days is the 2029 endpoint, not the cap today — at that point a single certificate needs 7 renewals a year, which is why enrolment has to be automated rather than diarised. Source: CA/Browser Forum ballot SC-081v3 — https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Where SBOM and attestation obligations actually come from
InstrumentForceWhen it applies to you
EU Cyber Resilience Act — Regulation (EU) 2024/2847, Annex I Part II(1)regulationSelling a product with digital elements into the EU. Full application 11 December 2027.
FD&C Act section 524B(b)(3)statuteCyber device submissions under 510(k), De Novo, PMA, PDP or HDE. In force since 29 March 2023.
Contract-specific termscontractAny engagement whose terms name it. This is where most SBOM obligations actually come from.
CISA Secure Software Development Attestation Form (OMB M-22-18, M-23-16)agency-conditionSelling covered software to a federal agency. Form released 11 March 2024.

Each row is an instrument that names the artifact, or a contract that does. There is no general United States requirement to produce an SBOM; the evidence pillar is scoped to the hooks above and to producing an artifact on request.

Platform

Eight services, one issuance path

Each service pairs a delivery engagement with the product that carries it. Nothing here is a bundle of the others under a new name.

Vendor agnostic
01 — Cygnus PQC PKI/PKE/RA/SSL Foundry

Post-Quantum PKI & Certificate Authority Design

A certificate authority you call over HTTP. Classical, post-quantum and composite lineages from one issuance path.

02 — Convergence

PQC Readiness Assessment & Audit Evidence

An inventory of what your estate signs with today, and the order in which to move it. Evidence produced as artifacts, not slides.

03 — Cygnet

Hardware-Rooted Composite Certificates

Keys generated and held in hardware, with the composite certificate bound to the device that will use it.

04 — QuantaScript

Compliance Policy as Code

Certificate and key policy expressed as code, versioned in your repository and enforced at issuance.

05 — Sanctum Standards

Cryptographic Standards & Spec Review

Review of a protocol, profile or migration plan by the people who write the drafts.

06 — Sanctum Orchestrate

Security Operations Automation

Renewal, rotation and revocation as scheduled operations rather than incidents.

07 — Sanctum Endpoint

PQC-Native Endpoint & Device Management

Enrollment and lifecycle for devices whose certificates are post-quantum from first boot.

08 — Sanctum Edge qZT

Zero-Trust Edge Architecture

Mutual authentication at the edge, with identity carried by the certificate rather than by the network.

Workflow

Five calls from profile to evidence

The operational lexicon is the API surface. Each step below is one endpoint, and the sequence is the same in the console, the logs and the audit record.

  1. forge — POST /v1/forge

    Build or derive a deployable configuration or package.

  2. min — POST /v1/min

    Issue a new cryptographic artifact that carries its own identity.

  3. cast — POST /v1/cast

    Deploy an already-built artifact to a target.

  4. seal — POST /v1/seal

    Finalize an approved result and preserve its verified state.

  5. trace — GET /v1/trace

    Collect the bounded operational evidence for an action.

Why the verbs are fixed

Every state transition an operator can cause has exactly one verb, so the console label, the route name and the log line are the same word. That is what makes an issuance reconstructable a year later.

Removal and disclosure are never a bare DELETE. burn, unward and unveil are POST, so each request carries the authorization and the reason that justified it.

API surface

One verb per operation

A representative slice of the operational lexicon. The complete vocabulary, with the disambiguation rules, is published with the API reference.

Typed source
Commercial API verbs
VerbWhat it doesMethodRouteAuthorization recorded
MINIssue a new cryptographic artifact that carries its own identity.POST/v1/min—
FORGEBuild or derive a deployable configuration or package.POST/v1/forge—
CASTDeploy an already-built artifact to a target.POST/v1/cast—
SEALFinalize an approved result and preserve its verified state.POST/v1/seal—
WARDApply or enforce a security boundary or policy.POST/v1/ward—
BURNRevoke or permanently retire an object.POST/v1/burnRequired
PULSEReal-time status, health or reachability check.GET/v1/pulse—
TRACECollect the bounded operational evidence for an action.GET/v1/trace—

Table and route strings are generated from the same typed package the server imports, so this page cannot drift from the implementation.

Start with an issuance profile, not a migration plan

Send the certificate profile you issue today. We return the composite lineage that replaces it and the order in which to cut over.

Send a profile+1 (607) 378-8287