← Back to Blog Research

NIST IR 8547: PQC Transition Strategy

13 min read

For most organizations, the question is not whether to migrate to post-quantum cryptography. It is how. Standards exist (FIPS 203, 204, 205). Software vendors are starting to ship PQC. But moving an enterprise from RSA and ECDSA to ML-KEM and ML-DSA is not a one-week project. There are inventories to take, vendors to push, protocols to negotiate, and compliance gates to clear.

To help with this, NIST published Internal Report 8547 in November 2024: "Transition to Post-Quantum Cryptography Standards." The document is meant for federal agencies but its framework applies to any organization. IR 8547 lays out a clear sequence: discover, prioritize, plan, deploy, validate, and retire. Each step has concrete deliverables and timelines.

This post explains what IR 8547 requires, how it aligns with the parallel CNSA 2.0 mandate from NSA, and what practical steps a security team can start taking today. It is the playbook for moving cryptography from "we use it" to "we know exactly where it lives, when it expires, and what replaces it."

The Problem IR 8547 Solves

Most organizations do not know what cryptography they actually run. Production systems have been using TLS, SSH, S/MIME, and code signing for two decades. Each layer was added by a different team. Vendors brought their own libraries. Libraries embedded their own algorithms. The result is a tangle that nobody has fully mapped.

Without a map, you cannot migrate. You cannot promise that all RSA-2048 use will be replaced by 2030 if you do not know where RSA-2048 is being used. You cannot decide which systems get priority if you cannot see the data flows.

IR 8547 starts with this discovery problem. It calls the output a Cryptographic Bill of Materials, or CBOM. The CBOM is a structured inventory of every place cryptography lives in your organization: algorithms, key sizes, protocols, libraries, certificates, hardware modules.

Phase 1: Discovery and Inventory

IR 8547 expects organizations to start by building the CBOM. Sources of inventory include:

Network traffic analysis (passive sensors looking at handshake suites)
Code scanning (static analysis on source repositories)
Configuration audits (TLS settings, SSH config, KMS exports)
Vendor questionnaires (asking suppliers what they use)
Hardware inventory (HSMs, smart cards, TPMs)

The CBOM should record at minimum: where the cryptography is used, which algorithm and parameter set, which library, who owns the system, and what data is being protected. NIST publishes a JSON schema for CBOMs aligned with the broader Software Bill of Materials (SBOM) work.

For most enterprises, the discovery phase takes six months to a year. The output is sobering: a typical Fortune 500 has tens of thousands of cryptographic uses across thousands of systems. Many use deprecated algorithms (RSA-1024, SHA-1, 3DES) that should have been retired years ago. The PQC migration becomes an opportunity to clean up.

Phase 2: Prioritization

Not every cryptographic use is equally urgent. IR 8547 suggests prioritizing based on:

Data sensitivity and lifetime: data that must remain confidential for 30 years is more urgent than session traffic
Exposure to harvest now decrypt later attacks: anything sent over a public network where an adversary could record it
Hardness of replacement: code-signing keys baked into firmware are harder to rotate than TLS certificates

The harvest now decrypt later threat is central. An attacker who records encrypted traffic today can decrypt it once a quantum computer arrives. So the priority order is roughly:

Data with long-term confidentiality requirements (state secrets, health records, financial archives)
Long-lived signing keys (root CAs, code signing, firmware)
Authentication keys with long validity (smart cards, IoT devices)
Session traffic (TLS, SSH) where compromise affects only past sessions

For more on the harvest now decrypt later threat model, see harvest now decrypt later.

Phase 3: Planning

With the CBOM and prioritization done, the planning phase produces a roadmap. IR 8547 expects this roadmap to include:

Target dates for each system or class of systems
Choice of algorithms (ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS)
Hybrid mode strategy (run PQC alongside classical during transition)
Vendor coordination (who needs to update what by when)
Testing and validation plans
Rollback procedures

The hybrid mode question is critical. NIST and IETF both recommend hybrid for the transition: combine classical (X25519, ECDSA) with post-quantum (ML-KEM, ML-DSA) so security holds if either is broken. This is what QNSQY does by default. See hybrid encryption.

Phase 4: Deployment

Deployment is where most organizations stall. IR 8547 anticipates this and provides guidance:

Start with greenfield systems where backward compatibility is not an issue
Move next to systems where you control both endpoints
Tackle ecosystem-wide protocols (TLS, S/MIME, DNSSEC) only after libraries and vendors are ready
Use hybrid suites to maintain interoperability with non-PQC peers

Deployment also requires updating monitoring. New algorithms mean new failure modes. Performance characteristics shift (ML-KEM is fast, but key sizes are larger). Operational runbooks need updating.

