NIST SP 800-216 (federal vulnerability disclosure guidelines), explained

NIST SP 800-216, "Recommendations for Federal Vulnerability Disclosure Guidelines," is a free NIST Special Publication (May 2023) that tells U.S. federal agencies how to receive, triage, verify, remediate and publicly advise on vulnerability reports against their own software, hardware and IoT devices. It exists because Section 5 of the IoT Cybersecurity Improvement Act of 2020 directed NIST to write exactly this guidance, aligned "to the maximum extent practicable" with ISO/IEC 29147 and 30111 — the international coordinated-vulnerability-disclosure standards. SP 800-216 does not replace those standards; its own text says it "augments rather than replaces the requirements and recommendations provided in" them, adding a federal-government-specific organizational layer on top.

Two actors: the FCB and the VDPO

The whole framework runs on two defined roles (Executive Summary; Sections 2-3):

Actor	Role
Federal Coordination Body (FCB)	"A group of cooperating government entities that operate at the federal level to ensure vulnerability disclosure coordination services for all government agencies." Receives source vulnerability reports, coordinates investigation to identify vulnerable systems, routes findings reports, and produces advisories. Expected to have few members, each covering a distinct slice of government (e.g. military vs. civilian).
Vulnerability Disclosure Program Office (VDPO)	"The operational unit that is responsible for information technology (IT) systems and coordinating with other actors to identify, resolve, and issue advisories on reported vulnerabilities." Ideally part of an existing information technology security office (ITSO), closest to the affected product or service.

Most agencies "will leverage the services provided by an FCB member, will not themselves be part of the FCB, and will instead establish their own VDPOs" (Section 1). Other actors in the flow are the reporter (anyone submitting a report, inside or outside government), the public (whoever needs to act on or is affected by a vulnerability), and the external coordinator — a non-government CVD entity, another VDPO, or the upstream software vendor.

What a VDPO must stand up (Section 3.2)

1. Report acceptance policies and receipt capability — both a public external policy (report methods, acknowledgement/resolution expectations, no-legal-action commitment for researchers following the rules — aligned with CISA's BOD 20-01) and an internal policy covering response/remediation timelines.
2. Monitoring of the reporting mechanism and of public sources/support channels likely to surface a report informally.
3. Processing and resolution — identifying which systems/software a report concerns, verifying the vulnerability exists, and overseeing or supporting the system owner's mitigation or remediation.
4. Internal handling procedures — who is responsible at each stage, safeguards against premature disclosure, and a target remediation schedule.

How a report moves end to end

SP 800-216's Section 2 walks the FCB-level process in sequence: prepare receipt capability and contacts (2.1) → receive the source vulnerability report (2.2) → triage and prioritize using "a documented vulnerability scoring methodology (e.g., the Common Vulnerability Scoring System [CVSS])" plus government-exposure and user-impact factors (2.3) → determine the affected system (2.4) and software (2.5) → verify and remediate, with the VDPO closest to the system leading resolution (2.6) → decide whether to publish an advisory (2.7). Note 6 under Section 2.3 flags a deliberate deviation from ISO/IEC 30111: SP 800-216 prioritizes using the highest calculated severity across configurations, rather than ISO/IEC 30111's "severity of the most common configuration," because this guidance targets specific deployed government systems rather than widely-configured commercial products.

Deciding whether — and how — to publish an advisory

Section 2.7.1 lists conditions favoring public disclosure: the vulnerability has no CVE yet, the affected system is public-facing, PII or sensitive data exposure is possible, the flaw could affect users outside the VDPO's own agency, or the public needs to take action (patch, update, change a password). Section 2.7.2 then specifies what a good advisory contains: a stable identifier (ideally a CVE), affected product/version detail "without... too much detail to avoid enabling exploitation," an ISO 8601-formatted publication date, a documented severity rating (CVSS recommended), remediation or mitigation steps, contact information, and reporter credit if requested. Section 2.7.3 names the two standing government advisory channels: CISA's National Cyber Awareness System (five products — Current Activity, Alerts, Bulletins, Analysis Reports, and an Industrial Control Systems feed) and NIST's own National Vulnerability Database (NVD).

How this fits with ISO/IEC 29147/30111 and CISA's own process

SP 800-216 is built directly on top of ISO/IEC 29147 and 30111: a VDPO "will implement the vulnerability disclosure standard [ISO/IEC 29147]" and "provide oversight and support for system owners who perform the vulnerability handling duties described in [ISO/IEC 30111]." It separately notes alignment with CISA's Binding Operational Directive 20-01 (2020), which already requires federal agencies to publish a vulnerability disclosure policy enabling external reports. SP 800-216 does not itself describe CISA's own internal CVD workflow for non-federal reports — that is covered by CISA's published CVD process page, a related but distinct process.

A workable starting point

1. Decide your FCB relationship first. Most agencies are not FCB members — identify which FCB member covers your sector and use its templates and advisory channel rather than building one from scratch.
2. Write the external policy to BOD 20-01's shape, even outside the federal government: clear report channel, acknowledgement timescale, and an explicit no-legal-action commitment for good-faith researchers.
3. Pick a documented severity methodology up front — CVSS is what SP 800-216 recommends — so prioritization is consistent across every report your VDPO-equivalent function receives.
4. Decide your advisory channel before you need one. Whether that's an internal customer bulletin or a public CVE/NVD entry, Section 2.7.2's element list (identifiers, affected versions, severity, remediation, contact, credit) is a usable checklist regardless of audience.

SoftWSP's PSIRT engagements can be structured around the FCB/VDPO roles and the report-intake-through-advisory flow SP 800-216 describes, adapted for a device maker rather than a federal agency: see PSIRT as a Service.

This guide summarises the public NIST SP 800-216 (May 2023) documentation; it is not a substitute for the full text and does not constitute compliance or legal advice.