up:: Migration Architecture MOC

Key Management

Key management is the discipline of handling cryptographic keys safely across their entire lifecycle: generating them, distributing them to the parties that need them, storing them so they can’t be stolen, using them, rotating them on a schedule, revoking them when they’re compromised, and destroying them when they retire. A cipher is only as strong as the secrecy of its key, so key management is the part of cryptography where most real-world failures actually happen. The algorithm rarely breaks. The key gets copied, leaked, left in a config file, wrapped under something a quantum computer can open, or never rotated. In a post-quantum migration this is the layer that carries the real weight, because the new algorithms bring bigger keys that strain the formats, hardware, and protocols built around small ones.

The short version:

• Key management is the whole life of a key: generation, distribution, storage, use, rotation, revocation, and destruction. NIST codifies this as a set of key states and a cryptoperiod for every key.
• Keys are usually anchored in a hardware security module (HSM) and operated through a key management system (KMS), which is often the single largest cryptographic surface an organization owns.
• The post-quantum keys are much larger than the classical ones they replace, so the friction shows up here first: a ML-KEM public key is over 1,000 bytes where an elliptic-curve key is 32, which strains message sizes, token storage, and HSM formats.
• Crypto-agility is really a key-management property. It’s the ability to roll keys and swap algorithms cleanly, without opening every application by hand.
• Data-at-rest exposure is usually a key-wrapping problem. The bulk AES-256 survives quantum fine, but the RSA- or ECDH-wrapped key that unlocks it is the quantum-vulnerable link.

Think of the master keys to a large building. The locks can be excellent, but the whole system stands or falls on how the keys are handled: who cuts them, how they get to the right hands, where the spares are kept, how often they’re changed, and whether anyone actually collects and destroys the copies when a keyholder leaves. Change the lock standard across the whole building and every one of those steps has to happen again, at scale, without locking anyone out mid-shift. Key management is that set of procedures for an organization’s cryptography, and the quantum transition is exactly that building-wide re-key.

What is key management?

Key management is the set of processes and infrastructure that governs cryptographic keys through their entire existence, so that the right parties hold the right keys, unauthorized parties never do, and every key is retired cleanly before it becomes a liability. NIST’s foundational guidance, SP 800-57 Part 1, frames it around two ideas: a defined set of key states that every key moves through, and a cryptoperiod, the bounded span of time a given key is authorized for use. A key doesn’t just exist; it’s pre-activated, made active, eventually deactivated, and destroyed, and a well-run system knows which state each key is in at all times.

Source: Elaine Barker, “Recommendation for Key Management, Part 1: General,” NIST SP 800-57 Part 1 Rev. 5, May 2020, csrc.nist.gov/pubs/sp/800/57/pt1/r5/final.

Two pieces of infrastructure do most of the work in a modern estate:

1. A hardware security module (HSM) is the tamper-resistant vault that generates and holds high-value keys and performs operations with them so the raw key never leaves the hardware. HSMs are validated against FIPS 140-3.
2. A key management system (KMS) is the software layer that controls which principals can use which keys for which operations, enforces the lifecycle policy, logs every access, and exposes an API so applications ask for a cryptographic operation rather than ever touching the key itself. Every major cloud offers one (AWS KMS, Azure Key Vault, GCP Cloud KMS) over an underlying HSM.

Source: Elaine Barker et al., “A Framework for Designing Cryptographic Key Management Systems,” NIST SP 800-130, August 2013, csrc.nist.gov/pubs/sp/800/130/final.

The reason this matters so much: the KMS is frequently the largest single cryptographic surface an organization has, because it manages the keys that protect databases, object storage, backups, and application-level encryption across the whole environment. Get the algorithms wrong there and every dependent system inherits the weakness, even when the encryption itself is strong.

What is the key lifecycle?

The key lifecycle is the ordered sequence of stages a cryptographic key passes through, from the moment it’s created to the moment it’s securely destroyed. Every stage is a place the key can be protected or lost, and a post-quantum migration touches all of them. The stages, and where the quantum transition changes each one:

