Cryptographic Agility

Cryptographic Discovery — Start Here

Before choosing algorithms or migration paths, you need to know what cryptography you have and where it lives. Discovery produces a CBOM (Cryptographic Bill of Materials) — an inventory of every algorithm in use, cross-referenced with asset criticality. The CBOM determines your actual risk surface and which migration path applies to each system.

What a CBOM Covers

Asset Criticality Matrix

Cross-reference each CBOM entry against data lifetime and sensitivity to assign migration priority:

HNDL vs TNFL — Which Assets Are at Risk

HNDL Risk Calculator — Confidentiality Horizon

How urgent is your HNDL risk? Enter your data profile to see where you stand on the confidentiality horizon.

Two-Track Migration Model

Run key-exchange migration and signature/PKI migration as parallel tracks — they have different urgency drivers, different algorithms, and different operational constraints.

Regulatory Timeline — ASD Milestones

FIPS 140-3 Deployment Environment Classification

Before planning migration, classify each system's deployment environment — this determines the earliest date PQC can enter production.

CBOM Format — CycloneDX

The industry standard for CBOM is CycloneDX — supported by OWASP, adopted by the Post-Quantum Computing Consortium (PQCC), and integrated into tooling from IBM, SandboxAQ, and the Linux Foundation's PQCA project (CBOMkit). Each CBOM entry captures: component identifier, algorithm in use, key sizes and parameters, protocol context, certificate/key location, and vulnerability status.

Discovery Output → Migration Decision

CBOM References

ML-KEM-768 — Key Encapsulation

ML-KEM (NIST FIPS 203) replaces ECDH for key exchange. It is a Key Encapsulation Mechanism: the sender encapsulates a shared secret using the recipient's public key; only the recipient can decapsulate it.

Size Comparison

ML-DSA-65 — Digital Signatures

ML-DSA (NIST FIPS 204) replaces ECDSA for digital signatures. It is a lattice-based scheme with significantly larger keys and signatures than classical algorithms — but is quantum-safe.

Size Comparison

JWT Identity Token Transition

{"typ":"agent+jwt","alg":"ES256"}
{"sub":"spiffe://bank.internal/agent-1",
 "iss":"https://idp.bank.internal"}

{"typ":"agent+jwt","alg":"ML-DSA-65"}
{"sub":"spiffe://bank.internal/agent-1",
 "iss":"https://idp.bank.internal"}

Hybrid Classical + Post-Quantum

Running both classical and PQC algorithms in parallel provides defense-in-depth: an attacker must break both simultaneously to compromise the session. This is the approach adopted in TLS 1.3 (X25519+ML-KEM-768) and in many SPIFFE/mTLS migration paths.

Algorithm Negotiation & Rotation

Crypto agility (RFC 7696) means a system can negotiate the strongest mutually-supported algorithm and rotate when threat level changes — without protocol changes.

Private AI Inference — Homomorphic Encryption

When you query an AI model, the server sees your raw inputs — your prompts, your data, your query intent. Homomorphic encryption (HE) changes this: the server computes on encrypted inputs and returns an encrypted result. It never sees plaintext at any point.

result_enc = Σ (Enc(input_i) × weight_i)
result     = Decrypt(result_enc)
           = Σ (input_i × weight_i)

HE Scheme Comparison

Identity & Auth Token Transition

WIMSE workload identity tokens (WIT), agent tokens, and mTLS certificates all use classical algorithms today. The transition to PQC affects every layer — and the threat begins now, not when a CRQC exists.

Header:
{
  "typ": "agent+jwt",
  "alg": "ES256",     ← ECDSA P-256
  "kid": "key-2026-01"
}
Payload:
{
  "sub": "spiffe://mesh.internal/workload",
  "cnf": { "jkt": "<EC P-256 thumbprint>" }
}

Header:
{
  "typ": "agent+jwt",
  "alg": "ML-DSA-65",  ← FIPS 204
  "kid": "pq-key-2027-01"
}
Payload:
{
  "sub": "spiffe://mesh.internal/workload",
  "cnf": { "jkt": "<ML-KEM-768 thumbprint>" }
}

mTLS Certificate Migration

Standards Tracker

Post-quantum cryptography standards relevant to this PoC, tracked across NIST and IETF.