NIST Releases SP 1800-38: A Roadmap for Migration to Post-Quantum Cryptography

Table of Contents
23 Dec 2023 – The National Institute of Standards and Technology (NIST) unveiled Special Publication (SP) 1800-38, “Migration to Post-Quantum Cryptography,” a comprehensive practice guide to help organizations prepare for the quantum era. This guide, developed through the NIST National Cybersecurity Center of Excellence (NCCoE), is structured into three volumes (A, B, and C) and was produced in collaboration with over two dozen industry players – including Amazon Web Services (AWS), IBM, Microsoft, Samsung SDS, Entrust, PQShield, wolfSSL, and many others.
The release of SP 1800-38 signals a significant effort to raise awareness and provide practical tools for the coming transition from today’s cryptography to quantum-resistant alternatives.
Volume A (Executive Summary)
Volume A offers a high-level overview of the project’s purpose and findings. It explains why planning for post-quantum cryptography (PQC) must start now, noting that advances in quantum computing could eventually crack widely used public-key algorithms (RSA, ECDH, ECDSA, etc.). NIST emphasizes that many current systems lack crypto agility – they weren’t designed for rapid cryptographic upgrades – and organizations often don’t even know where all their cryptography is used.
Volume A frames the central challenge: enterprises need an accurate cryptographic inventory and a risk-based migration roadmap before large-scale quantum computers arrive. It also previews the two major workstreams covered in the later volumes: (1) using discovery tools to find vulnerable cryptography in your environment, and (2) testing quantum-ready solutions for interoperability in common protocols like TLS, SSH, and X.509 certificates.
Volume B (Cryptographic Discovery Guidance & Architecture)
Volume B, “Quantum Readiness: Cryptographic Discovery,” dives into how organizations can discover and inventory their cryptographic assets. It provides a functional test plan for evaluating crypto discovery tools, a sample use-case scenario, a threat analysis, and a high-level architecture for automating the discovery of quantum-vulnerable cryptography across an enterprise.
In this lab demonstration, NIST and its collaborators integrated multiple contributed tools – for scanning source code, binaries, network traffic, and certificates – into a unified workflow. The conceptual architecture covers discovery in three domains (the CI/CD code pipeline, operational systems/applications, and network services) feeding into a central analysis engine. The output from various scanners is normalized and correlated, then run through a risk assessment to prioritize which vulnerabilities to address first.
Volume B highlights that building a Cryptographic Bill of Materials (CBOM) or inventory is now an urgent need. It notes that most organizations lack full visibility into where cryptography is used in their systems, which makes it hard to prioritize what to fix. The guidance suggests starting immediately by expanding existing asset inventory processes to include cryptographic components.
A key contribution of Volume B is demonstrating a “multifaceted discovery approach” – using multiple tools in tandem – since no single product may find all instances of vulnerable crypto. The project’s lab setup included tools from consortium members (e.g. code scanning by AWS CodeQL, system scans by IBM and Samsung SDS agents, network traffic analysis by InfoSec Global, etc.), showing how combined outputs can give a more complete picture. All of this feeds into the broader goal of helping organizations develop a crypto inventory and migration playbook, aligned with risk management practices.
Volume C (Interoperability & Performance Testing)
Volume C, “Quantum Readiness: Testing Draft Standards for Interoperability and Performance,” documents hands-on testing of leading post-quantum algorithms in real-world use cases. It focuses on ensuring that quantum-resistant cryptography works in practice with today’s protocols and products.
The NIST NCCoE team and collaborators set up a non-production test environment to integrate draft PQC algorithms (like CRYSTALS-Kyber for key exchange and CRYSTALS-Dilithium for digital signatures) into common protocols: TLS 1.3, SSH 2.0, X.509 certificate infrastructure (including hybrid certificates), QUIC, and even hardware security modules (HSMs). Over a dozen organizations contributed implementations – for example, Open Quantum Safe’s OpenSSL fork, AWS’s s2n TLS, wolfSSL, Crypto4A and Thales for HSMs, and others. Volume C reports on two key aspects: interoperability (do different vendors’ implementations of PQC work together?) and performance (what is the throughput or latency impact of PQC algorithms?).
One set of tests checked whether various TLS 1.3 clients and servers (from different vendors) could negotiate PQC-based key exchange and authentication. The guide defines multiple “profiles” – e.g. Profile 1 using a PQC key exchange (Kyber at NIST security levels 1, 3, 5) with classical ECDSA signatures, and Profile 2 using both PQC key exchange and a PQC signature (Dilithium) to meet the upcoming CNSA 2.0 suite requirements.
The interoperability matrices in Volume C show generally positive results – if an algorithm was supported on both sides, the connections succeeded – but also highlight gaps where some implementations hadn’t yet added certain algorithms or draft specifications diverged. For example, in Profile 1 TLS testing, five different TLS stacks (OQS OpenSSL, wolfSSL, AWS s2n-tls, OQS Nginx, and Samsung SDS’s PQC-TLS) were configured with Kyber and hybrid ECDH+Kyber key exchanges. Most combinations worked across vendors, though the AWS s2n-tls (at the time) did not support the PQC cipher suites yet (shown as “N/A” entries). Notably, one pairing in SSH tests was marked “Pending” for wolfSSL – indicating an implementation bug or draft update in progress during the test. These nuances are exactly what interoperability testing is meant to surface.
Another major section of Volume C covers performance benchmarking. While security leaders might assume post-quantum algorithms are “slower,” the reality is nuanced. The NIST team measured TLS handshake throughput (handshakes per second) using Open Quantum Safe’s OpenSSL integration and other stacks, comparing classical vs. post-quantum operations. For instance, using Kyber for key exchange was actually more efficient than RSA/ECDH at higher security levels – Kyber-768 and Kyber-1024 handily outperformed classical ECDH P-384 and P-521 in their tests. At the lowest security level, Kyber-512 was slightly less efficient than an optimized classical curve (P-256) but in the same order of magnitude. However, hybrid modes (combining classical ECDH with Kyber in one handshake) showed roughly half the throughput of using either alone, since the server had to do both computations. Volume C provides tables of raw numbers – an excerpt is shown below – to quantify these impacts. As an example, in one scenario at security level 5, a pure Kyber-1024 key exchange achieved ~667 handshakes/s, versus ~192 handshakes/s for classical ECDH P-521; but the hybrid P521+Kyber-1024 dropped to ~110 handshakes/s. The takeaway: post-quantum algorithms can be fast, but hybrids and larger key sizes will tax servers more, which enterprises must account for in capacity planning.
Overall, Volume C’s interoperability and performance findings are meant to accelerate real-world adoption. By identifying compatibility issues early – for example, how draft standards for PQC in TLS, SSH, and X.509 might conflict or need clarification – the project helps standards bodies and vendors address them before final PQC standards are rolled out. NIST has demonstrated working prototypes of “hybrid certificates” (combining traditional and PQC signatures in one X.509 certificate) and found that all major vendors’ TLS implementations could successfully negotiate hybrid modes when implemented consistently.
The collaboration in this project (spanning academic, industry, and government) reduced duplication of effort by creating a shared knowledge base of what works and what doesn’t. As the guide notes, one goal is to “reduce the time spent by individual organizations performing similar interoperability testing for their own PQC migration efforts.”
From the Trenches: Why SP 1800-38 Matters for CISOs
As a cybersecurity consultant and technology risk leader, I find NIST SP 1800-38 to be a timely and pragmatic wake-up call for CISOs and their teams. In years past, quantum computing was a distant academic topic. Now, with NIST’s PQC standards imminent and experts predicting quantum attackers could emerge within a decade, procrastination is not an option. Here are a few key insights and why they demand attention at the executive level:
Discovering Your Cryptography is Hard (and Urgent)
One striking takeaway is just how little many organizations know about their own cryptographic footprint. Volume B effectively says: you can’t protect what you can’t find. Most enterprises lack a comprehensive cryptography inventory; crypto is embedded everywhere (in applications, network protocols, IoT devices, cloud services) and often “owners are unaware of what components have cryptography embedded or how it’s used”.
NIST’s guidance to build a cryptographic inventory or CBOM is crucial – and it’s not just a technical exercise, but a governance one. As a former CISO, I see this as analogous to asset management 10-15 years ago: we needed inventories of hardware and software then, and now we need inventories of algorithms and keys. The fact that NIST is providing a testbed and even open-source data (the project plans a repository of tool outputs) underscores that automated tooling is the only viable way forward. Manually combing through code or configurations for RSA or ECC usage is impractical at any reasonable scale.
I believe we’ll see cryptographic asset management become as standard as vulnerability management – an accepted part of security programs. For CISOs, a near-term action is to initiate a crypto discovery project: pilot one of the tools or approaches from Volume B and start illuminating where your organization relies on potentially vulnerable crypto. This inventory forms the foundation of a PQC migration roadmap.
Interoperability Challenges Are Real (But Solvable)
Volume C’s testing might seem very technical, but it carries an important message for decision-makers: expect bumps in the road during the PQC transition. Even in these early trials, the consortium hit issues where implementations didn’t initially work together due to ambiguities in draft specs or version mismatches. For example, when one SSH library was updated to a newer draft of the hybrid key exchange and another was not, they could no longer communicate. This is normal for emerging tech – and it means organizations should plan for careful testing and perhaps phased rollouts of quantum-safe crypto.
The good news is that by the time standards are finalized, many of these kinks will have been ironed out (indeed, the NCCoE team notes that certain issues “would not occur when implementers start from a ratified, stable specification.”). However, enterprise security leaders should budget extra time and resources for integration testing when introducing PQC into systems. In practice, this may mean working closely with vendors (VPN providers, TLS library maintainers, etc.) and staying on top of patch cycles as PQC support matures.
The NIST project’s emphasis on collaboration has effectively jump-started this process for everyone – by identifying, say, that a draft TLS spec needed clearer guidance on how to encode hybrid public keys, they’ve given feedback to standards bodies and vendors that will make the eventual deployments smoother for all of us. As a CISO, I appreciate that Volume C provides reassurance that “PQC will work in practice” – but it also implicitly warns that enterprises must not wait until the last minute. Testing your critical systems with PQC (even in a lab) in advance will prevent unpleasant surprises down the line.
Crypto Agility and Hybrid Approaches Mark a Cultural Shift
Perhaps the biggest strategic change reflected in SP 1800-38 is a new mindset around crypto agility. Historically, once we installed encryption, we tended to “set it and forget it” for a decade or more – cryptography was seen as static plumbing.
NIST is signaling that those days are over. The guide repeatedly stresses designing for agility, meaning building systems and policies that can accommodate algorithm changes or upgrades with minimal friction. This is a cultural shift: it means security and IT teams will need processes to update cryptographic components regularly (similar to how we handle software patching). It also means engaging vendors about their roadmap for supporting PQC and agility.
I’ve observed in client organizations that the concept of “crypto agility” is still nascent – many don’t have it on their radar. But NIST including a “Cryptographic Agility Index” concept in the project and showcasing hybrid certificate solutions signals that regulators and industry groups will likely push agility as a requirement. The use of hybrid certificate formats in Volume C is especially noteworthy: for a transitional period, we may use certificates that contain both a classical and a post-quantum signature. This allows compatibility with older systems while introducing PQC, but it also means our certificate management processes get more complex.
As a risk manager, I interpret this as NIST urging organizations to embrace flexibility in cryptography. Concretely, CISOs should ensure their crypto architects and PKI teams are exploring support for composite/hybrid certificates and are designing systems that can swap out algorithms (e.g. support multiple cipher suites, update firmware on HSMs, etc.). In the long run, building crypto agility will reduce the cost of future migrations – whether due to quantum threats or new classical vulnerabilities.
Proactive Roadmapping to Mitigate PQC Transition Risk
Finally, SP 1800-38 drives home the point that planning and prioritization must start now – not when the day arrives that a quantum computer is online. There’s a compelling rationale in the documents about the “harvest now, decrypt later” threat: adversaries may be recording encrypted data today that they can decrypt in the future with a quantum computer. This means certain sensitive data (think long-term secrets, healthcare records, state secrets) are already at risk if we don’t transition in time.
From a CISO’s perspective, that threat translates into business risk that needs addressing on our roadmap. NIST’s guide suggests creating a quantum-readiness roadmap that ties into overall risk management. I strongly agree: CISOs should be leading a cross-functional effort – involving enterprise architects, cryptographers, IT ops, and vendor management – to plot out the steps to quantum-safe cryptography. This includes inventorying all cryptographic dependencies (applications, protocols, third-party services), assessing which are most critical or most vulnerable, and engaging vendors about their plans. It also involves prioritizing which systems to upgrade first (perhaps internal systems and VPNs that protect highly sensitive data), and which can wait.
Volume B provides a sample of how a fictional company did this triage: identifying critical business processes and mapping them to systems that use vulnerable crypto, then tackling the highest-risk ones first. In practice, I advise starting with an impact analysis: what would break if we turned off RSA/ECC tomorrow? That helps reveal where to focus remediation. The NCCoE publication essentially arms CISOs with talking points and evidence to make the case for investing in PQC preparedness now, rather than deferring until standards are finalized. Given that NIST aims to finalize initial PQC standards by 2024, and U.S. federal agencies have been mandated to begin migration planning (per White House directives and OMB Memo M-23-02), the clock is already ticking.
In summary, NIST SP 1800-38 (Volumes A, B, C) is more than just a technical guide – it’s a roadmap that bridges high-level strategy and hands-on implementation for the post-quantum crypto transition. For CISOs, it provides both validation (that yes, this is a real issue warranting attention) and a toolkit (frameworks to discover, test, and plan) to address the issue proactively.
My recommendation is to use this publication as a springboard for internal discussions: brief your executive team on the looming quantum risk in business terms, leverage Volume A’s points to explain why action is needed now, and perhaps even demonstrate a discovery scan (Volume B style) or a lab validation of a PQC-enabled system (Volume C style) to build momentum.
The migration to post-quantum cryptography will be one of the largest cryptographic upgrades in decades – but with early planning, collaboration, and agility, we can mitigate the risk and turn it into a manageable evolution of our security posture rather than a chaotic scramble.