The Vulnerability Database Is Being Rebuilt Without a Word About Cryptography
Ask the engineer who keeps a municipal water system running which of her controllers still rely on RSA, and how long that answer will stay true, and you will get a pause and a spreadsheet. The pause is not carelessness. It is that one of her two questions has a public answer and the other does not. Whether a device carries a known software flaw is something she can look up in seconds, for free, in a federal repository that has answered exactly that question for a generation. For the second question there is no comparable starting point — no public record that says which cryptographic algorithms that model implements in the first place. She would still have to check what her own units are configured to use; no database can know that. But she would not be starting from nothing.
On August 12, 2026, the National Institute of Standards and Technology asked the public how the first of those repositories should be rebuilt. The request for information on modernizing the National Vulnerability Database in the age of artificial intelligence (Federal Register document 2026-16371, docket 260805-0401) opens a comment window that closes at 11:59 p.m. Eastern on October 13, 2026. It is a serious document, and it is the most consequential thing NIST has published this month. It also never once uses the word cryptography.
Practical takeaway. The federal vulnerability repository is being redesigned in public, on a docket that closes October 13, 2026, and the questions on the table are about AI-assisted triage and remediation — not about recording what cryptography runs where. Whether the modernized database acquires a cryptographic dimension is being decided now, by whoever writes in.
What the notice actually asks
The RFI is organized around seven groups of questions. Four are operational: where the bottlenecks in the vulnerability lifecycle sit and which are appropriate for AI-enabled automation; how vulnerability information should be disseminated and which standards gaps block that; how risk prioritization can be made contextual and auditable; and what controls are needed before AI-generated remediations are trusted to touch production systems. The last three are more architectural, and they are the ones worth reading twice: Vulnerability Data and Standards, Development Processes, and Vision for the NVD. NIST states its own diagnosis plainly — that approaches centered on "periodic scanning, static prioritization, and manual remediation" are showing their limits, while "malicious actors may seek to leverage AI systems to discover and exploit vulnerabilities at scale."
Against a text search the omission is exact rather than impressionistic. The notice does not contain the string cryptography in any form. It does not contain post-quantum. It does not contain software bill of materials, or its cryptographic cousin. But the absence of the word is not the absence of a door. Question 4(e) asks what "process and organizational dependencies" are prerequisites for automating remediation, and names discovery and asset inventory as its own example. Question 5(c) asks flatly what gaps exist in current standards and specifications for vulnerability data; 5(e) asks what would improve machine-readable vulnerability data. Question 7(b) asks what capabilities should be integrated into the database over the next five years.
So the openings are there, and they are unlabelled. Anyone who thinks cryptographic properties belong in the public record has three or four places to say so and no prompt inviting it — which is not a closed door, but is not an agenda either. Consultations are answered by the constituencies that recognize themselves in the questions.
Speed was never the constraint
It is worth being fair to the existing system, because the popular story about the NVD is a story about backlog, and the RFI tells a more precise one. The database ingests CVE records within approximately an hour of publication, automatically. The queue forms afterward, at the enrichment step, where human analysts add severity scores and affected product versions. NIST names the pressure honestly: "resource constraints associated with scaling vulnerability analysis and enrichment activities." Applying machine assistance there is a reasonable thing to want, and much of the RFI is a careful attempt to work out which parts of that judgment can safely be delegated and which cannot.
But throughput is only one kind of limit. The other is structural, and no amount of automation touches it: a register can only answer the questions its schema anticipated. A CVE record says that a named product at a named version has a named flaw. It does not say which key exchanges that product implements, which signature algorithms its firmware will accept for an update, or what it falls back to when a peer refuses the modern option. Those are not vulnerabilities in the sense the schema was built for. They are product properties — and, as the next section argues, a decade of migration policy has quietly come to lean on someone recording them.
It is worth marking the limit of that claim, because it is easy to overstate. No central database can tell an operator what she has actually deployed; configuration is local, it drifts, and discovering it will always require looking at her own estate. What a public record can supply is the other half of the problem — the reference layer that says what a given product version is capable of, so that local discovery has something to resolve against instead of being re-derived, vendor by vendor, by everyone independently. Public metadata would not replace local discovery; it would make local discovery cheap.
Two calendars that do not cite each other
Two years ago this month, NIST finalized the first three post-quantum encryption standards — FIPS 203, 204 and 205. That was the moment the technical question stopped being open and the institutional one started. Since then the surrounding legal furniture has been assembled, though it is worth being precise about what it does and does not say. In Europe, the NIS2 directive requires essential and important entities to adopt risk-management measures that expressly include "policies and procedures regarding the use of cryptography and, where appropriate, encryption," and it places responsibility for approving those measures on management bodies; in the Netherlands, the implementing Cyberbeveiligingswet and Cyberbeveiligingsbesluit take effect on August 15, 2026 — three days after this notice published, in the same week, with no relationship between the two events except the one a reader has to construct.
Neither instrument writes down a post-quantum migration duty, and neither orders anyone to keep a cryptographic inventory. That inference is ours, and we state it as an inference: a policy about the use of cryptography that cannot be checked against real deployed systems is not a policy an auditor can test, and the practical route from a written policy to a defensible one runs through knowing what is deployed. It is the unglamorous precondition beneath the whole program, and it is nowhere assigned. We have argued before that the interesting question about a new cryptanalytic result is rarely the mathematics and almost always what would have to hold for it to reach a deployed standard; the same asymmetry applies here in reverse. The algorithms were the part that got finished. The bookkeeping that makes an algorithm change actionable was never assigned to anyone in particular, and the public data layer that would carry it is, this week, being redesigned around a different problem.
Who gets an inventory, and who does not
None of this is a gap in the market. A commercial tooling category for cryptographic discovery and inventory has grown up alongside the standards, and an organization with a security budget can procure the answer to the engineer's second question rather than derive it. The capability exists; what it costs is what varies.
That is the distributive point, and it is why a comment docket is worth caring about. The NVD's defining property is not that it is comprehensive but that it is free, public, and machine-readable — which is what makes it usable by operators who cannot buy their way to an answer. The Bulletin of the Atomic Scientists has reported this month on how badly outmatched America's water systems are, and its account of the mismatch is about knowledge, resources and available talent rather than indifference — in a sector whose control equipment has service lives measured in decades. When a duty is written into law, who can discharge it is settled less by the statute than by whether the underlying facts are cheap to obtain. A public repository that recorded cryptographic properties would not do the small operator's work for her, but it would give her the same reference layer the large bank's tooling already assembles for itself. Without one, the duty stays formally universal and the head start stays purchasable.
There is a reasonable counterargument, and it deserves stating: cryptographic inventory may simply not be the NVD's job. Vulnerability data and configuration data are different things, and stuffing the latter into a schema built for the former could degrade both. That may be right. It is also exactly the kind of architectural judgment the RFI says it is collecting — the notice states that responses will inform "future strategic planning, technical architecture decisions, standards and best practices development, data governance approaches." If the answer is no, it should be a decided no, on a record, rather than an omission nobody noticed.
How Quentir Reads It
Consultations are where infrastructure gets its shape, and they are consistently underused by the people who will later be governed by the result. This one is unusually accessible: a numbered docket, a named contact at NIST, a portal submission, no requirement that a respondent be American, and a two-month window. Nothing about the process privileges large vendors except that large vendors reliably show up. The strategic reading is that the post-quantum transition has entered the phase where its binding constraints are administrative rather than mathematical. We made a version of this argument when the post-quantum web arrived as a platform setting rather than as a policy — the substantive change happened in a configuration default, far from where anyone was watching for it. The same pattern is visible here, one layer down. Whether the free public data layer learns to describe cryptography will do more to determine the real pace of migration across small operators than any additional deadline will, and it will be settled in a comment file rather than an instrument. It is also a reminder, familiar from our reading of how anti-hacking law sees an AI agent, that new technical realities tend to arrive first as gaps in old categories.
For organizations working out what their own migration actually requires — inventory scope, sequencing, and where supplier duties bite — our Signature Report The PQC Migration Roadmap for Boards covers the ground this post only points at: fixed scope, a dated source spine, refresh triggers as the standards move, and an internal-use license so the analysis can circulate inside an organization rather than being re-derived. This post gives you the argument and the docket number; the Report is what you use when you have to act on it and show your work.
The date to watch is October 13. What arrives on that docket, and from whom, will tell you whether the cryptographic dimension of the public vulnerability record has an advocate — or whether the next round of migration deadlines will land on operators who still have nowhere to look.
Published intelligence, built to inform your own decisions. Published: August 12, 2026.
Sources. National Institute of Standards and Technology, Request for Information (RFI) on Modernizing the National Vulnerability Database in the Age of Artificial Intelligence, Federal Register document 2026-16371, docket 260805-0401, published August 12, 2026; comments close October 13, 2026 (PDF). NIST, NIST Releases First 3 Finalized Post-Quantum Encryption Standards, August 2024, and FIPS 203. The CVE Program, CVE record downloads. Directive (EU) 2022/2555 (NIS2). Cyberbeveiligingswet and Cyberbeveiligingsbesluit, Staatsblad 2026, 189, in force August 15, 2026. Bulletin of the Atomic Scientists, Why hackers targeting America's water systems have the upper hand, August 2026. Quotations from the RFI are from the Federal Register text as published August 12, 2026; all links checked that day.
Published intelligence, built to inform your own decisions. Published: August 12, 2026.