When a researcher finds a flaw in your product or website and cannot find anyone to tell, the report goes nowhere, goes public, or goes to someone who will exploit it. Receiving and handling external vulnerability reports is now a legal duty for many organisations: UK connectable product manufacturers since 29 April 2024 under the PSTI regime, and manufacturers of products with digital elements in the EU, who must report actively exploited vulnerabilities under the Cyber Resilience Act from 11 September 2026. This five-level NHI Mgmt Group model (Ad hoc, Developing, Defined, Managed, Optimised) describes how a vulnerability disclosure capability matures, from no contact point to a measured programme with safe harbour and, later, a bug bounty. It is for security leaders, product security teams and PSIRT managers. For running the programme day to day, see the Bug Bounty and Vulnerability Disclosure Guide.
Key takeaways
- Level 2 is the legal floor for many: a published contact point and stated response expectations are required of UK connectable product manufacturers by the PSTI Regulations 2023, Schedule 1 paragraph 2.
- Level 3 is the sensible first target: a published policy aligned with ISO/IEC 29147, a security.txt file under RFC 9116, and an internal handling process aligned with ISO/IEC 30111.
- EU manufacturers need a clock, not just an inbox: the CRA requires a 24-hour early warning and a 72-hour notification through ENISA's Single Reporting Platform for actively exploited vulnerabilities.
- Safe harbour comes before money: a clear authorisation statement and a no-legal-action commitment do more for report quality than rewards.
- Bug bounty is a Level 4 or 5 choice: pay for reports only once triage and remediation can keep up with the volume they create.
The five levels
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | No published contact. Reports arrive through support, sales or social media, and are lost, ignored or treated as threats. Nobody owns them. Legal threats against researchers are possible. |
| 2 | Developing | A security contact (for example a security@ mailbox or web form) is published and monitored. Reporters are told when to expect acknowledgement and updates. Handling depends on individuals, with no tracking or timelines. |
| 3 | Defined | A vulnerability disclosure policy (VDP) states scope, permitted testing, how to report and a good-faith safe harbour. security.txt is published on every domain. Reports are tracked in a ticketing system with severity, owners and target times. Regulatory reporting duties are mapped. |
| 4 | Managed | Timelines are measured and met. A product security incident response team (PSIRT) coordinates fixes, advisories and CVE assignment. CRA early warning and notification can be met within 24 and 72 hours. Supplier and open-source component reports are handled. A private bug bounty may run for high-value assets. |
| 5 | Optimised | Root causes from reports feed secure development. Public bug bounty where justified, published metrics and acknowledgements, coordinated multi-party disclosure, and regular review of the programme against ISO/IEC 29147 and 30111. |
Capability areas
Score each area separately. Most organisations are uneven: a well-written policy (Level 3) with no tracking behind it (Level 1) is common.
| Capability area | Level 2 evidence | Level 3 evidence | Level 4 to 5 evidence |
|---|---|---|---|
| Contact and intake | Monitored mailbox or form, no personal data required | security.txt at /.well-known/security.txt with Contact, Expires (less than a year ahead) and Policy; Encryption key offered | Signed security.txt with Canonical; intake on every domain and product; anonymous reports accepted |
| Policy and safe harbour | Response expectations published | VDP with scope, permitted and prohibited testing, no-legal-action statement, no NDA demanded | Policy versioned, reviewed yearly, scope expanded on a schedule; bounty terms separate |
| Triage and handling | Named person forwards reports | Tracked tickets, severity (for example CVSS), owners, target times for acknowledgement, assessment and fix | PSIRT, SLA tracking, duplicate handling, reporter kept informed until resolution and invited to retest |
| Remediation and advisories | Fixes made when noticed | Fixes linked to the vulnerability management process | Security advisories, CVE IDs, customer notification, coordinated release with suppliers |
| Regulatory reporting | Duties not known | PSTI, CRA and sector duties mapped to owners | CRA early warning and notification rehearsed; Single Reporting Platform account ready; user notification templates |
| Measurement and improvement | None | Counts of reports and valid findings | Median times, ageing, recurrence by root cause, findings fed back into secure development |
What the main requirements ask for
| Source | Status | Key requirement | Minimum level |
|---|---|---|---|
| RFC 9116 security.txt | IETF Informational, April 2022 | File at /.well-known/security.txt over HTTPS; Contact and Expires required | 3 |
| ISO/IEC 29147:2018 | Current, confirmed 2024; revision under development | Receiving reports and publishing remediation information | 3 |
| ISO/IEC 30111:2019 | Current, confirmed 2025; revision under development | Internal process to investigate and remediate reported vulnerabilities | 3 |
| UK PSTI Regulations 2023, Schedule 1 para 2 | In force since 29 April 2024; enforced by OPSS | Publish at least one contact point, and when reporters will get acknowledgement and status updates until resolution | 2 |
| EU CRA (Regulation (EU) 2024/2847), Article 14 | Reporting applies from 11 September 2026; most other obligations from December 2027 | Early warning within 24 hours, notification within 72 hours, final report within 14 days of a corrective measure (vulnerabilities) or one month (severe incidents), via ENISA's Single Reporting Platform; inform affected users | 4 |
| EU CRA Annex I, Part II | Applies from December 2027 | Coordinated vulnerability disclosure policy and a contact address for reporting vulnerabilities | 3 |
| CISA BOD 20-01 | Issued 2 September 2020; US federal civilian agencies | VDP covering all internet-accessible systems, no legal action for good-faith research, anonymous reports, quarterly metrics | 3 to 4 (useful benchmark for anyone) |
CRA reporting applies to products already on the EU market, including products that no longer receive updates, according to the Irish and Finnish national cyber security centres. Fines for missing the 24-hour deadline do not apply to micro and small enterprises (recital 120), but the duty to report does. See the EU Cyber Resilience Act Guide and the UK PSTI Act Guide.
Self-assessment questions
- If a researcher searched for how to report a flaw in your main product today, would they find a contact within a minute? Is security.txt present on every domain, and is its Expires date in the future?
- Does your policy say what testing is authorised and that you will not pursue legal action for good-faith research within it? Do you avoid demanding NDAs or personal data?
- Is every report tracked from receipt to closure, with an owner, a severity and target times? What were your median acknowledgement and fix times last quarter?
- Can you tell within 24 hours whether a reported vulnerability is being actively exploited, and who would file the CRA early warning?
- Do reports about third-party or open-source components reach the team that maintains them, and the upstream supplier?
- Does the reporter hear back until resolution, and can they retest the fix?
- Do recurring root causes from reports change your secure development practice?
Moving up: roadmap
- Level 1 to 2 (weeks): publish a monitored security contact that requires no personal data, state when reporters will get acknowledgement and updates, and name an owner and a backup. For UK connectable products, this is the PSTI baseline.
- Level 2 to 3 (one to three months): write a VDP using ISO/IEC 29147 and the NCSC Vulnerability Disclosure Toolkit as models; include safe harbour reviewed by legal. Publish security.txt on every domain with Contact, Expires and Policy, and set a calendar reminder to renew Expires. Track reports in a ticket queue with targets: CISA suggests acknowledgement within 3 business days, initial assessment within 7 days and resolution within 90 days. Map PSTI and CRA duties to owners.
- Level 3 to 4 (three to twelve months): form a PSIRT or assign the role formally, connect intake to the vulnerability management and incident response processes, rehearse a CRA 24-hour early warning end to end, prepare advisory and user notification templates, and decide whether to become a CVE Numbering Authority. Consider a private bug bounty for the highest-value assets once SLAs are being met.
- Level 4 to 5 (ongoing): publish metrics and acknowledgements, move to a public bounty only where triage capacity is proven, run coordinated multi-party disclosure with suppliers, and feed root-cause trends into threat modelling and secure coding training.
Small organisations can reach Level 3 with a form, a policy, security.txt and a shared tracker; a bug bounty is rarely worth it. Product manufacturers selling into the EU should treat Level 4 regulatory reporting as mandatory from 11 September 2026 regardless of size.
Practitioner checklist
- Publish /.well-known/security.txt on every domain with Contact, Expires (under a year ahead) and Policy; consider signing it.
- Publish a VDP with scope, permitted testing, safe harbour and response times; never require an NDA or personal data to report.
- Track every report with an owner, severity and target times for acknowledgement, assessment and fix.
- Measure median time to acknowledge, validate and remediate, and the number of reports older than 90 days.
- Name the owner for CRA early warning and notification and rehearse the 24-hour and 72-hour deadlines.
- For UK connectable products, publish the contact point and acknowledgement and update timescales required by PSTI.
- Treat a credible report of active exploitation as an incident and link it to incident response; see the Zero-Day and Exploited Vulnerabilities Guide.
- Map the programme to NIST CSF 2.0 ID.RA-08 and SP 800-53 RA-5(11) Public Disclosure Program, and to your Vulnerability Management Maturity Model score.
Standards and references
- IETF: RFC 9116, A File Format to Aid in Security Vulnerability Disclosure
- ISO: ISO/IEC 29147 Vulnerability disclosure
- ISO: ISO/IEC 30111 Vulnerability handling processes
- European Commission: Cyber Resilience Act reporting obligations
- legislation.gov.uk: Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1
- CISA: BOD 20-01 Develop and Publish a Vulnerability Disclosure Policy
- NCSC: Vulnerability Disclosure Toolkit
Related NHI Mgmt Group resources: Bug Bounty and Vulnerability Disclosure Guide · Vulnerability Management Guide · IoT Security Guide · Medical Device Security Guide