PQC Cryptographic Inventory

See every crypto primitive your org depends on — before Q-Day does.

Deep, automated inventory of every cryptographic primitive in your code, infrastructure, and dependency graph. We connect to your GitHub / GitLab / Bitbucket via read-only OAuth, scan AST-level for RSA / ECDSA / secp256k1 / weak hashes / hard-coded IVs, then cross-reference your TLS certificates and Cloud KMS configuration. You get a signed PDF risk report and a phased migration plan.

Engagement

4–8weeks

Day-one staffing

Seniorled

Final artefact

Signedcert

Asset surface

Repo + TLS + KMS

Output artefact

Risk report

Standards mapped

FIPS 203/204

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.

Do you connect to our private repos?

Read-only OAuth via GitHub / GitLab / Bitbucket Server / Azure DevOps. We never write. Tokens are scoped per-repo and revocable. Self-hosted Git supported.

What languages and stacks do you cover?

Python, Go, Java, Rust, TypeScript/Node, C/C++, Solidity, Move, OpenSSL, BoringSSL, custom JCA providers, AWS KMS, GCP KMS, HashiCorp Vault, Azure Key Vault. Anything else, we extend the scanner.

How is this different from a generic SAST scan?

Generic SAST flags 'crypto used here.' Our scanner identifies the algorithm, key size, mode, IV handling, and cross-references it against the migration matrix. We surface ML-KEM-readiness, not just 'AES is used.'

What does the timeline look like?

4–8 weeks. Week 1: read-only access + scoping. Weeks 2–4: scan + manual review of high-impact findings. Weeks 5–7: report + migration plan drafting. Week 8: walkthrough with your team and signed delivery.

PQC Cryptographic Inventory

Every engagement ends with a registry-verifiable certificate.

You can't migrate what you can't see.

Signed deliverables. No handwave.

Cryptographic inventory CSV + PDF

CVSS-scored risk register

Harvest exposure analysis

Phased migration plan (12–36 months)

CNSA 2.0 compliance gap matrix

What your SAST scanner misses about your cryptographic surface.

What we’re actually shipping into your stack.