If you are an IT leader and post-quantum cryptography is not on your roadmap yet, you are already behind. That is not hyperbole - it is the reality of where we stand in early 2026. NIST finalised its first post-quantum cryptographic standards in August 2024, major vendors are rolling out support, and the clock is ticking on a threat that most organisations still have not properly assessed.
I manage IT infrastructure for an e-commerce company with over 250 users. We handle sensitive customer data, process thousands of transactions daily, and rely on encrypted communications across every layer of our stack. When I started looking into our quantum readiness last year, what I found was sobering. This post shares what I have learned and the practical steps I am taking to prepare.
Why This Matters Now - Not in Ten Years
The most common pushback I hear from fellow IT leaders is: "Quantum computers capable of breaking current encryption are years away. We have time." That thinking is dangerously wrong, for one critical reason.
The Harvest Now, Decrypt Later Problem
Nation-state actors and sophisticated threat groups are already intercepting and storing encrypted data today. The strategy is simple - capture encrypted traffic now, store it cheaply, and decrypt it later once quantum computers are powerful enough. This is not theoretical. Intelligence agencies have confirmed this approach is actively being used.
Think about the data your organisation handles. Customer records, financial transactions, intellectual property, strategic communications - how long does that data need to remain confidential? If the answer is more than five to ten years (and for most organisations it is), then the threat is not in the future. It is happening right now.
For an e-commerce business like ours, customer payment data, personal information subject to GDPR, and commercial agreements all have long confidentiality requirements. Every day we transmit that data under RSA or elliptic curve encryption is another day it could be harvested for future decryption.
The Timeline Is Shrinking
Estimates for when a cryptographically relevant quantum computer (CRQC) will exist vary, but the consensus has been tightening. Many experts now place it somewhere between 2030 and 2035. Some are more aggressive. The point is not to predict the exact date - it is to recognise that migration takes years, not months.
Replacing cryptographic algorithms across an enterprise touches everything: TLS certificates, VPN tunnels, email encryption, database encryption, API authentication, code signing, firmware updates, and more. If you start today, you might just be ready in time.
The New Standards - What NIST Has Given Us
In August 2024, NIST published three finalised post-quantum cryptographic standards. Understanding what they are and what they replace is essential for planning your migration.
ML-KEM (FIPS 203) - Key Encapsulation
Previously known as CRYSTALS-Kyber during the standardisation process, ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) is the primary standard for key exchange. This is what will replace the key agreement mechanisms in TLS handshakes, VPN tunnels, and anywhere you currently use Diffie-Hellman or ECDH.
ML-KEM is based on lattice cryptography and comes in three security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. For most enterprise use cases, ML-KEM-768 offers a good balance of security and performance.
The practical impact: this is the algorithm that protects data in transit. It is your top priority for migration because it directly addresses the harvest-now-decrypt-later threat.
ML-DSA (FIPS 204) - Digital Signatures
Formerly CRYSTALS-Dilithium, ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the primary standard for digital signatures. This covers code signing, certificate authentication, document signing, and verifying the integrity of software updates.
ML-DSA also comes in three levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The signature sizes are larger than what we are used to with ECDSA or RSA, which has implications for certificate chains and network overhead.
SLH-DSA (FIPS 205) - Stateless Hash-Based Signatures
Previously known as SPHINCS+, SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) provides an alternative signature scheme based on hash functions rather than lattice problems. It is considered a more conservative choice because hash-based cryptography is extremely well understood, but the trade-off is significantly larger signature sizes and slower performance.
SLH-DSA is best suited for use cases where you want defence in depth - a backup algorithm based on different mathematical foundations in case lattice-based schemes are found to be weaker than expected.
HQC - The Fourth Algorithm
NIST also selected HQC (Hamming Quasi-Cyclic) as a backup key encapsulation mechanism, expected to be standardised in 2027. Based on code-based cryptography rather than lattices, it provides algorithm diversity for key exchange alongside ML-KEM.
What This Means for Your Infrastructure
Let me walk through the major areas of impact, based on what I have been assessing in our own environment.
TLS and Web Traffic
This is where most organisations will feel the change first. TLS 1.3 already supports the concept of hybrid key exchange, where a classical algorithm (like ECDH) is combined with a post-quantum algorithm (like ML-KEM) in a single handshake. Google Chrome, Mozilla Firefox, and Cloudflare have been experimenting with and deploying hybrid key exchange since 2024.
For IT leaders, the action items are clear:
- Check your web servers and load balancers. Do they support post-quantum TLS? If you are running Nginx, Apache, or cloud-based load balancers, check your vendor's roadmap.
- Test with hybrid key exchange. The combination of X25519 and ML-KEM-768 (often called X25519Kyber768) is becoming the de facto first step.
- Watch your certificate authority. CAs are beginning to issue post-quantum certificates, but the ecosystem is still maturing. Plan for larger certificate sizes affecting handshake performance.
VPNs and Site-to-Site Tunnels
If you run IPsec or WireGuard VPNs, these rely on key exchange mechanisms that are vulnerable to quantum attack. Many VPN vendors are adding post-quantum support, but it is not universal.
In our environment, we use site-to-site VPNs to connect our warehouse, office, and cloud infrastructure. I have started conversations with our VPN vendor about their PQC roadmap. If your vendor cannot give you a clear timeline, that is a red flag.
Certificate Management
Post-quantum certificates are larger. ML-DSA-65 signatures are roughly 3,300 bytes compared to around 70 bytes for ECDSA P-256. That has real implications for certificate chains, OCSP responses, and the overall overhead of TLS handshakes - particularly on constrained devices or high-volume API endpoints.
If you do not already have a robust certificate management platform, now is the time to invest in one. Manual certificate management will not scale through a cryptographic migration.
Data at Rest
While the harvest-now-decrypt-later threat primarily targets data in transit, do not ignore data at rest. AES-256 is currently considered quantum-resistant (Grover's algorithm reduces its effective security to 128 bits, which is still sufficient), but the key management systems protecting those AES keys likely rely on RSA or ECC.
Review your key management infrastructure. If your encryption keys are protected by classical asymmetric cryptography, they need to be included in your migration plan.
Building Your Migration Roadmap
Here is the practical framework I am using to approach this in our organisation. It is not going to happen overnight, but having a structured plan makes the difference between controlled migration and panicked reaction.
Step 1 - Conduct a Cryptographic Inventory
You cannot migrate what you cannot see. A crypto inventory audit maps every use of cryptography across your organisation. This includes:
- TLS certificates (internal and external)
- VPN configurations
- Database encryption settings
- API authentication mechanisms
- Email encryption (S/MIME, PGP)
- Code signing certificates
- SSH keys
- File and disk encryption
- Third-party integrations and their cryptographic dependencies
This is tedious work, but it is non-negotiable. There are tools emerging to help automate this - IBM, Venafi, and others offer cryptographic discovery tools. Even a spreadsheet-based approach is better than nothing.
Step 2 - Classify and Prioritise
Not all cryptographic assets carry the same risk. Prioritise based on two factors:
- Data sensitivity and longevity - Data that must remain confidential for ten or more years is at highest risk from harvest-now-decrypt-later attacks.
- Exposure - Internet-facing systems are at higher risk of interception than internal-only systems.
For us, customer-facing web services and our payment processing pipeline are the highest priority. Internal admin tools are lower on the list.
Step 3 - Assess Your Vendors
Much of your cryptographic infrastructure is managed by third-party vendors - cloud providers, SaaS platforms, security appliances, certificate authorities. You need to understand their PQC roadmaps.
Questions to ask:
- When will you support post-quantum key exchange?
- Will you support hybrid mode (classical plus post-quantum)?
- What algorithms are you implementing?
- How will the migration be handled - automatic update or manual configuration?
- What testing have you done on performance impact?
Document the responses. Where vendors have no plan, escalate it and consider alternatives.
Step 4 - Start with Hybrid Mode
The industry consensus is to begin with hybrid cryptography - combining a classical algorithm with a post-quantum algorithm. This provides protection against quantum threats while maintaining compatibility and providing a fallback if any issues are discovered with the new algorithms.
Hybrid mode is available now for TLS in most modern browsers and many server implementations. Start testing it in your staging environments.
Step 5 - Plan for Performance and Compatibility
Post-quantum algorithms have larger key sizes and signatures. ML-KEM-768 public keys are around 1,184 bytes. ML-DSA-65 signatures are around 3,300 bytes. This will affect:
- TLS handshake latency (particularly on mobile networks)
- Certificate chain sizes
- Network bandwidth for high-volume API traffic
- Storage requirements for signed artefacts
Test extensively. Measure the impact in your specific environment. In our load testing, the performance overhead of hybrid TLS was measurable but acceptable - roughly 10-15% increase in handshake time. Your results will vary.
Step 6 - Build Internal Expertise
This is perhaps the most important step. Post-quantum cryptography is new territory for most IT teams. Invest in training. NIST publications, vendor training programmes, and industry conferences are all good sources. You need at least a few people on your team who understand the new algorithms, the migration challenges, and the tooling.
The Cost of Waiting
I understand the temptation to wait. Budgets are tight, teams are stretched, and there is always something more urgent. But consider this - the average large-scale cryptographic migration takes three to five years. If a CRQC arrives in 2032, organisations that start migrating in 2028 will not finish in time.
The cost of being late is not just a compliance problem. It is a fundamental data protection failure. Your encrypted data, your customers' personal information, your commercial secrets - all of it becomes readable.
What I Am Doing Right Now
To be concrete about where we are in our journey:
- Completed our initial cryptographic inventory across all production systems.
- In progress - vendor assessment for our top 20 critical suppliers.
- Testing hybrid TLS (X25519 plus ML-KEM-768) on our staging web servers.
- Planning a phased migration starting with internet-facing services in Q3 2026.
- Training our infrastructure team through vendor-provided PQC workshops.
We are not close to done. But we have a plan, we have started, and we know what the path looks like.
Key Takeaways for IT Leaders
- The threat is current. Harvest-now-decrypt-later means your data is at risk today, not just when quantum computers arrive.
- NIST standards are finalised. ML-KEM, ML-DSA, and SLH-DSA are published and ready for adoption.
- Start with discovery. You cannot migrate what you have not mapped.
- Go hybrid first. Combining classical and post-quantum algorithms is the safe transition path.
- Push your vendors. If they do not have a PQC roadmap, you need to know now.
- Budget for this. It is a multi-year programme that needs dedicated resources.
The quantum clock is ticking. The organisations that act now will be protected. The ones that wait will be scrambling. I know which side I want to be on.
Cryptographic migration is one piece of a broader security strategy. For more on building resilient security postures, see zero trust architecture in practice and identity-first security strategy.
Daniel Glover is an IT leader with over a decade of experience managing technology infrastructure, cybersecurity, and digital transformation for e-commerce and retail businesses. He currently oversees IT operations for 250+ users, focusing on security-first infrastructure, cloud strategy, and building high-performing technology teams. Connect with him on danieljamesglover.com.
Top comments (0)