Insights / Articles
Crypto-agility is an architecture property, not a library upgrade
An organisation that cannot say where RSA is used today will not be able to remove it on a deadline, whichever algorithm replaces it.
Topics
- Crypto-Agility
- Post-Quantum Cryptography
- Cryptographic Inventory
- Key Management
- PKI
- Migration
Post-quantum migration is usually introduced through the algorithms. Standards have been selected, libraries implement them, and the work appears to be a matter of adoption: identify the primitives, swap them, done. Organisations that begin there discover the actual problem within about a week.
The actual problem is that cryptography in a mature estate is not in one place. It is in TLS terminators and service meshes, in database transparent encryption, in signed artefacts and firmware, in VPN concentrators, in JWT signing keys, in hardware security modules, in a certificate that somebody generated in 2019 for an internal service and pinned in a mobile client. Very few organisations can produce that list. Without it, the migration has no scope, and a deadline against an unbounded scope is not a plan.
Harvest now, decrypt later sets the clock
The reason this cannot be deferred until a cryptographically relevant quantum computer exists is that the adversary does not have to wait either. Traffic and stored ciphertext captured today can be retained and decrypted whenever the capability arrives. For data whose confidentiality requirement outlives the expected arrival of that capability — health records, state secrets, long-lived commercial agreements, biometric templates — the exposure has already begun.
That reframes the deadline. It is not set by when quantum computers become useful. It is set by the confidentiality lifetime of the data an organisation is protecting, minus the time the migration will take. Both terms are usually unknown, which is itself the first finding of any serious assessment.
Attack path — harvest now, decrypt later
The only attack path on this site where the adversary's work is finished before the capability to exploit it exists.
- Adversary
- Capture
- Storage
- Later
- 01CaptureToday
Encrypted traffic is recorded in bulk
At a transit point, a compromised device, or anywhere else the adversary can observe. Nothing is broken, nothing fails, and nothing is detected — the ciphertext is simply kept.
- 02StorageOngoing
The archive is retained
Storage is cheap and ciphertext does not decay. An adversary prepared to wait pays almost nothing to keep it, which removes the usual economic pressure to act quickly.
- 03LaterDate unknown
A cryptographically relevant machine becomes available
Forecasting that date is not the useful exercise. What matters is whether it falls inside the confidentiality lifetime of what was captured — and for health records, state material, long-lived contracts and biometric templates, it very plausibly does.
- 04Later
The archive is decrypted
Every session recorded under classical-only key agreement is recoverable at once. The adversary chooses what to read years after the organisation stopped thinking about it.
Post-quantum key agreement, deployed before the capture. Traffic exchanged under a hybrid or post-quantum key agreement is not recoverable from the archive whenever the capability arrives. This is the only control on this path, and its timing is the whole difficulty: it has to be in place before the traffic is captured. Nothing applied afterwards reaches material an adversary already holds.
- 05Adversary
The contents are used
Disclosure, leverage, or quiet advantage. The organisation learns about a capture that happened years earlier, if it learns about it at all.
Does not occur once the chain is broken
Step 1 / 5 — Encrypted traffic is recorded in bulk
The layers agility actually requires
Inventory
Where cryptography is used, by what, with which parameters, and with what data lifetime behind it. Continuously maintained, because an estate changes faster than an audit cycle.
Abstraction
Applications call a cryptographic service or interface rather than a primitive directly, so an algorithm change does not require touching application code.
Policy
Which algorithms and parameters are permitted, for which classes of data, expressed centrally and enforced at runtime rather than documented in a standard nobody reads.
Rotation
The mechanical ability to change keys, certificates and algorithms on demand, exercised regularly enough that it is known to work.
Evidence
A record of what is deployed where, and when it last changed — which is what turns an assertion of compliance into something demonstrable.
The abstraction that is usually missing
Software that calls a cryptographic primitive directly has bound itself to that primitive. The algorithm name appears in application code, in configuration, and often in a serialised format that other systems parse. Changing it means a code change, a release, a compatibility window, and a negotiation with every consumer of the format.
Software that calls an interface — sign this, with the key appropriate to this classification of data — has bound itself to a policy decision that can be changed centrally. The migration cost drops from one release per application to one policy change plus a verification pass.
This abstraction is not free and is not always achievable. Protocol-level cryptography in TLS or SSH is governed by the peers and the libraries, not by application structure. Signed formats that third parties verify cannot change unilaterally. The realistic goal is not to abstract everything but to know which parts are abstracted, which are not, and what the second category will cost — which returns, again, to the inventory.
Rotation, treated as a drill
Most estates can rotate a key in principle. Considerably fewer have done it recently, under time pressure, across a dependency chain, without an outage. The gap between those two states is where a migration schedule goes wrong, and it is discoverable in advance at low cost.
Discover
Where the primitive is used and by what
Classify
Confidentiality lifetime of the data behind it
Abstract
Route the call through an interface
Substitute
Hybrid first, where the protocol allows it
Verify
Interop tested against every consumer
Evidence
Recorded, so the change is demonstrable
Hybrid is a transition state
Hybrid key exchange — combining a classical and a post-quantum primitive so that the result is secure if either holds — is the sensible default during transition, and it is what deployed protocol work has converged on. It hedges against a weakness being found in a relatively young post-quantum construction without giving up protection against the harvesting problem.
It is worth holding it as a transition state rather than a destination. Hybrid doubles the material to manage, complicates interoperability testing, and carries a size and handshake cost that matters in constrained environments. The point of building agility first is that the eventual exit from hybrid is another policy change rather than another migration.
Articles
Positions reached while building.
What NIS2 and DORA actually ask of your telemetry
A 24-hour reporting clock is a data architecture requirement before it is a policy one. An engineering reading of what the EU incident-reporting regimes need from a security data platform.
September 2026 · 5 min read
Detection engineering is a software problem
Rule counts measure activity, not coverage. Treating detections as software — with dependencies, tests, owners and a retirement path — changes what a SOC can honestly claim.
September 2026 · 5 min read
The tiering decision: what a security data platform keeps hot
Security data architecture is mostly one recurring decision: which data is searchable in seconds, which is retrievable in minutes, and who is allowed to make the call.
September 2026 · 5 min read