Phase 5: Validation

Once PQC is deployed, IR 8547 expects validation. This includes:

FIPS 140-3 testing (CMVP) for cryptographic modules
Algorithm validation (CAVP) for individual algorithm implementations
Penetration testing focused on side channels
Compliance attestation for regulated industries (HIPAA, PCI-DSS, GDPR)

Validation is not optional for federal agencies. CNSA 2.0 requires CMVP-validated modules for national security systems. Healthcare and financial industries have similar mandates. See NIST FIPS guide for the validation path.

Phase 6: Retirement

The final phase is retiring legacy cryptography. IR 8547 sets clear endpoints:

RSA, DSA, ECDH, ECDSA: deprecated 2030, disallowed 2035
3DES, MD5, SHA-1: already disallowed
New protocols negotiated after 2030 must use PQC

Retirement is harder than deployment. Some systems cannot be upgraded (embedded firmware, legacy industrial control). The plan must include compensating controls for cases where full migration is impossible.

Alignment with CNSA 2.0

NSA's Commercial National Security Algorithm Suite 2.0, published in 2022 with timeline updates in 2024, is the parallel framework for US national security systems. Its dates are tighter than IR 8547's general guidance:

2025: software/firmware signing PQC required for new development
2026: web browsers and servers in NSS supporting PQC
2027: networking protocols (IPsec, TLS, SSH)
2030: most other systems
2033: full transition

CNSA 2.0 also restricts algorithm choices: ML-KEM-1024, ML-DSA-87, SHA-2 (not SHA-3), AES-256. IR 8547 is broader (allowing ML-KEM-512 and ML-DSA-44 for non-NSS use), but the timelines align.

For organizations selling to the federal government, CNSA 2.0 is the binding deadline. For everyone else, IR 8547 sets the expected pace and gives cover for budget conversations.

Practical First Steps

If your organization is starting today, IR 8547 implies a concrete sequence:

Designate a PQC migration lead. This person owns the CBOM and roadmap.
Inventory your top 10 most sensitive data flows. Map their cryptography end to end.
Identify your long-lived signing keys. Code signing, root CAs, firmware. These are highest priority.
Pick a PQC tooling pilot. Try out a library (liboqs, Open Quantum Safe) or a product like QNSQY for file encryption.
Engage with key vendors. Ask their PQC roadmap. Many will not have one. That itself is data.
Track standards. NIST FIPS 203/204/205 are final. FIPS 209 (HQC) and FIPS 206 (FN-DSA) are coming. See NIST PQC standards timeline.

Cryptographic Agility

IR 8547 emphasizes cryptographic agility: building systems so the algorithm can change without ripping out the application. This is harder than it sounds. Many systems hardcoded RSA-2048 for 20 years and now require deep refactoring to swap in ML-KEM.

Agility design principles:

Negotiate algorithms at protocol setup, not bake them into application logic
Store algorithm identifiers in data formats (header field, OID, code point)
Wrap cryptography behind interfaces (KEM, signature, AEAD) the application can compose
Design key rotation paths from day one

QNSQY's file format includes algorithm identifiers in the QSPG v2 header so a single tool can read files encrypted with any combination of ML-KEM-512/768/1024, X25519, AES-256-GCM, or ChaCha20-Poly1305. This is cryptographic agility in practice.

Vendor Coordination

A theme throughout IR 8547 is vendor coordination. No agency or company can migrate alone. Their software vendors, hardware suppliers, cloud providers, and service partners must all support PQC. The report recommends:

Add PQC requirements to procurement language
Push vendors for explicit roadmaps with dates
Test new algorithms in vendor labs before signing
Demand FIPS 140-3 PQC validation as a contract condition

Some vendors will move fast. Others will be slow. Procurement leverage is the main accelerant. Federal agencies with their procurement scale set the pace for the broader market.

Risks and Pitfalls

IR 8547 also lists what can go wrong:

Premature deployment: shipping non-FIPS-validated PQC into regulated systems
Forgotten dependencies: subsystems using a different library quietly broken
Incomplete inventory: missing a class of systems and being surprised at audit
Hybrid mistakes: combining algorithms in ways that lose security properties
Performance regressions: PQC keys and signatures are larger, network impact uncertain

The biggest risk is doing nothing. Organizations that wait for perfect tooling will miss the deadlines. The CBOM and pilot deployments need to start in 2025 or 2026 to hit 2030 to 2033 milestones realistically.

Section-Level Reference Inside IR 8547

