Vulnerability Disclosure Requirements Map: CVD and Reporting Duties in the EU, UK, US, China and Japan

A vendor that sells one connected product in Europe, the UK, the US, China and Japan now faces five different answers to the same question: when a vulnerability is found, who must be told, by when, and what may be published. Some regimes only require a published reporting route; others require a report to a government platform within hours or days, and one restricts what researchers may publish. This map sets out the main coordinated vulnerability disclosure (CVD) and vulnerability reporting duties side by side: the EU Cyber Resilience Act (CRA) and NIS2, the UK Product Security and Telecommunications Infrastructure (PSTI) regime, US federal rules, China's vulnerability management provisions and Japan's Early Warning Partnership. It is for PSIRT leads, product security managers, compliance teams and bug bounty owners who need one disclosure process that satisfies all of them. Status checked 12 November 2026.

Source note: this map summarises the official texts linked in the references (EUR-Lex, legislation.gov.uk, CISA, GovInfo, FDA, State Council of China, IPA) as of 12 November 2026. Confirm against the official text before relying on it.

Key takeaways

• The EU clock is already running. Since 11 September 2026, CRA Article 14 requires manufacturers to report actively exploited vulnerabilities through ENISA's single reporting platform: early warning within 24 hours, notification within 72 hours and a final report within 14 days of a fix being available.
• China is the fastest unconditional report. Network product providers must report a verified vulnerability to the MIIT platform within two days, whether or not it is exploited, and nobody may publish details before a fix exists unless MIIT and MPS assess early release.
• The UK and Japan regulate the channel, not the clock. PSTI requires a published contact point and published response timescales for consumer connectable products; Japan's Early Warning Partnership is voluntary, with a recommended 45-day publication timeline.
• The US works through procurement and sector rules. Federal agencies must run vulnerability disclosure policies under CISA BOD 20-01, the IoT Cybersecurity Improvement Act bars agencies from buying IoT devices that prevent compliance with NIST disclosure guidelines, and FDA requires a CVD plan for cyber devices.
• One intake process, several outputs. A single PSIRT intake that timestamps verification, exploitation evidence and fix availability can feed every regime; separate processes per country miss clocks and leak embargoed data.

Regulations and frameworks at a glance

Sector rules sit on top of these, and incident reporting regimes (GDPR, NIS2 Article 23, DORA, SEC) may also be triggered when a vulnerability is exploited against you. For those clocks, see the Cyber Incident Reporting Requirements Map.

Scope: which duty applies to whom

• Manufacturer duties: the CRA, PSTI, FDA 524B and the China provisions all attach to the maker of the product. The CRA covers hardware and software products with digital elements and their remote data processing; PSTI covers consumer connectable products, with exceptions such as desktops and laptops without cellular connectivity; China covers network products, hardware and software.
• Operator duties: China also binds network operators that find vulnerabilities in their own systems, and US agencies under BOD 20-01 must accept reports about their own internet-facing systems. NIS2 entities have vulnerability handling and disclosure in their Article 21 risk management measures.
• Researcher and platform duties: only China places binding rules on discoverers and on vulnerability collection platforms, which include bug bounty platforms operating there. Elsewhere, researcher conduct is governed by the vendor's policy and general computer misuse law.
• Exploited versus unexploited: the CRA reporting clock starts only for actively exploited vulnerabilities; unexploited ones follow the Annex I handling requirements. China's two-day report applies to any verified vulnerability.

For the process standards that most of these regimes point to, see the ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide.

Key obligations by jurisdiction

European Union

• Reporting route: notifications go through the single reporting platform to the CSIRT designated as coordinator in the Member State of the manufacturer's main EU establishment, with ENISA receiving them at the same time (Art. 14(7)). Without an EU establishment, the order is the authorised representative's Member State, then the importer's, then the distributor's, then where most users are.
• Three stages: early warning within 24 hours of becoming aware, vulnerability notification within 72 hours, final report no later than 14 days after a corrective or mitigating measure is available. Severe incidents affecting product security follow the same route under Art. 14(3), with their own final report timing.
• Users: after becoming aware, inform impacted users, and where appropriate all users, about the vulnerability and mitigations, in a structured, machine-readable format where appropriate (Art. 14(8)). CSAF advisories fit this requirement.
• Handling requirements (from 11 December 2027): an SBOM covering at least top-level dependencies, remediation without delay, regular testing, public disclosure of fixed vulnerabilities, an enforced CVD policy, a contact address, secure update distribution and free security updates with advisories (Annex I Part II).
• Voluntary reports: anyone may notify vulnerabilities, threats or near misses to a CSIRT or ENISA (Art. 15); if a third party reports an exploited vulnerability, the CSIRT informs the manufacturer.

