Turning NIST SP 1800-38 Into a Governance Work Plan

NIST published the preliminary drafts of Special Publication 1800-38 in December 2023, with more than two dozen organizations contributing tools, implementations and test results. AWS, IBM, Microsoft, Samsung SDS, Entrust, PQShield and wolfSSL are among them.

A governance, risk and compliance team can read the document for something other than the cryptography. The three volumes are a record of a group of vendors attempting a migration to post-quantum cryptography, or PQC, in a shared lab, writing down what broke, and publishing the results. Most guidance on PQC will tell you the work is large. This one shows where the hours go.

How the Guide Relates to Your Obligations

SP 1800-38 came out of the National Cybersecurity Center of Excellence, or NCCoE, which is NIST’s applied cybersecurity lab. Its output is a practice guide, and a practice guide carries no compliance obligation. No auditor is going to ask whether you followed it.

The obligations come from elsewhere. In the United States, Office of Management and Budget (OMB) Memorandum M-23-02 requires federal agencies to produce and submit prioritized inventories of cryptographic systems. National Security Memorandum 10 sets the broader federal migration direction. Outside government, the pressure arrives through contracts, as customers in financial services, defense supply chains and critical infrastructure begin asking suppliers for migration plans and inventory evidence.

So read SP 1800-38 as method rather than mandate. The three volumes divide the work. Volume A carries the executive framing, Volume B cryptographic discovery, Volume C interoperability and performance testing.

Volume A and the Two Deliverables

Volume A makes a short argument that a GRC team can lift straight into a steering paper. Two things must exist before a migration plan means anything. One is an accurate inventory of where cryptography is used. The other is a risk-based roadmap that puts systems in order. The NCCoE authors add a third observation, which is that most deployed systems were never designed to have their algorithms changed at all.

For governance purposes those are deliverables with owners and dates, not concepts. The inventory belongs to whoever owns asset management. The roadmap belongs to whoever owns the technology risk register. If neither has been assigned, the migration hasn’t started, whatever the slide deck says.

Volume B and the Inventory Problem

Volume B covers cryptographic discovery. The central artifact is a cryptographic bill of materials, usually shortened to CBOM. It is an inventory that records which algorithms, key sizes, certificates, protocols and libraries each system uses, and where each one is implemented. Think of it as a software bill of materials, or SBOM, narrowed to the cryptographic components and extended to include configuration.

In the lab, the NCCoE team split discovery into three domains. The first is the build pipeline, where source code and dependencies are scanned before deployment. The second is running systems and applications, scanned by agents. The third is the network, where traffic analysis and certificate collection reveal what production systems actually negotiate. Outputs from several tools are normalized, correlated into a single view, and then ranked by risk.

We would copy the design decision that follows from this. No single scanner found everything. Code scanning misses cryptography that arrives inside a binary dependency, network analysis misses an algorithm that is configured but never negotiated, and certificate discovery says nothing about how an application handles symmetric keys.

Three consequences follow for a GRC function. First, “complete” needs a written definition before tooling is selected, or the inventory will be measured against an expectation nobody agreed to. Define it by scope, naming which environments, which asset classes and which third-party services are covered, and what evidence counts as coverage. Second, discovery is a standing process rather than a project, because new cryptography enters the estate with every release. Third, and hardest, ownership has to be assigned to people who currently have no reason to know the answer. The NCCoE authors put it plainly: system owners often don’t know their components contain cryptography.

There is a precedent for this. 15 years ago, most large organizations could not produce an accurate list of the hardware and software they ran. Configuration management databases, the systems of record for that question, were half-populated and quietly distrusted. It took a decade of process work, discovery tooling and audit pressure before inventory became routine, and a better database was never the main ingredient. Cryptographic inventory is at the start of the same arc – with considerably less time available.

Volume C and the Price of Interoperability

Volume C moves the migration out of theory. The contributors built a non-production test environment and ran post-quantum algorithms through the protocols enterprises actually depend on: TLS 1.3, SSH, X.509 certificates, QUIC and hardware security modules. A TLS handshake is the short negotiation at the start of an encrypted connection, where two systems agree on keys and prove their identities. It is the first place an algorithm change becomes visible.

