Post Quantum Planning Without Panic
Quantum risk is not an emergency for every system today, but it is already a planning issue for data that must remain confidential for years. The practical goal for 2025 is clear: know where cryptography is used, decide what data is most exposed, and make systems easier to change before deadlines arrive.
The anchor facts are now solid. The US National Institute of Standards and Technology (NIST) finalised FIPS 203, FIPS 204, and FIPS 205 in August 2024. These standards cover the first approved algorithms for key establishment and digital signatures designed to resist quantum attacks. NIST has also published draft IR 8547, which proposes a transition timeline that deprecates many quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035. In Europe, the coordinated post-quantum roadmap is also moving, with milestones set for June 2025 under the EU approach to a shared transition plan.
Here is how to build a calm, evidence-based plan.
1. Start with the data that must stay secret
The phrase “harvest now, decrypt later” describes a simple attack pattern. An adversary records encrypted traffic or steals encrypted data today, then waits until future tools can break the encryption used to protect it.
This matters most when confidentiality has a long shelf life. Examples include:
Payment infrastructure designs
Customer identity data
Trading strategies
Authentication secrets
Legal records
Mergers and acquisitions material
Health or insurance records
Government or critical infrastructure data
A short-lived session log from a low-risk system may not justify immediate change. A data set that must remain confidential until 2035 clearly does. This is why post-quantum planning should begin with data classification, not with algorithm replacement.
Use three questions to set priorities:
How long must this data remain confidential?
Could an attacker capture it now?
What would happen if it became readable later?
If the answer points to high impact and long life, put the system near the top of the post-quantum cryptography plan.
2. Build a cryptographic inventory before changing controls
No regulated firm can migrate what it cannot see. A cryptographic inventory records where cryptography is used, which algorithms are in place, who owns the system, and how hard each component will be to change.
At minimum, capture:
Inventory field | Why it matters |
System or application name | Links the finding to an accountable owner |
Data protected | Shows business impact and retention period |
Algorithm and key length | Identifies exposure to quantum attacks |
Certificate use | Reveals renewal and trust chain dependencies |
Library or product | Shows whether change depends on internal code or a vendor |
Protocol | Finds common areas such as TLS, SSH, VPNs, and signing |
Replacement path | Tells teams whether change is simple, complex, or blocked |
Do not limit the inventory to internet-facing systems. Internal service calls, file encryption, backup encryption, document signing, hardware security modules, and third-party connections often contain older choices that no one has reviewed for years.
A good inventory also avoids false confidence. AES and SHA-2 are not in the same category as RSA or elliptic-curve cryptography. Quantum computing affects different cryptographic tools in different ways. Public-key encryption and digital signatures need the most attention because large enough quantum computers could break the mathematical problems they rely on.
3. Compare current use against the new standards
The NIST post-quantum standards finalised in August 2024 give organisations a stable reference point:
FIPS 203 Covers ML-KEM, a key establishment method based on CRYSTALS-Kyber.
FIPS 204 Covers ML-DSA, a digital signature method based on CRYSTALS-Dilithium.
FIPS 205 Covers SLH-DSA, a stateless hash-based digital signature method based on SPHINCS+.
These names will appear in product roadmaps, procurement answers, and security architecture reviews. The inventory should show where key exchange and digital signatures are used today so teams can map those uses to future options.
NIST draft IR 8547 is also useful for planning because it gives a directional timeline. The draft proposes that many public-key schemes vulnerable to quantum attacks should be deprecated after 2030 and disallowed after 2035. “Deprecated” means organisations should stop creating new dependencies on them. “Disallowed” means they should no longer be used for covered purposes unless an exception applies.
That timeline does not mean every system must be replaced in 2025. It does mean new architecture decisions made in 2025 should avoid creating systems that will be expensive to unwind before 2030.
4. Design for crypto agility from the start
Crypto agility means systems can change cryptographic methods without major redesign. It is a design principle, not a product feature.
Practical signs of good crypto agility include:
Algorithms are selected through configuration, not buried in code.
Certificates can be rotated without service outages.
Protocol versions can be phased in by environment.
Test suites include cryptographic negotiation and failure cases.
Hardware security modules and key management tools support planned algorithms.
Data formats have room for larger keys and signatures.
This matters because the transition will not happen in one clean step. Hybrid approaches, where classical and post-quantum methods run together, may be used during transition periods. Some products will support standards earlier than others. Some counterparties will move slowly. Systems that can accept change safely will reduce operational risk.
For fintech and other regulated environments, the lesson is direct: a PQC migration should be treated as an architecture programme, not only as a compliance task.
5. Test vendor roadmaps against real readiness
Vendor statements need careful reading. “Post-quantum ready” can mean research, a beta feature, partial protocol support, or production support aligned with FIPS 203, 204, and 205.
Ask vendors for evidence in writing:
Which approved algorithms are supported, and in which product versions?
Is support generally available or still experimental?
Which protocols are covered, such as TLS, VPN, code signing, or certificate management?
Are hybrid modes supported?
How will existing keys, certificates, and policies migrate?
What changes are needed in hardware, clients, agents, or third-party integrations?
What is the support timeline through 2030 and 2035?
How does the roadmap align with EU and NIST guidance?
For European operations, include the EU coordinated roadmap in governance tracking. The European Commission’s 2024 recommendation pushes Member States towards a shared path for the transition to post-quantum security, with milestones set for June 2025. That makes 2025 a sensible year to align procurement, audit evidence, and architecture principles before national expectations become more specific.
6. Turn the plan into governed work
A calm plan still needs ownership. Assign clear roles for inventory quality, architecture standards, vendor follow-up, risk acceptance, and board reporting. Track progress with a short set of measures:
Percentage of critical systems inventoried
Number of high-risk long-lived data flows identified
Number of vendor roadmaps received and reviewed
Systems with hard-coded cryptography
Systems blocked by unsupported products
New projects reviewed for post-quantum readiness
The goal is not to replace everything at once. The goal is to stop making the problem larger, protect long-lived data first, and make future changes cheaper.
Post-quantum planning in 2025 should feel disciplined, not frantic. Start with the data, build the inventory, design for change, and challenge vendor claims with specific evidence. For more practical guidance on security architecture and quantum-era planning, visit our website and use these steps to start a focused review of your own environment.
If you’d like help mapping where cryptography lives in your systems and planning the move, it’s part of our Security Architecture work.
