Cryptography, key management and the post-quantum transition

It is worth restating the foundations one level deeper before adding key management on top. Cryptography gives you three families of primitive, and each is a contract with a specific promise and a specific failure mode. It is not magic, and treating it as magic is where most real-world mistakes start.

Symmetric encryption uses one shared secret to both encrypt and decrypt. It is fast and is what protects bulk data: AES in an authenticated mode such as AES-GCM is the workhorse. Its contract is simple and brittle: confidentiality holds only while the single key stays secret and the nonce is never reused with the same key. Reuse a nonce and you can leak the plaintext relationship between two messages without anyone breaking AES at all.

Asymmetric, or public-key, cryptography uses a mathematically linked key pair: a public key anyone may hold and a private key only the owner holds. It solves the two problems symmetric ciphers cannot: agreeing a key with someone you have never met (key exchange) and proving who sent something (digital signatures). RSA and elliptic-curve schemes such as ECDSA and X25519 are the common examples. Their contract rests on a hard mathematical problem, factoring or discrete logarithms, and this is precisely the contract a large quantum computer would one day void. That is the thread this module pulls on later.

Hashing is one-way. A hash such as SHA-256 turns any input into a fixed-length fingerprint that cannot be reversed and that changes completely if a single bit of input changes. Its contract is collision resistance: it should be infeasible to find two inputs with the same fingerprint. That contract expires when an algorithm is broken, which is why MD5 and SHA-1 are now banned for security use. Hashing protects integrity and stores passwords; it does not protect confidentiality, and a plain hash on its own proves nothing about who produced it, which is why keyed constructions such as HMAC exist.

Hold on to one line from this section: choosing the primitive is the easy part, and the primitive is almost never what breaks. What breaks is the handling of the key.

A key is not a static secret you set once. It has a life, and every stage of that life is a place custody can be lost. NIST SP 800-57 sets out the cryptographic key lifecycle as six stages: generate, distribute, use, rotate, revoke and destroy. A key is generated from a good source of randomness, distributed to the parties that need it without ever travelling in the clear, used under least privilege with its use logged, rotated on a schedule and on events such as staff departures, revoked the moment compromise is suspected, and destroyed by zeroising every copy when it is retired.

Two systems carry this work. A key management system (KMS) centralises the handling of keys so that applications never hold raw key material themselves; it generates, stores, distributes and retires keys and enforces policy over who may use which key for what. A hardware security module (HSM) is tamper-resistant hardware that performs cryptographic operations inside its own boundary, so the private key is created and used but never leaves the device in readable form. A cloud KMS is typically backed by HSMs; the KMS is the policy and lifecycle layer, the HSM is the vault that the most sensitive keys never leave.

How do you know an HSM actually protects what it claims to? That is what FIPS 140-3 validation answers. It is the US and Canadian standard, aligned with ISO/IEC 19790, for the security of cryptographic modules, with four ascending levels from basic (Level 1) to strong physical tamper response and environmental protection (Level 4). Buying a module validated to a stated level, rather than one merely described as secure, is how a procurement decision becomes an evidenced one.

Key rotation, replacing a key with a fresh one on a defined schedule and after any suspected exposure, limits the blast radius of a compromise: a key that is rotated every ninety days can only ever decrypt ninety days of data if it leaks. The deeper point of this whole section is a design warning. Cryptography fails at custody far more often than at mathematics. Hard-coded keys in source code, private keys emailed between teams, a single master key that is never rotated, expired certificates that take a site down: these are the incidents that actually happen, and none of them is an algorithm being broken.

Encryption is not the only data control, and it is not always the right one. Two others belong in every practitioner's vocabulary, and the most important idea in this section is that sometimes the correct control is to not hold the data in the first place.

Data loss prevention (DLP) is egress policy. A DLP system inspects data in motion and at rest against rules that describe what sensitive data looks like, a card number pattern, a document marked confidential, a block of personal records, and then monitors, alerts on or blocks that data leaving through email, uploads, removable media or messaging. DLP does not make data secret; it enforces where data is allowed to go. It is how an organisation turns a data-handling policy from a document into an enforced control, and it is exactly the control whose absence turns a small mistake into a reportable breach.