Stage	What happens	The post-quantum wrinkle
1. Generation	The key is created from a certified random source, usually inside an HSM	Post-quantum keys are generated by different math and are much larger, and they still need strong entropy from an approved random-bit generator
2. Distribution	The key (or a public half) is delivered to the parties that need it	A ML-KEM public key is roughly 1,184 bytes and an ML-DSA signature roughly 3,309 bytes, versus 32 bytes for an X25519 key, so distribution messages and handshakes inflate
3. Storage	The key rests in an HSM, a token, or wrapped inside a key store	Larger keys strain fixed-size token formats, smartcards, and HSM object slots built for small classical keys
4. Use / rotation	The key does its work, and is periodically replaced within its cryptoperiod	Rotation is where crypto-agility is tested. Swapping the algorithm through configuration, rather than rebuilding every application that touches it, is the capability that matters here
5. Revocation	A compromised or superseded key is marked invalid so nothing trusts it	Revocation infrastructure (CRLs, OCSP, trust stores) has to carry the larger post-quantum certificates and signatures too
6. Destruction	Every copy of the retired key is securely erased	Unchanged in principle, but re-wrapping stored data keys under new post-quantum keys can force re-encryption of the data itself at scale

Sources: Elaine Barker, NIST SP 800-57 Part 1 Rev. 5, §7 (key states and transitions), csrc.nist.gov/pubs/sp/800/57/pt1/r5/final. NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024 (ML-KEM-768 encapsulation key 1,184 bytes), csrc.nist.gov/pubs/fips/203/final. NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024 (ML-DSA-65 public key 1,952 bytes, signature 3,309 bytes), csrc.nist.gov/pubs/fips/204/final.

The single most common lifecycle mistake is treating destruction as optional. A key that’s rotated out but never collected and erased is a key that can still decrypt whatever it once protected, which is the whole reason retired keys are a liability rather than a footnote.

Where does key management live in a real system?

Key management lives in a small number of high-value places, and finding all of them is part of building a cryptographic inventory. The concrete homes:

1. Envelope encryption hierarchies. Most storage encryption uses two tiers: a data encryption key (DEK) encrypts the actual data, and a key encryption key (KEK), held in an HSM, wraps the DEK. The KMS only ever hands out wrapped DEKs, never raw ones.
2. PKI and certificate stores. Certificate authority signing keys are among the highest-value keys anywhere, because one CA key vouches for every certificate beneath it.
3. TLS, SSH, and VPN endpoints. Every termination point holds private keys and negotiates session keys, and a key derivation function turns a shared secret into the working keys.
4. Vendor-controlled products. A large share of an organization’s keys are generated and managed inside third-party products the security team can’t directly see, which is why key management is never fully solved by internal scanning alone.

The pattern across all of them is a division of labor. Something manages and delivers the key, and something else does the bulk encryption with it. Understanding that split is what makes the quantum exposure legible, because the two halves are affected very differently.

Why does key management make a post-quantum migration harder?

Because the post-quantum algorithms are drop-in for the math but not for the plumbing, and the plumbing is key management. The replacement algorithms are standardized and increasingly shipped by default, so choosing them is the easy part. The hard part is that they carry much larger keys, ciphertexts, and signatures, and decades of key-management infrastructure quietly assumed those artifacts would stay small. The friction concentrates in a few places:

1. Size strains distribution. A hybrid key exchange carrying a post-quantum key can push a handshake message over a kilobyte, and middleboxes on the path that never expected a message that large can drop it. Cloudflare, testing hybrid key exchange at internet scale, found connections failing at sharp size cliffs when a device on the path refused the larger handshake.
2. Size strains storage. Smartcards, tokens, and HSM object formats sized for a 32-byte elliptic-curve key or a 256-byte RSA key have to accommodate keys several times larger, and not every deployed device has the room or the firmware.
3. Hardware gates the timeline. An HSM has to run firmware that supports the new algorithms before the KMS above it can generate or store post-quantum keys, so the HSM refresh cycle, often measured in years, sets the pace for everything downstream.
4. Rotation is the real test. An estate that can technically load a new algorithm but takes eighteen months to roll it into production keeps its exposure window open the whole time, which is why the practical target is a rotation measured against a disclosure rather than a hardware-refresh cycle.

