What the New Joint CISA CVD Guidance Means for CRA Manufacturers

On 15 July 2026, five national cyber security agencies published a joint guide titled Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers. The authoring organisations are the US Cybersecurity and Infrastructure Security Agency (CISA), the US National Security Agency (NSA), Japan's JPCERT/CC, the Netherlands' NCSC-NL, and the UK's NCSC. The document is marked TLP:CLEAR, so it can be shared without restriction.

A guide led by US agencies might look like something EU manufacturers can skim and file away. It is not. The guide names the EU Cyber Resilience Act directly. In its note on policy obligations it states that the CRA requires all suppliers operating in the European Union to maintain vulnerability disclosure policies. What the five agencies describe as best practice is, for anyone selling products with digital elements into the EU market, largely a description of legal obligations under Article 13(8) and Annex I Part II of Regulation (EU) 2024/2847.

That makes the guide useful in a specific way. It is a plain-language, twelve-page operational checklist for requirements the CRA states in regulatory language. If you are building your CVD programme for the December 2027 deadline, this is the document to hand to the engineer or product manager who has to implement it.

What the guide recommends

The guide groups its recommendations into three key actions. Create and publish a vulnerability disclosure policy. Define processes to triage, remediate, and assign CVE identifiers. Leverage intermediaries such as national CSIRTs where you lack capacity.

Under those headings sit concrete practices. For the policy itself, the agencies recommend that you

• publish the policy on your website and open participation to the public, without conditions on a researcher's nationality or age
• set the widest possible scope for testing, because arbitrary boundaries constrain researchers without constraining attackers
• state clearly which activities are prohibited, such as introducing malware, modifying or deleting data, brute-force attacks, denial of service, and social engineering
• specify minimum reporting requirements and accept anonymous reports, since some researchers prefer to keep their identities confidential
• publish a security.txt file per RFC 9116 so researchers can find your reporting channel
• include safe harbor language assuring researchers that good-faith research is authorised, and the guide provides sample wording
• establish reasonable time frames for remediation and disclosure, noting that long embargoes do not reduce risk because attackers can find the same flaw independently
• avoid blanket disclosure restrictions such as NDAs and avoid silent fixes

For the handling process, the guide recommends acknowledging researcher outreach within a defined window such as two to three business days, triaging with a risk framework such as SSVC, sharing fixes with the researcher for validation before release, assigning CVE IDs to vulnerabilities found internally as well as externally, and considering becoming a CVE Numbering Authority.

For publication, the agencies recommend releasing advisories in an unrestricted location that requires no login, publishing them in the Common Security Advisory Framework (CSAF) so they are machine readable, and never putting advisories behind a paywall.

The researcher recognition point

One recommendation deserves particular attention because most manufacturers miss it. The guide lists what an ideal vulnerability publication contains. Alongside the affected products, root cause, CVSS information, remediations, and the CVE ID, it includes a recognition of the researcher for their efforts, if the researcher grants permission.

The consent condition matters as much as the credit. Some researchers build their reputation on public acknowledgments. Others, for employment or personal reasons, need to stay anonymous. A CVD programme that credits everyone by default is as broken as one that credits no one. The guide also suggests offering public recognition or bug bounties as a way to incentivise reporting when you review and improve your programme.

Most published CVD policies already promise credit. The standard template wording says something like "we will credit you by name or alias unless you prefer otherwise." The gap is operational. If your advisory pipeline has no field for the researcher's name and no record of whether permission was granted, that promise depends on someone remembering an email thread months after the report arrived.

CRA Portal closed this gap this week. Advisories now carry a structured researcher acknowledgment with an explicit consent flag. The credit appears in the Acknowledgments section of the public advisory page and in the machine-readable CSAF export's acknowledgments field, and only when the consent flag is set. Without consent the name stays internal.

Mapping the guide to your CRA obligations

Every recommendation in the guide lands on a CRA requirement or supports one.

A published vulnerability disclosure policy. Annex I Part II point (5) requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure. The guide's sections on scope, prohibited activities, reporting requirements, and safe harbor are effectively a drafting checklist for that policy.

A contact point for reporting. Annex I Part II point (6) requires measures to facilitate the sharing of information about potential vulnerabilities, including a contact address. The guide's security.txt recommendation is the established way to publish that contact point, and it is also what BSI TR-03183-3 recommends in Germany.

Handling and remediation processes. Annex I Part II points (1) to (4) require manufacturers to identify vulnerabilities, address them without delay, test products regularly, and share information about fixed vulnerabilities publicly once a security update is available. The guide's triage, fix development, and CVE assignment sections describe how mature organisations actually run those processes.

Public advisories. The requirement to disclose fixed vulnerabilities, including a description and the means to remediate, maps to the guide's publication section. The CSAF recommendation is the same format EU CSIRTs use, and the format CRA Portal generates for every published advisory.

Article 14 reporting. The guide recommends leveraging intermediaries such as national CSIRTs for coordination. Under the CRA this is more than a recommendation. Actively exploited vulnerabilities must be reported to your CSIRT and ENISA on the 24-hour, 72-hour, and 14-day cascade that has applied since September 2026.

What to do with this

If you already run a CVD programme, read the guide against your current policy and process. The most common gaps we see are missing safe harbor language, no anonymous reporting path, no structured researcher credit, and human-readable advisories with no machine-readable equivalent.

If you are starting from zero, the sequence is shorter than it looks. Publish a policy with safe harbor wording, serve a security.txt, stand up a tracked intake channel, define your acknowledgment window, and set up an advisory pipeline that can produce CSAF. That covers the bulk of the guide and the corresponding CRA obligations in one pass.

Further reading

The guide's own resources section points to material worth keeping on hand.

• The joint guide itself (CISA, NSA, JPCERT/CC, NCSC-NL, NCSC-UK, July 2026)
• The NCSC Vulnerability Disclosure Toolkit (NCSC-UK)
• Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure (FIRST)
• CERT Guide to Coordinated Vulnerability Disclosure (CERT/CC, Carnegie Mellon University)
• ISO/IEC 29147 on vulnerability disclosure, the standard the guide builds on

CRA Portal implements the operational side of this guidance out of the box. Published policy with safe harbor wording, security.txt generation, anonymous and tracked intake, acknowledgment SLAs, researcher credit with consent, CSAF advisories, and the Article 14 reporting cascade. The intake tier is free, because the baseline obligation should not have a price tag.