What We Told NIST About Proving a Vulnerability, and Why
Our filing to NIST argues that a security record should carry proof, so automation follows the evidence and a named person signs off wherever the consequence is high.
Rick Hensbergen4 minute read
In August, the National Institute of Standards and Technology (NIST) asked how the National Vulnerability Database should change now that artificial intelligence helps find and fix security flaws. The database is the federal government's public catalog of known software weaknesses. Our filing answered with one position: evidence should decide what gets automated, and consequence should decide what keeps a human signature.
The argument is narrow on purpose. A vulnerability record can say a weakness exists, and the filing says that isn't enough. A record should also carry proof a machine can check, so its reader can confirm the weakness, and later the fix, rather than read a description and take it on faith.
What we told NIST
The dividing line for AI in vulnerability management, the filing says, is not how sure a model is: "It is what the action would do." Finding a weakness, confirming it, and drafting a fix can run automatically, because each can be verified and undone. Telling a third party, changing a live system, and authorizing an active test keep a named person, because "accountability for such an act does not transfer with confidence."
The filing also names what today's standards leave out. The three behind vulnerability records (CVE, CVSS, and CWE) all describe a weakness, and none of them standardizes how to verify one. In the filing's words: "A record can say a weakness exists. No record can hand a consumer the means to confirm it."
What the filing says to put first
- Proven weaknesses first. A weakness shown to be reachable in a real system ranks ahead of one that is severe only in theory.
- Proof that travels with the claim. The filing asks for evidence to be "a first-class, referenceable object with a stable identifier and a defined shape," so a reader can re-confirm a record rather than merely re-read it.
- Proof that a fix worked. A fix counts as verified when a check shows the original problem can no longer be demonstrated. Until then, it's reported as unverified.
- A measure of what can be confirmed. For the next version of the database, the filing proposes tracking the share of records a reader can confirm independently: "Verifiability, not volume."
Why it matters beyond security
The same logic applies to any check an organization relies on. The filing puts it plainly: "A gate that fires on unvalidated findings gets disabled. A gate that fires on demonstrated ones does not." A warning that is often wrong gets ignored, and one that comes with its evidence gets acted on.
Most statements about a website's accessibility are claims on their own: a sentence in an accessibility statement, a badge in a footer, a vendor's word about its own work. A vendor cannot objectively grade its own work.
A claim on its own is what an organization has to offer when an ADA complaint or a demand letter arrives, and a claim carries no proof. A dated record the other side can check carries its proof with it.
Esther's records are held to the standard the filing argues for. Every finding is dated and carries its own evidence: what was assessed, what was found, and why it's on the list. When Esther assesses the site again, a resolved barrier is one that is no longer found, and a barrier that returns is on the list again. "We fixed it" becomes something a reader can verify.
The docket and the public record
NIST's request appeared in the Federal Register on August 12, 2026 (91 FR 52042, docket NIST-2026-0100). Our comment was filed on October 12 and posted by NIST on October 13. It can be read in full as NIST-2026-0100-0091 (opens in a new tab), and its attachment answers each section of the request.
The filing doesn't set out to show how Esther's engine works. As it says, "The argument does not depend on it." Instead, it argues that a record should hand its reader the means to check a claim, rather than a reason to accept it on faith.
What to ask next
- Which actions in your own processes run on confidence alone? And which stay tied to proof, or to a named person's sign-off?
- When someone asks how accessible your website is, what can you show them? A statement that the site meets WCAG asks the reader to take it on faith. A dated record lets them verify it.
- Does each finding you hold say what was found, on which page, and when? Those three details let someone confirm a finding later, including someone outside your organization.
- When a barrier is fixed, what shows it? A fix confirmed by the same check that found the problem is a fact. A fix on someone's word is a claim.
Questions like these separate speed from defensibility. Proof should decide what can be automated, and consequence should decide where a person stays involved. That is what lets a record stand up later, in a vulnerability database and on a website.
What that means for a public body: ADA compliance for government. For a business: ADA compliance for business. What can be checked on a website without special tools: How to check if your website is accessible.
Quotations are from Esther.ai Corporation's comment NIST-2026-0100-0091, received by NIST on October 12, 2026.
About the author
Rick Hensbergen is the founder and CEO of Esther. He has spent his career in governance and risk, twenty years of it at major banks in the United States and the United Kingdom, including as a Senior Manager approved by the UK's Financial Conduct Authority.