PQC Engineering Series: Deep Dive 5 - Mayckon Giovani
Mayckon Giovani
SubscribeSign in
PQC Engineering Series: Deep Dive 5<br>Crypto-Agility Is a Runtime Property, Not a Compliance Checkbox
Mayckon Giovani<br>May 15, 2026
Share
Post-quantum cryptography is often discussed as if the hard part were choosing the right algorithm.<br>That framing is dangerously incomplete.<br>This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.
Subscribe
The first finalized NIST post-quantum cryptography standards gave the industry a concrete cryptographic foundation: FIPS 203 for ML-KEM, derived from CRYSTALS-Kyber; FIPS 204 for ML-DSA, derived from CRYSTALS-Dilithium; and FIPS 205 for SLH-DSA, derived from SPHINCS+. These standards matter. They create a stable target for implementation, certification, procurement, and migration planning. They also remove one of the laziest excuses the industry had: “we are waiting for standardization.” (NIST)<br>But standards do not migrate systems.<br>Algorithms do not rotate themselves through legacy services, constrained devices, certificate authorities, service meshes, firmware pipelines, mobile applications, industrial gateways, HSMs, backup archives, telemetry streams, audit logs, and forgotten internal APIs that nobody has touched since the last infrastructure reorganization.<br>The real post-quantum problem begins after the algorithm is selected.<br>Crypto-agility is usually described as the ability to replace one cryptographic algorithm with another. That definition is too weak. It sounds clean on paper, which is exactly how bad engineering ideas usually enter polite society. A system is not crypto-agile because a configuration file contains an enum named Algorithm. It is not crypto-agile because a vendor dashboard lets someone select “PQC-ready” from a dropdown. It is not crypto-agile because a library claims support for ML-KEM while the surrounding protocol still assumes ECDH-shaped semantics, fixed certificate sizes, static identity binding, and classical operational timelines.<br>A system is crypto-agile only if it can safely change its cryptographic assumptions while preserving its security invariants.<br>That is a much harder property.<br>It means the system can move from one algorithm family to another without breaking identity, authentication, authorization, confidentiality, integrity, auditability, availability, rollback safety, operational recovery, or policy enforcement. It means migration is not treated as a one-time deployment event, but as a controlled state transition across the entire lifecycle of the system.<br>Crypto-agility is not a checkbox.<br>It is a runtime property.<br>The distinction matters because post-quantum migration is not merely about replacing RSA, ECDSA, ECDH, or classical Diffie-Hellman. It is about changing the assumptions under which distributed systems establish trust. Those assumptions appear everywhere: in handshake transcripts, certificate chains, session negotiation, firmware manifests, device provisioning, key wrapping, data retention policies, build pipelines, artifact signing, remote attestation, secure boot, message queues, service identity, and long-term archival confidentiality.<br>The algorithm is the visible artifact. The dependency graph is the real battlefield.<br>A system that cannot describe where cryptography is used cannot migrate safely. A system that cannot describe why cryptography is used cannot preserve semantics during migration. A system that cannot describe what security property each cryptographic primitive is supposed to enforce is not crypto-agile. It is simply cryptographically decorated.<br>This is where many post-quantum readiness programs quietly fail.<br>They begin with inventory. Inventory is necessary, but inventory alone is not enough. A cryptographic inventory that says “RSA-2048 is used here” is useful, but incomplete. Used for what? Transport authentication? Firmware signing? Database encryption? Token verification? Key wrapping? Long-term document integrity? Internal mTLS? Customer-facing TLS? Offline license validation? Root CA operations? Recovery keys? Legacy VPN tunnels? Inter-device trust?<br>The same primitive can represent completely different risk depending on context.<br>RSA used in an ephemeral transport context does not create the same migration pressure as RSA used to protect data that must remain confidential for twenty years. ECDSA used for short-lived service certificates does not carry the same implications as ECDSA embedded into firmware trust anchors deployed across industrial devices with fifteen-year lifespans. A signature algorithm used in CI/CD artifact provenance does not have the same operational constraints as a signature algorithm burned into a boot ROM trust model.<br>Post-quantum readiness requires semantic inventory, not just cryptographic inventory.<br>That means every cryptographic usage must be mapped to the property it protects, the asset it binds, the lifetime...