What we’re actually shipping into your stack.
The post-quantum migration is not a slide — it’s a specific set of standards, libraries, and key-management primitives. Below is what we touch on every engagement, why it exists, and what it protects you against.
ML-KEM (Kyber) · key encapsulation
The lattice-based key-exchange standard NIST finalised in August 2024. Replaces ECDH on every TLS 1.3 handshake, every IPsec tunnel, every messaging-app key wrap. We integrate the FIPS-203 module ML-KEM-768 by default (Level 3 security · ~256-bit classical · quantum-resistant).
- REQUIRES
- OpenSSL 3.x or BoringSSL with oqs-provider · TLS endpoint owner-of-record · 90-day rotation runbook
- PROTECTS
- Harvest-Now-Decrypt-Later: every byte your customers send today, recorded by an adversary today, decrypted in 2034 once Shor's-capable hardware exists
ML-DSA (Dilithium) · digital signature
The lattice-based signature standard. Replaces RSA-PSS and ECDSA on code-signing, document-signing, and TLS server authentication. We deploy ML-DSA-65 (Level 3) for transitional dual-signing alongside the classical algorithm during the migration window — never replace, always co-sign first.
- REQUIRES
- Sigstore / Cosign or in-house signer · code-signing CI/CD · 365-day key rotation
- PROTECTS
- Forged software updates, forged firmware, forged TLS server certs — every place a quantum-attacker would impersonate your build pipeline
NSA Commercial National Security Algorithm Suite v2
The U.S. federal mandate: PQC primitives operational across National Security Systems by 2030, exclusive by 2035. Defines the exact KEM (ML-KEM-1024) and signature (ML-DSA-87) profile used at NSS-grade and the migration-pace expected from contractors. Every Cryptographic Migration Certificate we issue carries an explicit CNSA 2.0 attestation block.
- REQUIRES
- FIPS-140-3 validated module (or FIPS-203/204 module-pending) · auditable inventory · documented sunset plan
- PROTECTS
- Federal contract eligibility post-2030 · DoD / IC supplier status · DORA + EO 14028 alignment
X25519 + ML-KEM · hybrid key exchange
The transitional posture every serious PQC rollout uses: combine a battle-tested classical primitive (X25519, the Curve25519 ECDH variant — or X448 at higher security level) with the post-quantum KEM in a single key-derivation step. If either side breaks, the other still holds. Browsers shipped this in 2024 (Chrome “X25519MLKEM768” group); we operationalise it for your endpoints.
- REQUIRES
- TLS 1.3 stack · OpenSSL 3.2+ or BoringSSL · negotiation telemetry to confirm hybrid-group adoption
- PROTECTS
- Day-1 deployment risk: a flaw in either ML-KEM or X25519 alone does not break your traffic — only a flaw in BOTH simultaneously could
oqs-provider · OpenSSL provider
The Open Quantum Safe project’s OpenSSL 3.x provider that exposes ML-KEM, ML-DSA, SLH-DSA, and the hybrid groups as first-class crypto algorithms inside any application that already speaks OpenSSL. We do not maintain a private fork — we ship upstream patches and point your CI at a reproducible build with a pinned commit.
- REQUIRES
- OpenSSL 3.2+ · CMake 3.18+ · liboqs build chain · application-side config update
- PROTECTS
- Vendor-lock-in to a single PQC library · drift between staging and production crypto behaviour
liboqs · post-quantum primitive library
The C library underneath everything else — implementations of every PQC candidate that ever entered NIST’s evaluation, including the four standardised winners (ML-KEM, ML-DSA, SLH-DSA, FN-DSA). Audited, side-channel-aware, and the de-facto reference for open-source PQC. We pin the version, we record the commit hash, and the hash makes it onto your migration certificate.
- REQUIRES
- C99 toolchain · OpenSSL or mbedTLS for symmetric primitives
- PROTECTS
- Implementation-bug exposure: a verified-pinned build is the difference between ‘we ran ML-KEM’ and ‘we ran a known-bad ML-KEM’
OpenSSL 3.x · with PQC providers loaded
The version line that gives us providers (modular crypto), proper FIPS module isolation, and the runtime negotiation hooks needed to ship hybrid TLS without a fork. We standardise every engagement on OpenSSL 3.2+ and surface the version on the certificate so auditors don't need to grep your container builds.
- REQUIRES
- Operating system upgrade if pinned to OpenSSL 1.x (RHEL 7, Ubuntu 18.04 etc.) · runtime config rebuild
- PROTECTS
- PQC drift across services — one binary on 3.2 negotiating hybrid, another on 1.1 silently falling back to classical-only
AWS KMS · GCP KMS · Azure Key Vault · Thales / Entrust HSM
Where your most sensitive keys actually live. Every cloud KMS now exposes ML-KEM and ML-DSA key types (AWS “ML_KEM_768”, GCP “PQ_SIGN_ML_DSA_65”, Azure “ML-KEM”), and on-premise HSMs from Thales and Entrust ship FIPS-203/204 firmware lines. We map your existing key inventory, design the wrap-and-rotate path, and ship the runbook your SRE team executes — without you ever exposing key material outside the boundary.
- REQUIRES
- Cloud account audit access · HSM administrator credential · IAM separation between operator and rotator
- PROTECTS
- Cross-region replication, backup/restore, and disaster-recovery flows breaking silently when a primary key migrates and a secondary doesn’t