Tokenisation replaces a sensitive value with a non-sensitive substitute, a token, that has no mathematical relationship to the original and is worthless if stolen. The real value lives in a separate, heavily guarded token vault; everywhere else holds only tokens. This differs from encryption in a decisive way: encrypted data can be decrypted by anyone who obtains the key, whereas a token cannot be reversed at all without access to the vault. For stored payment-card data this is the standard move, because it takes most systems out of scope for the strict handling rules of PCI DSS. The systems that only ever see tokens are no longer holding card data, so the compliance and breach burden shrinks with them.

Read those two together and the design lesson lands. Encryption protects data you must hold. Tokenisation and data minimisation remove the data from most of your estate so that there is far less to protect. The most secure record is the one you never stored, and the second most secure is the one that exists only as a token pointing at a vault someone else is paid to guard.

A large, fault-tolerant quantum computer would break the hard problems that RSA and elliptic-curve cryptography rely on. None exists today. The reason to act now is not that the machine is here; it is that the migration is slow and the data has a long memory. This is the harvest-now-decrypt-later argument, and it is the single line to give a non-technical audience: an adversary can record your encrypted traffic today, store it cheaply, and decrypt it years later once the machine exists. Any data whose sensitivity outlives the arrival of quantum computing, medical records, state secrets, long-term contracts, is effectively at risk from the moment it is sent, not from the moment the machine is switched on.

The replacements are no longer research. On 13 August 2024, NIST finalised the first three post-quantum standards. FIPS 203 defines ML-KEM, a key-encapsulation mechanism for agreeing keys, derived from the CRYSTALS-Kyber submission. FIPS 204 defines ML-DSA, a digital-signature algorithm derived from CRYSTALS-Dilithium. FIPS 205 defines SLH-DSA, a hash-based signature scheme that rests on different mathematics again, so that a break in one family does not take signatures down with it. On 11 March 2025, NIST selected HQC as a fifth algorithm, a backup key-encapsulation mechanism built on error-correcting codes rather than lattices; its draft standard is expected in 2026 and a final around 2027.

Two timelines turn those standards into deadlines. NIST IR 8547 sets the cryptographic-agility schedule: classical public-key algorithms at the 112-bit security strength are to be deprecated by 2030, and quantum-vulnerable algorithms are to be disallowed after 2035. The NCSC, in its post-quantum migration guidance, frames the same journey for organisations as three milestones: define your goals and complete a full discovery exercise with an initial plan by 2028, complete your highest-priority migrations by 2031, and complete migration of all systems, services and products by 2035. The two tracks agree on the destination and the year.

Proof that this is motion, not paperwork, is already in your browser. The hybrid X25519MLKEM768 key agreement from the opening story is the migration made concrete: a design that adds ML-KEM alongside the classical exchange so that traffic gains post-quantum protection now, while the classical half continues to guarantee at least today's security if the new scheme were ever found wanting. That belt-and-braces hybrid approach is how a careful transition is supposed to look.

The NCSC 2028 milestone is a discovery milestone for a reason: you cannot migrate cryptography you have not found, and cryptography hides. In practice, discovery means answering three questions across the estate. Where does TLS terminate, so you know which servers, load balancers and gateways negotiate public-key cryptography on your behalf? Where do long-lived secrets and keys sit, especially in firmware, embedded devices and code-signing pipelines that are expensive and slow to change? And which of your vendors have a published post-quantum roadmap, because a great deal of your cryptography is delivered inside software you do not write.

The output is an inventory that pins each system to the timeline. For every system, record the cryptography in use (RSA, elliptic-curve, symmetric or already hybrid), the lifetime in years of the data it protects, and the vendor roadmap status. A system whose data must stay confidential past 2035 and which still relies on classical public-key cryptography is a harvest-now-decrypt-later risk today, and it moves to the front of the queue against the 2031 priority milestone. A system holding only short-lived, low-sensitivity data can wait for the general 2035 deadline. That prioritisation, data lifetime measured against the fixed milestone years, is the whole discipline: it turns an intimidating, estate-wide problem into a ranked list of dated, ownerable work.