PQC Migration Engineering

Hybrid TLS, ML-KEM, ML-DSA — production-grade, week one.

Hands-on engineering to migrate your TLS endpoints, signature verification, key-management, and code-signing pipelines to post-quantum primitives. We embed senior engineers with your team, ship in production-ready PRs, and stay on through deployment + monitoring.

Engagement

8–24weeks

Day-one staffing

Seniorled

Final artefact

Signedcert

Downtime budget

Zero minutes

Cutover strategy

Hybrid first

Rollback window

T+60 days

Hybrid TLS isn't a config flag — it's a project.

Most teams discover this the hard way. oqs-provider needs to be wired into your build. Your CDN needs to advertise the new groups. Your KMS needs ML-KEM keys provisioned. Your code-signing pipeline needs ML-DSA. And your runbook needs to handle the rollback if something burns at 2am. That's not a flag. That's an engagement.

NIST FIPS 203

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

NIST FIPS 204

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

POLICY · CNSA 2.0

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

BRIDGE · HYBRID

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

TOOLING

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

TOOLING · CORE

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’

RUNTIME

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

KMS

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

Before you book the call.

What if my CDN / load balancer doesn't support hybrid yet?

We've shipped this on Cloudflare, Fastly, Akamai, AWS CloudFront, NGINX, HAProxy, and Envoy. Where the vendor doesn't support it natively, we configure a sidecar TLS terminator. We will tell you upfront which stack you're on.

Can we keep classical-only for legacy clients?

Yes — the entire point of HYBRID is graceful coexistence. Legacy clients stay on classical, modern clients get hybrid, and we measure the split with telemetry so you know exactly when to deprecate classical.

Will this break our existing certificates?

No. Hybrid TLS 1.3 negotiates groups separately from server certificates. Your existing RSA/ECDSA certs continue to work; PQ migration of the CERT itself is a separate (later) workstream we can sequence.

How do we measure success?

Three numbers, weekly: % of handshakes negotiating a hybrid group, p99 handshake latency delta vs classical baseline, and zero customer-facing TLS errors during the migration window.

PQC Migration Engineering

Every engagement ends with a registry-verifiable certificate.

Hybrid TLS isn't a config flag — it's a project.

Signed deliverables. No handwave.

Hybrid TLS rollout (X25519+ML-KEM)

Code-signing migration to ML-DSA / SLH-DSA

KMS / HSM PQC enablement

Runtime telemetry + alerting

Senior engineer pair-programming

The 3 mistakes most teams make migrating to hybrid TLS.

What we’re actually shipping into your stack.