Post-Quantum Cryptography Migration: A Practical Timeline

Why This Matters Now

The NIST standardization of post-quantum cryptography algorithms (ML-KEM, ML-DSA, SLH-DSA) means migration is no longer theoretical—it's engineering work with clear timelines.

The Risk Window

Harvest Now, Decrypt Later: Adversaries are already capturing encrypted traffic, waiting for quantum computers capable of breaking current RSA and ECC encryption. Data encrypted today could be vulnerable within 10-15 years.

Compliance Timelines: Financial services regulators are establishing PQC migration deadlines. Government systems face even tighter schedules.

The Three Migration Challenges

How do we maintain backward compatibility?
- Hybrid cryptography approaches during transition
- Protocol negotiation for mixed environments
- Certificate chain complexity
What about performance impact?
- Larger key sizes affect bandwidth and storage
- Computational overhead on constrained devices
- Latency sensitivity in real-time systems
How do we validate the migration?
- Testing hybrid cryptography configurations
- Monitoring for compatibility issues
- Ensuring no security regressions

Recommended Migration Path

Phase 1: Assessment (3-6 months)

Inventory Current Cryptography:

Document all cryptographic implementations
Identify libraries, protocols, and dependencies
Map data sensitivity and retention periods

Risk Prioritization:

Long-lived data gets migrated first
High-value targets require immediate action
Short-lived ephemeral data can wait

Phase 2: Hybrid Implementation (6-12 months)

Dual Algorithm Support:

Run traditional and PQC algorithms in parallel
Maintain backward compatibility
Enable gradual rollout

Infrastructure Updates:

Certificate authorities support PQC certificates
Key management systems handle larger keys
Monitoring systems track both algorithm types

Phase 3: Production Deployment (12-24 months)

Progressive Rollout:

Internal systems first
Partner integrations second
Public-facing services last

Validation Strategy:

Monitor error rates and performance
A/B testing for performance comparison
Rollback procedures for each phase

Phase 4: Full Migration (24-36 months)

Deprecate Legacy Algorithms:

Remove classical cryptography support
Simplify key management
Reduce attack surface

Technical Considerations

Performance Trade-offs

Key Sizes:

ML-KEM-768: 2400 bytes vs RSA-2048: 256 bytes
Network overhead matters for high-frequency systems
Storage costs increase for key archives

Computational Cost:

Signature verification faster in some PQC algorithms
Key generation slower than RSA/ECC
Hardware acceleration still emerging

Integration Challenges

TLS/SSL Migration:

Certificate chain length increases significantly
Handshake time extends due to larger keys
Load balancer configurations need updates

Hardware Security Modules:

Not all HSMs support PQC yet
Firmware updates may be required
Performance characteristics differ

IoT and Embedded Devices:

Limited memory constrains key storage
Processing power affects signature operations
Update mechanisms may not support large keys

Common Pitfalls

Waiting for "Full Maturity":

No algorithm is immune to future cryptanalysis
Delaying migration increases risk exposure
Hybrid approaches mitigate uncertainty

Underestimating Scope:

Cryptography appears in unexpected places
Third-party dependencies resist updates
Testing requirements exceed initial estimates

Ignoring Performance Impact:

Production load reveals bottlenecks
Bandwidth costs increase meaningfully
Latency-sensitive systems need redesign

Key Takeaways

Start assessment now, even if full migration is years away
Hybrid cryptography enables safe, gradual migration
Performance testing under production load is essential
Plan for 2-3 year migration timelines for complex systems

The risk is real, the standards are published, and the clock is running. Organizations that start planning now will avoid rushed, expensive migrations later.

Related services: Project Chimera