How to Build a NIST-Aligned Cryptographic Inventory and Migration Roadmap
Building a NIST-aligned cryptographic inventory and migration roadmap involves discovering assets across every environment, mapping dependencies and data lifetimes, prioritizing quantum risks, and establishing milestones, ownership, and verification processes to guide a controlled transition to post-quantum security.
Short answer: Find cryptographic assets by scanning every zone, including cloud, on-premise, operational technology (OT), and air-gapped systems, for algorithms, keys, certificates, and protocols. Map each asset to the data it protects and how long that data must stay secret. Then sequence migration by consequence and data lifetime against the National Institute of Standards and Technology (NIST) IR 8547 milestones: deprecate quantum-vulnerable algorithms by 2030 and disallow them by 2035.
Key takeaways:
- Scope the estate in writing before scanning, including third parties and the data you hold by lifetime.
- Combine top-down dependency mapping with bottom-up scanning, and capture the same six fields for every asset.
- Prioritize by how long protected data must stay secret, not by system age or ease of fix.
- Tie the roadmap to dated milestones: discovery by 2028, no new quantum-vulnerable deployments by 2030, high-priority migration by 2031, and full migration by 2035.
The problem this guide solves
Security leaders are being asked for a quantum-safe plan before they have the one input that plan requires: a defensible picture of where cryptography is used today.
Teams run a scan, produce a spreadsheet with thousands of rows, and then freeze because everything looks urgent and nothing is prioritized.
This guide walks through five steps that turn that spreadsheet into a NIST-aligned cryptographic inventory and a migration roadmap a security committee can approve.
Step 1: Scope the estate before you scan it
Discovery fails most often at the scoping stage, not the scanning stage.
Before any tooling runs, define the boundary in writing:
- Systems you operate: internal and externally facing
- Products you ship or embed: anything with a cryptography, communications, or data-processing function
- Networking and communications hardware: routers, switches, gateways, virtual private networks (VPNs), base stations
- Fielded and embedded devices: Internet of Things (IoT) devices, industrial control systems (ICS), sensors, end-user tokens
- Third-party and managed services: where a provider holds most of your cryptographic surface
- Data you hold: classified by expected lifetime and adversary value
The last item matters more than most teams expect. Cryptography protects data for a period of time. If the data must remain confidential past 2035, the migration deadline for the system protecting it is not 2035. It is sooner.
Step 2: Run cryptographic asset discovery across every zone
Run discovery across four zones, and treat each one as a distinct technical problem.
OT and air-gapped zones need purpose-built collection and export methods. Our guide to cryptographic discovery for critical infrastructure and defense covers both in depth.
Two approaches are needed, and they answer different questions:
- Top down: start from services and data, follow dependencies down. Answers: what matters?
- Bottom up: sweep the network and codebase for crypto primitives. Answers: what is actually there?
You need both. A top-down pass alone misses the undocumented dependency. A bottom-up pass alone produces a list with no priority.
For each asset you find, capture the same six fields:
- Algorithm and key length
- Where it lives (system, owner, zone)
- What it protects (data type, sensitivity)
- Data lifetime (how long it must stay secret)
- Dependency (what breaks if it changes)
- Renewal or rotation mechanism
That sixth field is the one that predicts how hard migration will be.
Step 3: Map quantum-vulnerable systems
Now classify. Not every asset is at risk, and not every at-risk asset is urgent.
Vulnerable to a quantum computer: Rivest-Shamir-Adleman (RSA), Diffie-Hellman, Elliptic Curve Digital Signature Algorithm (ECDSA), Elliptic Curve Diffie-Hellman (ECDH), and any public-key cryptography resting on factoring or discrete logarithms. Symmetric algorithms are weakened but not broken: the Advanced Encryption Standard with 256-bit keys (AES-256) and Secure Hash Algorithm 384 (SHA-384) remain viable, and the practical rule is to double effective key strength.
Not vulnerable: symmetric primitives at sufficient strength, hash functions at sufficient strength, and one-time-pad or physics-based key distribution.
The layer most inventories miss: entropy. A post-quantum algorithm running on a predictable random number generator is still a weak system. Weak randomness undermines key generation, tokenization, and signature schemes regardless of which algorithm sits on top. Validate entropy as part of the classification, not after it.
For each vulnerable asset, record two ratings:
- Consequence: what happens if this is broken (regulatory exposure, safety impact, intellectual property loss, mission failure)
- Harvest risk: whether the traffic or data is already exposed to collection today under a Harvest Now, Decrypt Later (HNDL) strategy
Any asset with high consequence and high harvest risk is where the program starts.
Step 4: Prioritize using data lifetime, not system age
Most organizations default to prioritizing by system age or by how easy the fix looks. Both are wrong.
The right sequence is driven by one question: how long does the protected data need to stay secret?
Layer consequence on top of lifetime. A five-year data set protecting safety-critical control systems outranks a ten-year data set in a low-consequence archive.
The output of Step 4 is a shortlist. For most organizations, that shortlist is 10 to 20 systems, not 2,000. That is the difference between a program that moves and a program that stalls.
Step 5: Build the post-quantum migration roadmap against NIST milestones
Now attach dates. Two authoritative timelines frame the work.
NIST IR 8547: quantum-vulnerable algorithms deprecated by 2030, disallowed by 2035, with high-risk systems transitioning earlier.
UK National Cyber Security Centre (NCSC) migration guidance: full discovery and initial plan by 2028, highest-priority migration complete by 2031, all migration complete by 2035.
Then convert the roadmap into an operating model, because migration is not a project:
- Ownership: one accountable owner for cryptographic inventory and one for migration execution
- Change control: what triggers a re-scan and who approves a crypto change
- Testing cadence: how you verify a system is actually using post-quantum cryptography (PQC) and not silently falling back to legacy
- Exception handling: how systems that cannot migrate are documented and compensated for
- Reporting: what goes to the security committee quarterly
The testing point deserves emphasis. A misconfigured PQC deployment does not usually fail loudly. It quietly negotiates a weaker fallback. Verify the algorithm in use, not the algorithm in the plan.
Common failure modes
- Scanning once and calling it an inventory. The estate changes weekly. So must the record.
- Treating this as a procurement exercise. Buying a tool before defining ownership produces a better-looking backlog, not progress. When you do evaluate platforms, use a structured cryptographic inventory buyer's framework.
- Ignoring third parties. If a managed service provider holds your cryptographic surface, their discovery is your discovery.
- Waiting for perfect standards. NIST has published three post-quantum Federal Information Processing Standards (FIPS): FIPS 203 for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), FIPS 204 for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), and FIPS 205 for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA). NIST states they can and should be put into use now. Planning does not need to wait for protocol standards to settle.
- Leaving entropy out of scope. Algorithm migration without entropy validation leaves the root-cause risk in place.
How enQase supports this workflow
enQase is built to run discovery and remediation in one governable path. Discovery feeds a control plane that manages encryption policy, key management, entropy, and hardware-rooted trust together, so the shortlist from Step 4 becomes a sequencing plan rather than a vendor-by-vendor integration project.
For teams working in regulated, restricted, or sovereign environments, that single path is the difference between planning migration and actually executing it.
Frequently asked questions
1. What does NIST require for cryptographic inventory?
NIST IR 8547 sets the transition timeline: deprecate quantum-vulnerable algorithms by 2030 and disallow them by 2035, with high-risk systems moving earlier. NIST directs organizations to identify where vulnerable algorithms are used and plan to replace them, and its Migration to Post-Quantum Cryptography project is developing practical guidance and tooling for that discovery and prioritization work.
2. How do I find cryptographic assets I don't know exist?
Combine top-down dependency mapping with bottom-up scanning of networks and application code. The bottom-up sweep is what surfaces hard-coded keys, legacy libraries, and undocumented integrations that no service owner will volunteer.
3. What is the first thing to migrate?
The system protecting data that must stay confidential the longest, where the consequence of compromise is highest, and where traffic is already exposed to collection. Long data lifetime plus high consequence plus existing exposure is the top of the list.
4. Is AES broken by quantum computers?
No. Symmetric algorithms are weakened by Grover's algorithm but not broken. The practical guidance is to double effective key strength: AES-256 remains appropriate. The quantum risk concentrates in public-key cryptography used for key exchange and digital signatures.
5. What should a PQC migration plan include?
A PQC migration plan should include a current cryptographic inventory, risk classification by data lifetime and consequence, a prioritized shortlist of 10 to 20 systems, dated milestones tied to NIST IR 8547, and an operating model covering ownership, change control, testing, exceptions, and reporting.
6. How long should a post-quantum migration take?
The NCSC's guidance assumes large organizations need two to three years for discovery and planning, and another two to three years for early migration work, targeting completion by 2035. Starting discovery late compresses the schedule in the most expensive way.
7. Can we migrate without replacing hardware?
Often yes for software-based cryptography, but hardware roots of trust, such as hardware security modules, secure boot chains, and embedded key storage, typically need replacement or firmware support. Identify long-lived hardware dependencies early, because they set your real critical path.
Sources: NIST IR 8547, Transition to Post-Quantum Cryptography Standards · NIST Post-Quantum Cryptography project · FIPS 203 · FIPS 204 · FIPS 205 · NIST: Migration to Post-Quantum Cryptography project · NCSC: Timelines for migration to post-quantum cryptography