Summary
- RFC 9958 asks engineers to build cryptographic agility and maintain a cryptographic inventory, including hard-coded uses and exposed configuration.
- A record that an algorithm was found is not evidence that it is selected on a live path, that all legacy paths are gone, or that anyone has authorized the residual risk.
The most seductive sentence in a post-quantum programme is also the shortest: “We have an inventory.” It sounds like a report on a completed migration because it answers a question that teams have often avoided: where is cryptography used? RFC 9958, Post-Quantum Cryptography for Engineers, treats that question as urgent. It advises application developers to look for hard-coded algorithm use and asks administrators, policy officers and compliance teams to track exposed cryptographic configuration through written or automated policy systems.
That is a major improvement over guessing. It is not a verdict. An inventory answers a bounded proposition: a person, scanner or process recorded a reference at a particular scope and time. The reference may be a library dependency, a certificate profile, a cipher-suite setting, a vendor declaration, a source-code constant, a build option, or an exception ticket. None is identical to the question a leadership team actually needs answered: which cryptographic operation happened on which production path, with which peer, under which approved exception, and with what remaining exposure?
RFC 9958 itself warns against the one-for-one-replacement story. Post-quantum algorithms can change key and ciphertext sizes, signature sizes, processing behaviour and application interfaces. It distinguishes public-key uses from the different considerations surrounding symmetric primitives and hashes. A Key Encapsulation Mechanism is not merely a new spelling for a Diffie-Hellman call: it has encapsulation and decapsulation roles, and its placement can require a protocol or application redesign.
A list that says “ML-KEM present” loses the decisive information if it does not say whether the item is a dormant dependency, a possible client offer, a selected handshake path, a wrapped-data recovery path, a test fixture, or a future design.
The difference is practical because a system has several distinct records. The discovery record says where a reference was located. The use record says what cryptographic function that component performs. The runtime record says whether a named path actually reached it. The compatibility record says what the peer and intermediary can negotiate. The exception record says which older path remains, why, until when, and who owns it. The decision record says who approved a change or consciously accepted the residual risk. The outcome record says what the post-change observation showed.
Compress those records into an “inventory complete” badge and the badge becomes an untraceable authority claim.
The standard is no excuse for that compression. RFC 9958 is Informational guidance, not a certification scheme, a deployment census or a forecast for the arrival of a cryptographically relevant quantum computer. Its own cryptographic guidance is non-authoritative where it conflicts with emerging and evolving CFRG guidance. NIST specifications for ML-KEM and ML-DSA identify algorithms and interfaces; they do not attest an organisation’s running traffic. RFC 7696’s idea of agility is the capacity to change algorithm choices. Capacity to change is not proof that a change has been selected, completed or survived rollback.
Heng Lu’s running-code primacy supplies a disciplined test. A configuration inventory matters because it gives an investigator a map. The map does not become the territory when a peer negotiates something else, a compatibility flag restores a legacy route, or a library takes a path that the scanner could not observe. The useful claim is therefore narrower and stronger: preserve the inventory as evidence, then bind it to controlled observation of the actual path. A programme that can make that chain legible can be challenged, repaired and governed. One that only repeats “PQC-ready” cannot.
Sources
- RFC 9958 — Post-Quantum Cryptography for Engineers
- RFC Editor record — RFC 9958
- RFC 7696 — Guidelines for Cryptographic Algorithm Agility
- RFC 9794 — Terminology for Post-Quantum Traditional Hybrid Schemes
- RFC 9180 — Hybrid Public Key Encryption
- NIST FIPS 203 — ML-KEM
- NIST FIPS 204 — ML-DSA
- IANA COSE Algorithms registry
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification, Localized Future Decision
- Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
