NIST FIPS 203 Migration Timeline Planner
Generates a phased post-quantum cryptography (PQC) migration timeline from classical algorithms (RSA/ECC) to NIST-standardized PQC ( ML-KEM, ML-DSA) based on asset count and team capacity.
NIST FIPS 203 Migration Planner
Estimate timelines for transitioning to Post-Quantum Cryptography (ML-KEM, ML-DSA).
FIPS 203 Migration: NIST requires critical federal systems to migrate to PQC by 2035. Enterprise timelines are typically 4-8 years. This model assumes a linear migration path with a 15% complexity overhead for every 100 systems.
Risk Assessment
MODERATE: Timeline is manageable with standard staffing
| Migration Phase | Dur. | Assets |
|---|---|---|
| Phase 1: Discovery & PlanningWeek 0–4 | 4w | — |
| Phase 2: Cryptographic InventoryWeek 4–7 | 3w | — |
| Phase 3: Assessment & PlanningWeek 7–11 | 4w | — |
| Phase 4: Critical Systems MigrationWeek 11–22 | 11w | 23 |
| Phase 5: High-Risk Systems MigrationWeek 22–33 | 11w | 53 |
| Phase 6: Medium/Low Systems & CloseoutWeek 33–47 | 14w | 74 |
Strategic Oversight
- High critical system count: Consider allocating additional resources to Phase 4
- Plan post-quantum contingency: Maintain dual-algorithm support for 18-36 months after initial deployment
The Six-Phase Migration Model and What Drives Each Timeline
Post-quantum cryptography migration is not a single event but a structured programme that NIST, NSA, and the UK NCSC have all modelled as a multi-phase effort spanning several years. The six phases this tool models reflect the actual sequencing recommended in NIST IR 8547 and NSA CNSA 2.0 implementation guidance. Phase 1 is cryptographic discovery — building the CBOM inventory that identifies where RSA, ECDH, ECDSA, and finite-field DH appear across your systems, libraries, certificates, and protocols. This phase cannot be compressed below its natural duration because it depends on crawling dependencies, analysing API call patterns, and engaging system owners — typically two to six weeks for a well-staffed team with existing SBOM tooling, and three to six months for organisations starting from an undocumented codebase. Phase 2 is risk prioritisation — ranking discovered assets by confidentiality horizon and exposure. Internet-facing TLS endpoints with RSA key exchange and systems handling data with multi-year sensitivity requirements are highest priority. Phase 3 is algorithm selection and library qualification — confirming which NIST-approved library versions (OpenSSL 3.2 and later with oqs-provider, BouncyCastle 1.78 and later, AWS-LC, Microsoft SymCrypt) are available for your platforms and passing your security evaluation process. Phase 4 is parallel deployment — running hybrid classical-plus-post-quantum configurations in production alongside existing infrastructure to validate interoperability before cutover. Phase 5 is cutover — replacing classical-only configurations with post-quantum or hybrid configurations and updating certificates. Phase 6 is decommission and audit — retiring legacy algorithm configurations and documenting completion for compliance evidence.
How FTE Count and Asset Volume Drive the Timeline Calculation
The tool uses your FTE count and total cryptographic asset count to estimate phase duration. These two inputs interact because discovery and remediation are fundamentally labour-constrained activities. A single cryptography-competent engineer can inventory and assess approximately 20 to 40 systems per week depending on documentation quality, or remediate one to three systems per week depending on complexity and testing requirements. The tool applies these productivity estimates against your asset count and FTE input to produce phase-level week estimates. There is also a minimum duration floor on each phase that reflects coordination overhead — even with unlimited engineers, discovery cannot complete in under two weeks because it requires gathering inputs from system owners, running automated scanning passes, and validating results. The risk distribution slider shifts the timeline weight between phases: a high-risk distribution indicates many internet-facing or high-sensitivity assets, which front-loads discovery and qualification effort; a low-risk distribution indicates mostly internal systems with short data lifetimes, which allows a more gradual phasing. The 2030 deadline bar on the output is set to the NIST IR 8547 target date for completing RSA and ECDH retirement in internet-facing systems.
Worked Example: Mid-Sized Financial Services Firm
Consider a financial services organisation with 4 FTE assigned to the PQC migration programme, 180 cryptographic assets identified in an initial CBOM scan, and a high-risk distribution reflecting significant internet-facing TLS infrastructure and regulatory data retention requirements of 7 to 10 years. Phase 1 discovery at 4 FTE scanning 180 assets takes approximately 6 weeks — asset volume divided by per-FTE throughput of 30 assets per week times 4 FTE, plus coordination overhead. Phase 2 risk prioritisation takes 3 weeks with 4 FTE to classify and stack-rank 180 assets, identify the 40 percent flagged as highest priority, and document the prioritisation rationale for regulatory evidence. Phase 3 library qualification takes 8 weeks — testing FIPS 203 library integration in the organisation's CI pipeline, completing internal security review of the oqs-provider or equivalent, and obtaining sign-off. Phase 4 parallel deployment of the highest-priority 72 assets at a remediation rate of 2 assets per FTE per week takes 9 weeks. Phase 5 cutover for 72 high-priority assets takes 4 weeks, including certificate replacement, monitoring, and validation. Phase 6 decommission and audit takes 3 weeks. Total for the first cohort: approximately 33 weeks. The remaining 108 assets would follow in a second cohort after the first is confirmed stable, completing the full migration in 60 to 70 weeks — well within the 2030 window if the programme begins no later than Q1 2027.
Frequently Asked Questions
Commonly Asked Questions
- What is the NIST FIPS 203 standard and what algorithm does it standardise?
- NIST FIPS 203, finalised in August 2024, standardises ML-KEM — Module Lattice Key Encapsulation Mechanism — as the primary post-quantum key establishment algorithm for federal and commercial use. ML-KEM is derived from the CRYSTALS-Kyber submission to the NIST PQC standardisation process and operates on the hardness of the Module Learning With Errors problem, which has no known efficient quantum algorithm solution. ML-KEM replaces RSA and ECDH in key encapsulation and TLS handshake contexts. Three parameter sets are standardised: ML-KEM-512 targeting 128-bit quantum security, ML-KEM-768 targeting 192-bit quantum security, and ML-KEM-1024 targeting 256-bit quantum security. NIST recommends ML-KEM-768 as the general-purpose choice balancing security margin and performance.
- What is the difference between FIPS 203, FIPS 204, and FIPS 205?
- FIPS 203 (ML-KEM) is for key encapsulation — establishing shared secrets for symmetric encryption. FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) is for digital signatures — authentication, code signing, and certificate issuance. FIPS 205 (SLH-DSA, from SPHINCS+) is a stateless hash-based signature scheme providing a conservative alternative to ML-DSA for high-assurance or long-lifetime signature contexts. Most migration programmes begin with FIPS 203 for data in transit because Harvest Now, Decrypt Later attacks target key exchange, then proceed to FIPS 204 for certificate and signature infrastructure. FIPS 205 is typically reserved for firmware signing and other contexts where the signature must remain verifiable over very long periods.
- What does NSA CNSA 2.0 require and who does it apply to?
- NSA CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) specifies the cryptographic algorithms required for protecting National Security Systems — US government systems processing classified information and systems used by defence contractors. It mandates ML-KEM for key establishment, ML-DSA for digital signatures, and AES-256 for symmetric encryption, with RSA and ECDH prohibited in new NSS acquisitions immediately and required to be retired from existing systems by 2030. For non-NSS commercial organisations, CNSA 2.0 is not legally binding but represents the benchmark that US federal procurement contracts are beginning to reference, and it aligns with NIST IR 8547 guidance for non-classified systems.
- How long does a realistic PQC migration programme take for a large enterprise?
- Published case studies and NIST guidance suggest 3 to 5 years for large enterprises with complex, heterogeneous infrastructure. The primary constraints are discovery completeness — many organisations have cryptographic assets in legacy systems, third-party integrations, and embedded devices that are not surfaced by automated scanning — and vendor readiness, because migrating a system often depends on library or firmware updates from a third-party vendor who is on their own PQC timeline. The 2030 NIST deprecation target for internet-facing systems is achievable for organisations that begin discovery by 2025 to 2026 and have dedicated programme resource. Organisations beginning after 2027 face significant schedule pressure for the 2030 target.
- Which systems should be migrated first under a risk-prioritised approach?
- NIST IR 8547 and NSA guidance both recommend prioritising systems in this order: first, long-term data stores where data has confidentiality requirements extending beyond 2030, because Harvest Now, Decrypt Later makes these assets at risk today; second, internet-facing TLS endpoints with RSA or ECDH key exchange, because these are the most accessible targets for harvest attacks; third, certificate infrastructure including internal CAs and code signing systems, because certificate lifetimes and chain dependencies make migration complex; fourth, internal system-to-system communication; and finally, embedded and constrained-device systems, which typically require firmware updates and have the longest vendor dependency chains.
- Is TLS 1.3 already post-quantum resistant?
- No. TLS 1.3 standardises ECDHE for key exchange, which is quantum-vulnerable. However, TLS 1.3 supports hybrid key exchange through the supported_groups extension, and RFC 8446 permits negotiation of post-quantum or hybrid key exchange groups. Browser vendors including Google and Cloudflare have deployed X25519Kyber768 — a hybrid combining X25519 and ML-KEM-768 — in production TLS. For an organisation to benefit from post-quantum TLS, both the server and client must support a hybrid or pure post-quantum group, and the server-side TLS library must be updated to a version that includes ML-KEM support (OpenSSL 3.2 with oqs-provider, or BouncyCastle 1.78 and later).
- What evidence do regulators expect organisations to produce for PQC compliance?
- NIS2 Directive implementation across EU member states is beginning to incorporate post-quantum migration expectations into technical measure assessments under Article 21. UK NCSC guidance explicitly recommends CBOM production and a documented migration plan as evidence of managing cryptographic risks. For US federal suppliers, FedRAMP is expected to incorporate FIPS 203 requirements into its control baselines. The minimum evidence package regulators and auditors are converging on includes: a completed CBOM documenting all cryptographic assets, a risk-prioritised migration roadmap with target completion dates, evidence of test deployments for highest-priority systems, and a vendor readiness register tracking third-party migration commitments. This tool's output — the phased timeline — forms the migration roadmap component of that evidence package.