Crypto Agility Readiness Framework
Lab + system design reference for assessing crypto agility and post-quantum migration readiness.
Version 1.0 · November 2026 · Status: Reference — open for comment · Author: Ajay Salunkhe
Lab view. The label is not the measurement.
Design stance
- Inventory first.
- Risk and agility are separate dimensions.
- Key-agreement (KEM / hybrid TLS) and signatures / PKI are different tracks with different clocks.
- Hybrid is a controlled transition, not a destination.
- Outputs must be explainable to both engineers and leadership.
This is a design reference and assessment model — not a product specification and not a compliance certificate.
The problem it addresses
Most programmes still treat “PQC readiness” as a flag: hybrid enabled, library upgraded, dashboard green. That is not readiness.
Readiness is inventory, measurement on the wire, and a clear path to change algorithms without an outage or a silent classical fallback.
Four questions the framework answers
- What cryptography is actually in use — and what was not scanned?
- Where is quantum-relevant risk concentrated?
- How hard is it to change algorithms on each path?
- What should be measured so that “PQC on” is not only a label?
Architecture principles
- Inventory first — no reliable CBOM, no reliable score.
- Two tracks — key agreement (ML-KEM / hybrid) vs signatures and certificates (ML-DSA / SLH-DSA / PKI).
- Measurement over labels — handshake success ≠ negotiated PQ group; ticket issued ≠ resume success.
- Hybrid is transitional — enablement includes exercised exit paths, not only “both on”.
- Explainable scoring — weights and inputs stay visible.
Measurement requirements
These separate a label from a measurement.
Key-agreement track
- Log negotiated group after Finished (e.g. X25519MLKEM768 / 0x11EC), not only TLS 1.3 success.
- Re-test group intersection after upgrades — draft vs final codepoints are not interchangeable.
Resumption / performance track
- Session ticket issue and resume rates.
- Ticket size under hybrid vs edge buffer limits.
- First-flight size vs typical TCP initial window (~14.6 KB on many stacks).
Signature / PKI track
- Separate clock from KEM enablement.
- Do not hide a red certificate track behind a green KEM tile.
Maturity model (0–4)
- 0 Unknown — no usable inventory.
- 1 Inventory started — partial CBOM; large not-scanned set.
- 2 Risk & agility visible — scored assets; measurements defined.
- 3 Hybrid-capable & measured — negotiated-group logging; resume checks; signature track owned.
- 4 Crypto-agile — algorithm change is an exercised path; labels match wire measurements.
Moving from 2 → 3 requires evidence on the wire, not only a library version.
CBOM minimum fields
Asset / path, owner, algorithm, key size, protocol context, library version, certificate role, sensitivity & retention, discovery confidence, coverage flag (observed | inferred | not scanned).
“Not scanned” rows are first-class. A CBOM with no unknown rows is usually incomplete, not complete.
Label-only vs this framework
| Label-only view | This framework |
|---|---|
| “Hybrid enabled” | Negotiated group logged and tested |
| “Handshake success” | Success + selected group + resume rate |
| “CBOM complete” | CBOM + explicit not-scanned rows |
| Single “PQC %” | KEM track and signature track separate |
Inventory what you use. Measure what you negotiate. Separate the KEM clock from the certificate clock. Treat hybrid as a transition with an exit, not a sticker.
Lab view. The label is not the measurement.