Lesson 1.6 introduced the NIST deprecation timeline. This lesson applies it. The abstract dates become concrete when you map them to a specific sector, a specific system inventory, and a specific migration lead time. The calculator and scenario explorer below turn the schedule from a policy document into a planning tool.
Unit 2 progress — final lesson
By the end of this lesson you will be able to
Calculate the effective migration deadline for a specific sector and system type
Explain why enterprise migrations that haven't started by 2027 risk missing the 2035 hard cutoff
Describe the key differences in urgency between regulated sectors and SMBs
Apply the deprecation schedule to a specific organizational scenario
Identify the first action item in the deprecation schedule for your context
Part 1 — Your sector, your deadline
The NIST 2030 deprecation and 2035 disallowed dates are the floor. Your actual effective deadline depends on your sector, the systems you operate, and how long your migration will realistically take. Use the calculator to find your deadline.
Sector deadline calculator
Your sector –
Your most complex system type –
Effective deadline
–
–
Migration lead time needed
–
–
–
Part 2 — Why 2035 is not as far away as it sounds
Eleven years sounds comfortable. It is not, not for organizations with complex cryptographic infrastructure. Enterprise PKI migrations have historically taken 3 to 7 years from the beginning of planning to full completion. Here is why the timeline compresses fast.
2024–2025
Standards finalized. Awareness phase. Migration planning begins in leading organizations. Most enterprises have not yet started.
2025–2026
CBOM discovery phase: 6–18 months to inventory all cryptographic assets across enterprise systems. This must happen before any migration begins.
2026–2027
Vendor dependency resolution: HSM firmware updates, smart card procurement, TLS library upgrades, VPN appliance updates. Many vendor timelines are 12–36 months from order to deployment.
2027–2030
Active migration execution: CA hierarchy migration (12–24 months), certificate replacement across all systems, protocol configuration changes, testing, validation.
2030
RSA and ECC formally deprecated for new systems. Organizations still using them in regulated contexts face compliance scrutiny. Migration must be substantially complete.
2030–2033
Long-tail migration: legacy systems that could not be updated in earlier phases, remaining IoT hardware replacement, final certificate lifecycle turnover.
2035
Hard cutoff. RSA and ECC disallowed for any use in systems subject to NIST guidelines. No grace period. Legacy systems must be decommissioned or isolated.
The implication is direct: an organization that begins CBOM discovery in 2027 is starting the migration process only 8 years before the hard cutoff, and with a 3–7 year migration horizon, they will finish in 2030–2034. That is inside the margin, but with almost no buffer for vendor delays, organizational complexity, or scope surprises. Organizations that have not started planning by 2026 are not comfortably ahead of schedule, they are beginning to fall behind.
Part 3 — Sector scenarios: what the schedule means in practice
The same NIST dates produce very different urgency profiles depending on sector. Explore each scenario.
BFor SMB decision-makers: the SMB scenario above is your realistic picture. You do not face the same hard deadlines as federal agencies or financial institutions, yet. But the "vendor-driven" migration means you are subject to your software vendors' timelines whether you plan for it or not. The organizations that manage this transition well are the ones who know what is coming and can respond to vendor migration prompts without scrambling.
CFor IT professionals: your effective deadline depends on your sector and your most complex systems. If you have IoT or smart cards, your planning horizon is the longest, begin now. If your environment is primarily TLS and software certificates, you have more time but should still be in active planning. The CBOM exercise in Unit 3 gives you the structure to make this concrete: you cannot plan a migration you cannot see.
Part 4 — Your first action item
Every lesson in Unit 2 has pointed toward one output: the Vendor Evaluation Worksheet that closes this unit. But before you get there, here is the single most important first action item that the deprecation schedule demands from each persona.
A
First action: Complete the Unit 2 Vendor Evaluation Worksheet. Then pick one real vendor whose product you use and run the same five-question framework against their public documentation. Document the result. That is your first real PQC due diligence exercise, and a career-ready artifact.
B
First action: Make a list of every software vendor and cloud service your business uses that handles sensitive data or authentication. Then ask each one for their PQC migration roadmap. The ones who cannot answer are your highest-priority vendor risk items. The Vendor Evaluation Worksheet gives you the framework for scoring each response.
C
First action: Identify the three systems in your environment with the longest migration lead times, likely your HSMs, smart cards, or IoT devices. Those are the systems that need planning to start now. For everything else, TLS key exchange migration (Track 1) is deployable today. Enabling hybrid ML-KEM on your public-facing TLS endpoints is a concrete, measurable first migration milestone you can report to leadership.
Unit 2 deliverable — Vendor Evaluation Worksheet
You have completed all six lessons in Unit 2. The unit deliverable is next: a fictional vendor's PQC product page, evaluated against the three criteria you have spent this unit building. The worksheet takes 15–20 minutes and produces an artifact that Persona B can use with a real vendor tomorrow.
Is this claim FIPS-validated or only algorithm-compliant? What is the difference?
What PQCMM level does this product appear to meet based on the evidence presented?
What three questions would you ask this vendor before purchasing or renewing?
An enterprise CISO says: "We have until 2035 before RSA is disallowed. We have plenty of time, we'll start planning in 2028." What is the most accurate assessment of this position?
Question 2 of 3
A healthcare organization stores patient records required to remain confidential for 30 years. They encrypt all data in transit using TLS with ECDH key exchange. How does the Mosca inequality apply to their situation?
Question 3 of 3
Why do organizations with large IoT deployments face a longer effective migration lead time than organizations whose cryptography is primarily in software?