Post-quantum cryptography has moved from research papers to published standards. NIST has finalised its first set of post-quantum algorithms for key establishment and digital signatures, and vendors are shipping support in libraries, browsers and hardware security modules.
That is the easy part. The hard part is that most organisations cannot say with confidence where they use cryptography today. You cannot migrate what you have not found.
Why the timeline matters now
A large enough quantum computer would break the public-key algorithms that protect most traffic and signatures today. Nobody can give you a reliable date for that.
What matters more is “harvest now, decrypt later”. Data captured today and stored can be decrypted once the capability exists. If your records need to stay confidential for ten or fifteen years, the clock has already started for them.
Long-lived signatures carry the same problem. Firmware, documents and certificates signed today may need to be trusted well into the future.
What a crypto inventory actually contains
An inventory is not a spreadsheet of algorithm names. Each entry should answer practical questions:
- Where — application, service, device, network segment, third-party integration
- What — algorithm, key size, protocol version, library and version
- Why — confidentiality, integrity, authentication, signing
- How long — how long the protected data or signature must stay trustworthy
- Who — the owning team and the person who can approve a change
- How hard — configuration change, code change, vendor upgrade or hardware replacement
The last column decides your plan. Changing a TLS configuration on a load balancer is a ticket. Replacing cryptography burned into field devices is a programme.
Where cryptography hides
Teams usually find the obvious places first: public web endpoints, VPNs, certificate authorities. The surprises are elsewhere.
- Service-to-service calls inside the network with their own TLS settings
- Database and backup encryption configured years ago
- Code signing pipelines and package repositories
- SDKs embedded in mobile apps and partner integrations
- Payment, identity and messaging providers you depend on but do not control
- Scripts and batch jobs that call crypto libraries directly
- Industrial and IoT devices with long replacement cycles
Discovery needs more than one method. Scan network traffic and certificates. Analyse code and dependencies for crypto library calls. Ask vendors directly about their roadmap. Interview the teams who run the oldest systems, because they know where the exceptions live.
Crypto agility is the real goal
The migration will not be a single switch. Standards will evolve, implementations will get patched, and some early choices will be revisited.
Design for change:
- Centralise cryptographic calls behind a small number of internal libraries or services
- Keep algorithm choices in configuration, not scattered through code
- Support hybrid modes, classical plus post-quantum, during transition where your stack allows it
- Test larger key and signature sizes against real payload limits, latency budgets and constrained devices
Post-quantum algorithms generally use larger keys and signatures than what they replace. That affects packet sizes, handshake times, storage and embedded memory. Find those limits in a test environment, not in production.
Prioritise by exposure, not by convenience
Once the inventory exists, rank entries by data lifetime, exposure and difficulty. Data that must stay secret for a long time and crosses untrusted networks goes first. Internal systems with short-lived data can wait for routine upgrades.
Third-party dependencies need their own track. Add post-quantum readiness to vendor reviews and contract renewals so the question is asked consistently.
Where to start
- Name an owner for the crypto inventory and give it a review cadence
- Run automated discovery on certificates, endpoints and code dependencies
- Interview owners of legacy, embedded and partner-facing systems
- Classify each entry by data lifetime and change difficulty
- Pick one low-risk system and pilot hybrid key exchange end to end
- Add crypto agility to architecture standards for new builds
Incubics helps teams build the inventory and the engineering plan that follows it, so the migration runs as ordinary delivery work rather than a last-minute scramble.