For practitioners reading IR 8547 directly, the document is organized in numbered sections that map to the migration phases. Section 2 covers the problem statement and threat model. Section 3 covers the algorithm landscape and the standards inventory. Section 4 covers the migration phases (discovery, prioritization, planning, deployment, validation, retirement) which form the operational core. Section 5 covers special cases including stateful hash-based signatures and hybrid mode. Section 6 covers tooling references, including pointers to the CBOM JSON schema, the CISA quantum readiness factsheet, and the NIST National Cybersecurity Center of Excellence (NCCoE) practice guides.

The NCCoE practice guides are particularly useful. SP 1800-38A (executive summary), 1800-38B (approach and architecture), and 1800-38C (how-to guides) extend IR 8547 with detailed laboratory procedures. Practitioners building a CBOM for the first time should read 1800-38B alongside IR 8547 because the practice guide includes worked examples that the report itself does not.

The companion NIST resource is SP 800-208 (stateful hash-based signatures, October 2020) which IR 8547 references for cases where LMS or XMSS is appropriate. SP 800-227 (a key derivation companion) is also referenced. Together these documents form the working set that a federal agency cryptography lead should keep open during migration planning.

FAQ

Is IR 8547 mandatory?

For US federal agencies, yes. OMB Memorandum M-23-02 directs agencies to follow NIST PQC migration guidance, which now includes IR 8547. Private sector organizations are not legally bound but face industry pressure (insurance, contracts, cyber-incident reporting requirements) that effectively makes it mandatory in regulated sectors.

How long does a CBOM take?

Six months to two years for a large enterprise. Smaller organizations can do it in weeks. The variation comes from the complexity of cryptographic uses. A SaaS company with one product is fast. A bank with 40 years of legacy systems is slow.

Does IR 8547 require hybrid mode?

It strongly recommends hybrid for the transition period. Pure PQC deployments are also acceptable but riskier because they bet entirely on the new algorithms. NIST, NSA, BSI, and ENISA all favor hybrid for the next decade. See hybrid encryption.

What about open-source software?

IR 8547 acknowledges that much of an enterprise's cryptography flows through open-source libraries (OpenSSL, BoringSSL, libsodium, etc.). It encourages contributing to these projects and tracking their PQC roadmaps. Many libraries are already shipping PQC support in 2025 and 2026 releases.

How does QNSQY fit in this transition?

QNSQY is a ready-to-use PQC cryptography tool that needs no in-house migration project. It implements ML-KEM and ML-DSA in hybrid mode out of the box, with FIPS-aligned design. For organizations starting their migration, QNSQY can encrypt critical files today while the rest of the infrastructure catches up. See pricing.

How does IR 8547 interact with FIPS 140-3 module validation timelines?

IR 8547 references CMVP (Cryptographic Module Validation Program) under FIPS 140-3 as the validation path for federal cryptographic modules. CMVP validation of PQC algorithms began rolling out in 2024 and continues through 2026 and beyond. A module claiming PQC support under FIPS 140-3 must include CAVP-validated implementations of the underlying algorithms (FIPS 203, 204, 205) and pass module-level testing. The CMVP queue length has historically been long, and module validation can take 12 to 18 months from submission to certificate. Procurement officers requiring FIPS 140-3 validation should plan vendor evaluation cycles around the CMVP timeline.

What does the CBOM JSON schema look like in practice?

The CBOM schema extends the CycloneDX SBOM format with cryptographic-asset components. Each cryptographic use is described as a component with attributes for algorithm, key size, protocol context, library, validation status, and quantum vulnerability assessment. The schema is published by NIST under the broader software supply chain transparency work. Tools including the CycloneDX command line interface, OWASP Dependency-Track, and several commercial SCA platforms can produce CBOMs from existing software inventories. For practitioners building a CBOM, the right starting point is to import existing SBOMs and annotate the cryptographic components with the additional attributes the CBOM schema requires.

Sources

NIST Internal Report 8547, "Transition to Post-Quantum Cryptography Standards," November 2024. https://csrc.nist.gov/pubs/ir/8547/final
NSA Cybersecurity Advisory, "Commercial National Security Algorithm Suite 2.0," September 2022. https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
CISA, NSA, NIST, "Quantum-Readiness: Migration to Post-Quantum Cryptography," 2023. https://www.cisa.gov/sites/default/files/2023-08/Quantum%20Readiness_Final_CLEAR_508c%20%283%29.pdf
NIST Special Publication 800-57 Part 1, "Recommendation for Key Management." https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
OMB Memorandum M-23-02, "Migrating to Post-Quantum Cryptography," 2022. https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf
NIST NCCoE SP 1800-38A/B/C, "Migration to Post-Quantum Cryptography." https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY