When "we'll migrate later"
isn't an option.
Trust infrastructure for procurement-shaped buyers. FIPS 140-3 compliant cryptography. Post-quantum-ready CA ceremony today. On-premises deployment. The compliance posture you need stated explicitly, with no asterisks.
Stated explicitly. Verifiable in code.
For procurement evaluators reviewing trust infrastructure, "FIPS compliant" can mean a dozen different things. Here is exactly what Cyphrs ships.
Cryptographic baseline
FIPS 140-3 compliant cryptography via the OpenSSL 3.0 Provider API. No bolt-on libraries, no `ring`, no pure-Rust HMAC / SHA / HKDF implementations. Cryptography is invariant – not configurable per-environment.
Post-quantum signing
ML-DSA-65 and ML-DSA-87 supported as native signing algorithms for root and intermediate CA today. Or stay classical with a Catalyst hybrid extension carrying an ML-DSA signature alongside the classical one – backward compatible with every legacy verifier.
OIDs 2.16.840.1.101.3.4.3.17 and .18
Database-level enforcement
Audit log records cannot be modified or deleted at the application layer. Postgres triggers block UPDATE and DELETE at the database level. Compliance posture you can demonstrate to an auditor, not just claim in a policy.
Endpoint keys never leave hardware
Private keys are generated on the endpoint that uses them. The Hub signs CSRs or proxies protocol flows. No exception path. No `serverkeygen` endpoint. The architecture invariant is enforced at the API boundary.
2030 is closer than the budget cycle implies.
For regulated buyers with multi-year asset lifetimes – financial-services payment infrastructure, government identity systems, healthcare device fleets – a CA decision made in 2026 is in production through 2031 minimum. The question every procurement evaluator should ask:
"When RSA and ECDSA are deprecated in 2030, will this CA still issue certificates we trust?"
Every open-source private PKI in the corpus – step-ca, EJBCA, CertCTL, Vault community – answers "no, we'll migrate when we get there." Every classical commercial CA gives the same answer.
Cyphrs Trust CA ships ML-DSA-65 and ML-DSA-87 signing today. The choice happens at the offline root CA ceremony, not as a retrofit project four years from now. The 2030 transition becomes a profile change, not a CA-replacement project.
Designed to survive an audit.
Approval gates, evidence binding, dual-control, and immutable audit are first-class architectural invariants – not configuration options.
Production deployment approval is bound to the exact reviewed evidence bundle, not regenerated at approval time. Dual-control by default for sensitive actions. Every gate decision linked to the audit log.
Five roles, nineteen-plus capabilities, centralised capability evaluator. No ad-hoc role checks scattered through the code. API keys with hashed prefixes and revocation. Capabilities checked at every sensitive boundary.
Every issuance audit-event records the certificate profile version it was issued under. If a profile changes, prior issuances remain traceable to their original policy. The system determines the profile; the operator selects who.
Offline root CA key ceremony tool with localhost web wizard. Air-gapped operation, no network dependencies. Cryptographic invariant: the Hub refuses to start if the ceremony marked the root key as evicted but the key file is still on disk.
On-premises by default. SaaS only by choice.
The Customer Hub runs on customer infrastructure. No SaaS dependency for the certificate lifecycle. Air-gapped deployment is supported. Master Hub (CT intelligence, delegated DNS) is a separate runtime, optional, and behind explicit mode gates.
- → Cyphrs Hub runs on customer hardware. ACME + private CA + Trust Intelligence + audit. PostgreSQL only.
- → Root CA generated via offline ceremony on a separate machine. Root private key never goes on the production Hub.
- → CA sidecar mode optional. The Hub talks to a separate CA process via NATS request / reply for stronger key isolation in regulated deployments.
- → Scout agents selective. Tier 1 protocol enrollment (EST / SCEP / ACME) runs agentless. Scout deploys only on hosts that justify deeper integration.
- → No SaaS dependency for the customer's certificate lifecycle. CT intelligence is an opt-in upstream service when needed, never a runtime requirement.
The questions to ask, with the answers.
If you're evaluating Cyphrs against an internal-build, open-source-PKI, or commercial-CLM alternative, these are the questions worth asking each vendor and the answers Cyphrs gives.
Is your cryptographic module FIPS 140-3 validated, and which exact module are you using?
Cyphrs uses the OpenSSL 3.0 Provider API for all cryptographic operations. The provider is a FIPS 140-3 module. No alternative crypto paths exist – the architectural invariant is enforced.
Can you issue ML-DSA-signed certificates today, or is it a roadmap item?
Today. ML-DSA-65 and ML-DSA-87 are available as native signing algorithms at root and intermediate CA ceremony. Catalyst hybrid extension is also supported. Hub-side leaf catalyst issuance is on the roadmap.
Where does the root key live, and can it ever leave customer infrastructure?
The root key is generated via offline ceremony on a customer-controlled machine. It never goes on the production Hub. The Hub refuses to start if the ceremony marked the root key as evicted but the key file is still on disk – a coded invariant, not a policy.
Can the audit log be tampered with?
Not at the application layer. Postgres triggers block UPDATE and DELETE on the audit_log table at the database level. Tampering requires direct database superuser access and the corresponding forensic evidence in the database engine itself.
Send us your compliance checklist.
We walk you through how each requirement maps to what Cyphrs ships, what's roadmap, and what's out of scope. No qualified deals required for a briefing.