CISA, the National Security Agency and international cybersecurity partners have published new guidance telling software manufacturers and online service providers to build formal coordinated vulnerability disclosure programs rather than rely on improvised email exchanges when researchers find security flaws.
Published July 15, 2026, Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers focuses on the full operational chain: receiving vulnerability reports, communicating with researchers, triaging findings, developing fixes, coordinating disclosure and assigning Common Vulnerabilities and Exposures identifiers. The guidance also recognizes that smaller or less mature vendors may need CISA or another national computer security incident response team to act as an intermediary.
The practical message is straightforward. A vulnerability disclosure policy posted on a website is useful, but it is not a complete program. Manufacturers need people, authority and repeatable processes behind that page if they expect researchers to report flaws privately rather than disclose them publicly or abandon the effort.
A vulnerability disclosure policy, or VDP, gives researchers a defined route for reporting a suspected flaw. It should identify the products and services covered, acceptable research methods, prohibited activity, submission requirements and the organization’s expectations for coordinated publication.
That public document is particularly important for independent researchers who do not have an existing relationship with the vendor. Without it, they may be forced to send sensitive technical details to a general support address, search for employees on social media or approach a third-party coordinator simply to establish contact.
The joint guidance places the VDP inside a broader coordinated vulnerability disclosure program. Once a report arrives, the organization must acknowledge it, preserve the information, determine whether the issue is reproducible and route it to the engineering or operations team capable of fixing it.
That distinction matters for Windows administrators and enterprise customers. A vendor can advertise a security contact while still lacking the internal processes required to turn an external report into a tested update, security advisory and deployment recommendation.
Organizations designing a program should, at minimum, be prepared to:
CISA and its partners treat triage and remediation as core program functions rather than administrative follow-up. Reports need technical validation, severity assessment and ownership. The organization must also determine whether the finding affects a single hosted service, multiple supported versions, a shared library or products supplied to downstream customers.
For Windows environments, that can quickly become a supply-chain issue. A vulnerability in an authentication component, update agent, kernel driver or remote-management service may be embedded in several products. Fixing the originally reported application does not necessarily protect every customer using the affected code.
A mature program therefore needs access to product inventories, dependency records and release engineering. It also needs a way to escalate findings that may require emergency servicing, cloud-side mitigation or coordinated patches from multiple vendors.
Communication with the researcher remains important throughout that work. Researchers may possess proof-of-concept code, crash data or environmental details that internal testing has not captured. Treating the reporter as an adversary can cut off precisely the technical collaboration needed to confirm the exposure.
This is where safe harbor language becomes significant. A well-written policy can explain the conditions under which the organization will consider research authorized and refrain from pursuing legal action. Such assurances are not a substitute for legal review, but ambiguity around permitted testing can deter researchers from reporting at all.
Manufacturers with mature vulnerability-handling operations can consider becoming a CVE Numbering Authority, or CNA. Others can work through an existing CNA, CISA or another coordinator to obtain an identifier. The important point is to make CVE handling part of the disclosure workflow rather than an afterthought following publication.
A CVE alone does not tell an administrator whether a flaw is exploitable in a particular environment. Useful disclosure still requires accurate affected-version information, remediation instructions and enough technical context for defenders to assess exposure. Where appropriate, vendors may also need to communicate mitigations for customers that cannot immediately install an update.
For sysadmins, incomplete vulnerability records create costly uncertainty. If an advisory fails to identify affected builds, fixed versions or required configuration, teams may have to reverse-engineer the vendor’s update or assume that every deployment is exposed.
The same problem appears when a vendor silently repairs a vulnerability without publishing an advisory. Customers who postponed an update, maintain offline systems or depend on long-term support branches may never learn that they are running vulnerable software. Transparent disclosure allows vulnerability scanners, endpoint management products and asset owners to refer to the same issue.
The joint document fits CISA’s wider Secure by Design push, which asks technology manufacturers to accept more responsibility for customer security. A functioning disclosure program provides an external feedback loop for that effort: researchers identify where design assumptions, implementation choices or deployment defaults have failed, and vendors can feed those lessons back into development.
An intermediary can help establish contact, validate a report, coordinate among multiple vendors and manage publication when the parties have conflicting timelines. This is particularly valuable when the affected supplier is unresponsive, the vulnerability crosses national borders or a shared component exposes many downstream products.
Third-party coordination does not transfer responsibility for remediation away from the manufacturer. The vendor still controls its code, update infrastructure and customer communications. A coordinator provides structure and expertise, not an outsourced patch.
Organizations using an intermediary also need to define who communicates with the researcher and who can approve disclosure decisions. Adding another party without assigning authority can lengthen timelines rather than improve them.
For small software companies, however, an external coordinator can offer a practical starting point. It is preferable to a security report being lost in a help-desk queue or forwarded through multiple employees in unencrypted email.
They should also test the process before an urgent vulnerability arrives. A tabletop exercise can expose missing contacts, unclear escalation paths and disagreement over when customers or regulators must be notified.
For Windows-focused IT teams evaluating suppliers, the existence of a public VDP is increasingly a useful procurement signal. More important questions concern what sits behind it: whether the vendor publishes complete advisories, supports CVE assignment, communicates affected versions and has demonstrated that it can ship security updates across its supported product lines.
CISA and the NSA are effectively asking vendors to make external vulnerability reporting a normal part of product maintenance. The first milestone is a visible policy; the real measure is whether a researcher’s report can travel from inbox to validated fix without getting lost between legal, support, security and engineering.
Published July 15, 2026, Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers focuses on the full operational chain: receiving vulnerability reports, communicating with researchers, triaging findings, developing fixes, coordinating disclosure and assigning Common Vulnerabilities and Exposures identifiers. The guidance also recognizes that smaller or less mature vendors may need CISA or another national computer security incident response team to act as an intermediary.
The practical message is straightforward. A vulnerability disclosure policy posted on a website is useful, but it is not a complete program. Manufacturers need people, authority and repeatable processes behind that page if they expect researchers to report flaws privately rather than disclose them publicly or abandon the effort.
A Policy Page Is Only the Front Door
A vulnerability disclosure policy, or VDP, gives researchers a defined route for reporting a suspected flaw. It should identify the products and services covered, acceptable research methods, prohibited activity, submission requirements and the organization’s expectations for coordinated publication.That public document is particularly important for independent researchers who do not have an existing relationship with the vendor. Without it, they may be forced to send sensitive technical details to a general support address, search for employees on social media or approach a third-party coordinator simply to establish contact.
The joint guidance places the VDP inside a broader coordinated vulnerability disclosure program. Once a report arrives, the organization must acknowledge it, preserve the information, determine whether the issue is reproducible and route it to the engineering or operations team capable of fixing it.
That distinction matters for Windows administrators and enterprise customers. A vendor can advertise a security contact while still lacking the internal processes required to turn an external report into a tested update, security advisory and deployment recommendation.
Organizations designing a program should, at minimum, be prepared to:
- Publish a clearly defined scope and secure reporting channel that researchers can locate without contacting customer support.
- Acknowledge reports and maintain communication while technical validation and remediation are underway.
- Distinguish genuine vulnerabilities from duplicates, configuration problems and low-impact observations.
- Track affected products, versions, dependencies and supported release branches.
- Establish a process for assigning or requesting CVE identifiers when public tracking is appropriate.
- Coordinate the release of fixes, advisories and researcher credit without exposing customers prematurely.
Triage Must Connect Researchers to Engineering
The most visible failure in vulnerability disclosure is silence, but the more consequential problem often occurs behind the scenes. A security team may receive a valid report yet have no reliable way to identify the product owner, reproduce the behavior or secure engineering time for a correction.CISA and its partners treat triage and remediation as core program functions rather than administrative follow-up. Reports need technical validation, severity assessment and ownership. The organization must also determine whether the finding affects a single hosted service, multiple supported versions, a shared library or products supplied to downstream customers.
For Windows environments, that can quickly become a supply-chain issue. A vulnerability in an authentication component, update agent, kernel driver or remote-management service may be embedded in several products. Fixing the originally reported application does not necessarily protect every customer using the affected code.
A mature program therefore needs access to product inventories, dependency records and release engineering. It also needs a way to escalate findings that may require emergency servicing, cloud-side mitigation or coordinated patches from multiple vendors.
Communication with the researcher remains important throughout that work. Researchers may possess proof-of-concept code, crash data or environmental details that internal testing has not captured. Treating the reporter as an adversary can cut off precisely the technical collaboration needed to confirm the exposure.
This is where safe harbor language becomes significant. A well-written policy can explain the conditions under which the organization will consider research authorized and refrain from pursuing legal action. Such assurances are not a substitute for legal review, but ambiguity around permitted testing can deter researchers from reporting at all.
CVE Assignment Is Part of the Release Process
The guidance explicitly includes assigning CVE identifiers among the capabilities organizations should plan for. A CVE record gives defenders, vendors and security tools a common identifier for a publicly disclosed vulnerability, reducing confusion when product names and advisory formats differ.Manufacturers with mature vulnerability-handling operations can consider becoming a CVE Numbering Authority, or CNA. Others can work through an existing CNA, CISA or another coordinator to obtain an identifier. The important point is to make CVE handling part of the disclosure workflow rather than an afterthought following publication.
A CVE alone does not tell an administrator whether a flaw is exploitable in a particular environment. Useful disclosure still requires accurate affected-version information, remediation instructions and enough technical context for defenders to assess exposure. Where appropriate, vendors may also need to communicate mitigations for customers that cannot immediately install an update.
For sysadmins, incomplete vulnerability records create costly uncertainty. If an advisory fails to identify affected builds, fixed versions or required configuration, teams may have to reverse-engineer the vendor’s update or assume that every deployment is exposed.
The same problem appears when a vendor silently repairs a vulnerability without publishing an advisory. Customers who postponed an update, maintain offline systems or depend on long-term support branches may never learn that they are running vulnerable software. Transparent disclosure allows vulnerability scanners, endpoint management products and asset owners to refer to the same issue.
The joint document fits CISA’s wider Secure by Design push, which asks technology manufacturers to accept more responsibility for customer security. A functioning disclosure program provides an external feedback loop for that effort: researchers identify where design assumptions, implementation choices or deployment defaults have failed, and vendors can feed those lessons back into development.
Third-Party Coordinators Provide a Pressure Valve
Not every organization can immediately establish a full product security incident response team. The new guidance consequently discusses using CISA or another national computer security incident response team to supplement or substitute for an internal disclosure program.An intermediary can help establish contact, validate a report, coordinate among multiple vendors and manage publication when the parties have conflicting timelines. This is particularly valuable when the affected supplier is unresponsive, the vulnerability crosses national borders or a shared component exposes many downstream products.
Third-party coordination does not transfer responsibility for remediation away from the manufacturer. The vendor still controls its code, update infrastructure and customer communications. A coordinator provides structure and expertise, not an outsourced patch.
Organizations using an intermediary also need to define who communicates with the researcher and who can approve disclosure decisions. Adding another party without assigning authority can lengthen timelines rather than improve them.
For small software companies, however, an external coordinator can offer a practical starting point. It is preferable to a security report being lost in a help-desk queue or forwarded through multiple employees in unencrypted email.
The Program Will Be Judged by Its First Difficult Report
The immediate action for manufacturers and service providers is to compare their existing process with the July 15 guidance. That review should go beyond checking whether[email][email protected][/email] exists. Organizations need to verify that the mailbox is monitored, submissions can be stored securely, engineering ownership is defined and someone has authority to coordinate a fix and advisory.They should also test the process before an urgent vulnerability arrives. A tabletop exercise can expose missing contacts, unclear escalation paths and disagreement over when customers or regulators must be notified.
For Windows-focused IT teams evaluating suppliers, the existence of a public VDP is increasingly a useful procurement signal. More important questions concern what sits behind it: whether the vendor publishes complete advisories, supports CVE assignment, communicates affected versions and has demonstrated that it can ship security updates across its supported product lines.
CISA and the NSA are effectively asking vendors to make external vulnerability reporting a normal part of product maintenance. The first milestone is a visible policy; the real measure is whether a researcher’s report can travel from inbox to validated fix without getting lost between legal, support, security and engineering.
References
- Primary source: CISA
Published: 2026-07-15T12:00:00+00:00
- Related coverage: gsa.gov
Vulnerability Disclosure Policy
Vulnerability Disclosure Policy. This policy describes what systems and types of research are covered under this policy, how to send vulnerability reports, and how long we ask security researchers to wait before publicly disclosing vulnerabilities.www.gsa.gov - Related coverage: researchgate.net
(PDF) Zombies, Sirens, and Lady Gaga – Oh My! Developing a Framework for Coordinated Vulnerability Disclosure for U.S. Emergency Alert Systems
PDF | U.S. emergency alert systems (EAS) run on legacy software with aging hardware and limited cybersecurity. While EASs are an essential component of... | Find, read and cite all the research you need on ResearchGate
www.researchgate.net
- Related coverage: sei.cmu.edu
Coordinated Vulnerability Disclosure for DoD Websites | CMU Software Engineering Institute
Almost 30 years ago, the SEI's CERT Coordination Center established a program that enabled security researchers in the field to report vulnerabilities they found in an organization's software or systems....www.sei.cmu.edu
- Related coverage: cybersecuritycoalition.org
Policy Priorities | cybersecurity
www.cybersecuritycoalition.org