See the EU Cyber Resilience Act Vulnerability and Incident Reporting Guide for the platform mechanics.

United Kingdom

• What to publish: at least one contact point for reporting security issues with the product's hardware and software, and when the reporter will receive an acknowledgement and status updates until resolution.
• How to publish: accessible, clear and transparent, without a prior request, in English, free of charge and without asking for the reporter's personal information.
• No fixed days: the manufacturer sets its own timescales and must meet them. Deemed compliance is available through ETSI EN 303 645 provision 5.2-1 or named ISO/IEC 29147 clauses.

See the UK PSTI Act Guide.

United States

• BOD 20-01 (agencies): security contact at the .gov registrar within 15 business days; VDP, security.txt (with Policy and Contact fields) and handling procedures within 180 days; scope grows by at least one system every 90 days from day 270 until all internet-accessible systems are covered at two years. The VDP must commit not to pursue legal action against good-faith research, accept anonymous reports, and not require personal information or limit testing to vetted or US researchers. CISA's recommended handling targets are acknowledgement within 3 business days, initial assessment within 7 days and resolution within 90 days.
• IoT Cybersecurity Improvement Act: NIST guidelines (section 5) cover how agencies and their contractors at any tier receive vulnerability reports and share fixes, aligned with ISO/IEC 29147 and 30111. From 4 December 2022 agencies may not procure or use IoT devices whose CIO review finds they prevent compliance, subject to waivers for national security, research or alternative protection.
• FDA 524B: premarket submissions for cyber devices from 29 March 2023 must include a postmarket vulnerability plan with CVD and an SBOM.

For running a VDP or bug bounty that meets these expectations, see the Bug Bounty and Vulnerability Disclosure Guide.

China

• Provider workflow (Art. 7): verify and assess promptly, notify upstream suppliers immediately where the flaw is in their component, report to the MIIT Cyber Security Threat and Vulnerability Information Sharing Platform within two days with product name, model, version, technical characteristics and impact, fix promptly and tell users how to apply the fix.
• Publication (Art. 9): no publication before the provider offers a fix unless coordinated with the provider and assessed by MIIT and MPS; no details of vulnerabilities in systems operators are using; publish mitigations with any disclosure; no unpublished vulnerability information to overseas organisations or individuals other than the provider; no publication during major national events without MPS consent.
• Platforms and logs: intake channels with logs kept for at least six months (Art. 5); vulnerability collection platforms must file with MIIT (Art. 10).

See the China Regulations on Management of Network Product Security Vulnerabilities Guide.

Japan

• Partnership model: IPA receives vulnerability reports; JPCERT/CC coordinates software product cases with developers; IPA contacts website operators directly.
• Developer expectations: verify the report, make sure users know about countermeasures and cooperate with JPCERT/CC progress checks. The recommended release timeline is generally 45 days from the initial report; developers needing longer should contact JPCERT/CC. For cases handled over a year, the discoverer may ask IPA to withdraw its non-disclosure request.
• Status: participation is voluntary; advisories are published on Japan Vulnerability Notes (JVN).

Where the regimes conflict

Timeline and current status

Watch three items: national penalty rules for CRA Article 14, Commission guidance on when a manufacturer becomes aware of exploitation, and any change to China's provisions following the 2025 amendment of the Cybersecurity Law.

Enforcement and penalties

• EU CRA: breaches of Articles 13 and 14 and the essential requirements can attract fines up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64(2)); Member States set the penalty rules.
• UK PSTI: the Office for Product Safety and Standards can issue compliance, stop and recall notices and monetary penalties up to the greater of £10 million or 4% of qualifying worldwide revenue.
• China: penalties run through the Cybersecurity Law, enforced by MIIT and MPS within their remits.
• US: BOD 20-01 is binding on agencies; for suppliers the consequence is contractual and procurement exclusion, and for medical devices an incomplete 524B submission.
• Japan: no penalties; the partnership is voluntary.