Source: Cloudflare, “The state of the post-quantum Internet,” blog.cloudflare.com/pq-2024; NIST FIPS 203 and FIPS 204 (key and signature sizes), csrc.nist.gov/pubs/fips/203/final.

This is why so much of a migration’s cost sits below the algorithm. Picking ML-KEM is a decision. Getting every HSM, token, key store, and rotation procedure ready to hold and cycle it is a program.

Is my data at rest safe if it’s AES-256 encrypted?

The bulk cipher is safe, and the key that unlocks it usually isn’t, which is the single most important thing to understand about data-at-rest exposure. AES-256 survives the quantum transition comfortably, because the best quantum attack on it, Grover’s algorithm, only halves its brute-force strength and leaves about 128 bits of security. So the terabytes of encrypted data themselves aren’t the weak point. The weak point is the wrapping.

In a normal envelope-encryption setup, the data encryption key that AES uses is itself encrypted (wrapped) under a key encryption key, and that wrapping is frequently done with RSA or an elliptic-curve mechanism. Those are exactly what Shor’s algorithm breaks. So the attack path is:

1. An adversary copies the encrypted data and the wrapped data key today, from a backup, an export, or a stolen database.
2. They store it and wait for a capable quantum computer.
3. When one exists, they break the RSA or elliptic-curve wrapping, recover the AES data key, and decrypt the data retroactively.

That’s harvest now, decrypt later applied to storage, and it means AES-256 encryption gives a false sense of safety whenever the key that opens it is wrapped by a quantum-vulnerable algorithm. The fix isn’t to replace AES. It’s to re-wrap the data keys under a post-quantum mechanism such as ML-KEM (or a symmetric AES key-wrap, which also survives), and that re-wrapping is a key-management operation. For very large data stores, it can cascade into re-encrypting the underlying data, which is why organizations with long retention windows treat this as a real project rather than a setting.

Source: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” September 2022 (AES-256 retained, RSA and ECDH retired for national-security systems), media.defense.gov CNSA 2.0.

How does key rotation relate to crypto-agility?

Rotation and agility are the same muscle seen from two angles: rotation cycles the key value, and crypto-agility is what lets you cycle the algorithm underneath it without a rebuild. A key-management system that can only rotate values, but bakes the algorithm choice into application code, forces a redevelopment project every time the algorithm has to change. One that treats the algorithm as a configuration or policy decision can swap RSA wrapping for ML-KEM wrapping from a central point and let it propagate to every dependent application at once.

That’s the whole reason agility is a key-management property rather than a protocol feature. The post-quantum transition isn’t the last algorithm change an organization will ever make, so building rotation and algorithm-swap into the key-management layer is what turns the next migration from a multi-year excavation into a policy edit. A caution worth stating plainly, though: agility is an enabler, not a control. It gives you the ability to change the algorithm; it doesn’t make the new one strong and it doesn’t decide to actually rotate. Governance, including a minimum-strength floor so a system can’t be quietly downgraded, has to ride alongside it.

Source: NIST, “Transition to Post-Quantum Cryptography Standards,” NIST IR 8547 (initial public draft), csrc.nist.gov/pubs/ir/8547/ipd.

Has key management failed before?

Yes, and for most of cryptographic history it’s where systems fell, not on the cipher. For roughly 2,000 years, the fundamental constraint wasn’t the strength of the code but the problem of getting the key to the other end before you needed it. Sparta’s scytale operators, Renaissance diplomats, and Cold War embassies all faced the same wall, and they solved it with trusted couriers, sealed key lists, and pre-arranged codebooks.