Two findings apply to any enterprise program. The first concerns compatibility. Where both ends implemented the same algorithm and the same draft specification, connections succeeded. Where one library had moved to a newer draft and its counterpart had not, the two stopped talking. That failure mode is ordinary for a technology mid-standardization and will fade as implementations settle onto ratified specifications. It also names two budget items, integration testing across every pairing you care about, and patch discipline while libraries converge.

The second finding concerns performance, and it runs against the common assumption. Post-quantum key establishment is not inherently slow. In the NCCoE measurements, lattice-based key exchange was competitive with classical elliptic curve exchange, and at higher security levels it was faster. The cost appears in hybrid mode, where a system runs a classical algorithm and a post-quantum algorithm together so the connection holds if either one survives. Hybrid handshakes roughly halved server-side throughput, because the server performs both computations. Since hybrid is the sensible default through the transition, capacity planning has to assume it.

One translation note for anyone reading the December 2023 drafts. The tests used the draft names ML-KEM (CRYSTALS-Kyber) and ML-DSA (CRYSTALS-Dilithium). NIST finalized both in August 2024, as FIPS 203 and FIPS 204 respectively, alongside SLH-DSA in FIPS 205. Cite the revision you actually read, and check whether a later draft supersedes the finding you are quoting.

Vendor Roadmaps Become a Contract Question

The lab results hand procurement and vendor management a concrete question set. For each supplier holding or transmitting sensitive data, ask which post-quantum algorithms the product supports today, which specification the implementation follows, whether hybrid modes are available, and what the upgrade path looks like for versions already deployed. Answers to those four questions turn a vague supplier concern into a dated dependency you can track on a register.

Crypto Agility as a Requirement

Crypto agility means a system can change its cryptographic algorithms without being redesigned. Most estates today don’t have that property, and the NCCoE authors return to the point throughout all three volumes.

Write agility into two places. In architecture standards, specify that algorithm selection is configuration rather than code, that certificate profiles can be updated without a release, and that key sizes are never hard-coded. In procurement, make agility a testable acceptance criterion instead of a marketing claim. Ask the supplier to demonstrate an algorithm change in a test environment before signature.

Hybrid certificates, which carry both a classical and a post-quantum signature, show what that costs in practice. They keep older systems working through the transition, and they also increase certificate size and can complicate path building and validation policy decisions. Public key infrastructure, or PKI, teams need this on their roadmap now, because certificate lifecycles are measured in years.

Four Artifacts to Take From the Guide

A practice guide becomes useful once it turns into paperwork someone owns. The four artifacts below are the ones we ask governance teams to produce, and together they convert SP 1800-38 into a work plan.

1. A scope definition for discovery. One page, agreed before tooling is selected, naming the environments and asset classes in scope and the evidence that counts as coverage.
2. A cryptographic inventory with a refresh cycle. The CBOM itself, plus the process that keeps it current and the named owner who signs it off each quarter.
3. A prioritized system list keyed to data lifetime. Rank systems by how long their data must stay confidential rather than by how visible they are. Encrypted traffic captured today can be stored and decrypted years later, the problem usually labelled harvest now, decrypt later, so a system protecting records with a 10-year confidentiality requirement moves ahead of one protecting a session that ends this afternoon.
4. A budget line for testing and capacity. Integration testing across vendor pairings, plus server headroom for hybrid handshakes on whichever systems terminate the most connections.

Building the Capability

In our experience most programs stall on staffing rather than on documentation. Reading Volume B and converting it into a scope definition, or reading Volume C and converting it into a capacity estimate, takes people who have done that kind of work before. Cryptographic inventory, migration prioritization and supplier assessment are becoming standing responsibilities inside GRC functions, and they need trained people the same way vulnerability management did.

For the technical walk-through of the volumes themselves, PostQuantum.com covers the release in detail, and pqcframework.org sets out methodology for sequencing the migration once the inventory exists.

Quantum Academy’s training programs cover this ground for governance and compliance teams: cryptographic discovery and CBOM construction, migration planning against regulatory deadlines, and the procurement questions that follow. You can review the current programs at quantumacademy.com/.