Where identity fits

Many reportable product vulnerabilities are credential flaws: hard-coded keys, default service passwords, leaked signing keys and token handling bugs. A leaked update-signing key or CI/CD token that lets an attacker ship code is both a vulnerability to handle and, once exploited, a CRA severe incident. The accounts used to submit reports are sensitive too: the CRA platform submitters, the MIIT platform account and the security.txt mailbox should be named, protected with MFA and logged. See the Secrets Management Guide.

Compliance steps

1. Map products to regimes. For each product line, record markets, whether it is a product with digital elements, a consumer connectable product, a network product in China or a cyber device for FDA.
2. Publish one disclosure policy. A single CVD policy with a contact address, security.txt, acknowledgement and update timescales you can meet, safe harbour wording and a default embargo. See the Vulnerability Disclosure Policy Template.
3. Timestamp the decisions. Record receipt, verification, evidence of active exploitation and fix availability; each starts a different clock.
4. Register reporting accounts. CRA single reporting platform submitters with backups, MIIT platform access where you sell in China, and CISA contacts for federal customers.
5. Control data flows. Keep unpublished China-relevant details in a restricted store; check that AI triage and ticket integrations do not move embargoed findings abroad.
6. Prepare templates. Pre-draft CRA early warning and notification fields, the MIIT report fields and user advisories in CSAF.
7. Exercise it. Run a scenario where an exploited vulnerability is reported on a Friday evening and check that the 24-hour, 2-day and user notice steps are met.

Metrics that show it is working

• Acknowledgement compliance: percentage of reports acknowledged within the published timescale (target 100% for PSTI products).
• Clock compliance: percentage of CRA early warnings filed within 24 hours of awareness and China reports within two days of verification.
• Time to fix: median days from verification to fix availability, by severity.
• Advisory coverage: percentage of fixed vulnerabilities with a published advisory in machine-readable format.
• Policy coverage: percentage of product lines and internet-facing domains covered by the published CVD policy and security.txt.

Common failure patterns

• Unmonitored security contact: a published address nobody reads breaches PSTI's own stated timescales and the CRA contact address requirement.
• Waiting for certainty: exploitation evidence arrives through threat intelligence or customers, and the 24-hour CRA window passes while engineering debates.
• Global tooling, local law: embargoed details from a China case are copied into a global ticket system or external AI service.
• Promising timescales you cannot meet: a "48-hour acknowledgement" commitment that works only during office hours.
• No upstream notice: flaws in third-party components are fixed locally without telling the supplier, which China's Art. 7 and good CVD practice both require.

Framework mapping

Practitioner checklist

• Map every product line and market to the regimes in this map.
• Publish one CVD policy with a contact address, security.txt and timescales you can always meet.
• Record receipt, verification, exploitation evidence and fix availability as separate timestamps.
• Register CRA single reporting platform submitters with backups and test access out of hours.
• Prepare MIIT report content and route China-relevant unpublished details to a restricted store.
• Publish machine-readable advisories for every fixed vulnerability.
• Notify upstream component suppliers when the flaw is theirs.
• Recheck CRA national penalty rules and Commission guidance before each policy review.

Standards and references

• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• legislation.gov.uk: Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1
• CISA: Binding Operational Directive 20-01, Develop and Publish a Vulnerability Disclosure Policy
• GovInfo: Public Law 116-207, IoT Cybersecurity Improvement Act of 2020
• FDA: Cybersecurity in Medical Devices Frequently Asked Questions
• State Council of China: Provisions on the Management of Network Product Security Vulnerabilities
• IPA: Information Security Early Warning Partnership

This guide summarises vulnerability disclosure and reporting requirements as of 12 November 2026 and is not legal advice. Related NHI Mgmt Group resources: ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide · EU Cyber Resilience Act Vulnerability and Incident Reporting Guide · UK PSTI Act Guide · China Regulations on Management of Network Product Security Vulnerabilities Guide · Vulnerability Disclosure Maturity Model