The cost and the risk lived entirely in that handling. Commercial banks in the 1960s and 1970s that wanted to communicate securely had to establish a shared key with every partner bank by physically carrying the key material in a padlocked briefcase, hand-delivered by a bonded courier, sometimes two couriers for mutual verification. A bank talking to a thousand others meant a thousand of these exchanges, and every suspected compromise restarted the dance. A small industry of couriers specializing in cryptographic key material existed through the 1970s, and the per-message cost of secure banking was dominated by that one-time key-distribution cost.

Source: Simon Singh, “The Code Book,” 1999, on the 2,000-year key-distribution problem and pre-public-key key handling.

That era ended in 1976 when public-key cryptography made key distribution cheap, which is precisely what made the internet possible. Post-quantum cryptography is the effort to preserve that cheap key distribution against a quantum attacker. The lesson the history carries forward is that the cipher is rarely the thing that fails. The key handling is, and a migration that upgrades the algorithm while ignoring the key lifecycle is repeating the oldest mistake in the field with newer math.

Common misconceptions

1. “Strong encryption means our data is safe.” The cipher can be unbreakable while the key that unlocks it is wrapped by a quantum-vulnerable algorithm. Data-at-rest exposure is usually a key-wrapping problem, not a cipher problem.
2. “AES-256 has to be replaced for post-quantum.” It doesn’t. AES-256 survives. The urgent replacement is the RSA or ECDH key management around it.
3. “Key management is just where you store keys.” Storage is one stage. Generation, distribution, rotation, revocation, and destruction each carry their own failure modes, and destruction is the one most often skipped.
4. “The cloud KMS handles quantum for us.” Cloud providers are shipping post-quantum support unevenly, with signing keys ahead of key-wrapping keys, so the coverage has to be checked per operation rather than assumed.
5. “Crypto-agility means we’re migrated.” Agility makes the change feasible. It isn’t the change. An agile key-management layer with no plan and no execution is still wrapping keys with vulnerable algorithms.
6. “We rotate keys, so we’re fine.” Rotating the value while the algorithm stays quantum-vulnerable leaves the exposure open. The algorithm itself has to move for the rotation to close anything.

Questions people ask

What’s the difference between an HSM and a KMS? An HSM is the tamper-resistant hardware that physically protects and operates on key material so the raw key never leaves it. A KMS is the software and policy layer above it that decides who can use which key for what, enforces the lifecycle, and logs everything. The KMS manages; the HSM guards.

What is a cryptoperiod? It’s the bounded span of time a specific key is authorized for use before it must be rotated out, defined in NIST SP 800-57. Limiting a key’s cryptoperiod limits how much data one key protects and how long a compromise stays useful, which is why rotation is a scheduled discipline rather than an emergency response.

Do I have to replace AES-256 keys? No. The AES-256 bulk encryption carries forward through the transition. What has to change is the public-key mechanism that wraps or delivers the AES key, since that’s the part Shor’s algorithm breaks.

Why do post-quantum keys cause so much trouble? They’re much larger than the classical keys they replace, and a lot of infrastructure (token formats, smartcards, HSM object slots, handshake message sizes) was built assuming small keys. A ML-KEM public key is over a kilobyte where an elliptic-curve key is 32 bytes, so the size ripples through distribution and storage.

Does my HSM need to change? Probably. An HSM has to run firmware that supports the post-quantum algorithms before the key management system above it can generate or store those keys, and HSM refresh cycles are long, so this is often the gating dependency for the whole migration timeline.

Where should key-management work start? With inventory. You can’t rotate or re-wrap keys you don’t know exist, so a cryptographic inventory that maps where keys live, what wraps them, and what they protect is the prerequisite for any lifecycle change.

Is key wrapping the same as key exchange? They’re cousins. Key wrapping encrypts one key under another (common in storage and envelope encryption), while key exchange establishes a shared secret between two parties over a channel (common in TLS). Both can rest on quantum-vulnerable public-key math, and both are in scope for the migration.

---

Everything here is the map, given freely. When your team needs its key lifecycle assessed, its wrapped keys traced, and a rotation-and-re-wrap plan built against your own HSMs and key stores, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.