Vulnerability disclosure policy template and security.txt guide

Last updated: 2026-10-19

A vulnerability disclosure policy (VDP) tells security researchers and customers how to report a vulnerability in your products, what you will do with the report and by when. Publish it on your website, point to it from a security.txt file at /.well-known/security.txt (RFC 9116), and you meet the basic disclosure expectations of the EU Cyber Resilience Act, the UK PSTI regime and ETSI EN 303 645. Copy the template below, replace the bracketed parts and publish.

Why device makers need a VDP now

A VDP is also the front door of your PSIRT: if reports cannot reach you, you cannot meet the CRA 24-hour reporting deadline.

Vulnerability disclosure policy template

Copy everything in this section. Replace text in [brackets].

[Company name] Vulnerability Disclosure Policy

Last updated: [date]

1. Our commitment [Company name] wants its products to be secure. We welcome reports from security researchers, customers and partners, and we will work with you to understand and fix valid issues.

2. Scope This policy covers:

• [Product families and models, e.g. “all cameras sold under the [Brand] name”]
• Firmware and companion apps for these products
• Cloud services that these products depend on: [domains]

Out of scope: [e.g. third-party websites, physical attacks requiring device disassembly, denial-of-service testing against production services, social engineering of staff].

3. How to report

• Email: [[email protected]]
• Encryption: our OpenPGP key is at [URL], fingerprint [fingerprint]
• Web form: [URL, optional]

Please include: the affected product and firmware or app version, a description of the issue, steps to reproduce, the potential impact, and any proof-of-concept code. You may report in [English, other languages].

4. What you can expect from us

• We will acknowledge your report within [3] business days.
• We will give you an initial assessment within [10] business days.
• We will update you on progress at least every [30] days until the issue is resolved.
• We will tell you when a fix or mitigation is available.
• With your agreement, we will credit you in our security advisory.

5. Coordinated disclosure We ask you to give us reasonable time to fix the issue before you publish details. We aim to release a fix or mitigation within [90] days of the report and will agree a publication date with you. If a vulnerability is being actively exploited, we may publish an advisory sooner, and we will notify the authorities as required by law.

6. Guidelines for researchers

• Only test devices and accounts you own or have permission to test.
• Do not access, change or delete other people’s data; stop and report if you encounter it.
• Do not degrade our services or other users’ devices.
• Do not demand payment in exchange for not disclosing a vulnerability.

7. Safe harbour If you act in good faith and follow this policy, we will consider your research authorised, we will not pursue legal action against you for it, and we will make this clear if a third party raises a complaint. [Have this section reviewed by your legal counsel for each country you operate in.]

8. Rewards [We do not currently offer monetary rewards.] / [Describe your bounty rules.]

9. Security advisories and support periods We publish advisories for fixed vulnerabilities at [URL]. Security update support end dates for our products are listed at [URL].

Tips before you publish

• Name a real owner for the security mailbox and a backup; reports must not land in a general inbox.
• Choose timescales you can meet. PSTI makes you publish them; missing your own promises erodes trust.
• Link the policy from product documentation, packaging inserts or the app, since the CRA asks that the single point of contact be easy to find and be included in user information (Annex II).
• Get legal review of the safe harbour section.

security.txt explained (RFC 9116)

security.txt is a small text file that lets anyone find your security contact automatically. RFC 9116 was published in April 2022 as an Informational RFC.

Example security.txt

# security.txt for example.com – see RFC 9116
Contact: mailto:[email protected]
Contact: https://example.com/security/report
Expires: 2027-10-18T23:59:59Z
Encryption: https://example.com/.well-known/pgp-key.txt
Policy: https://example.com/security/vulnerability-disclosure-policy
Acknowledgments: https://example.com/security/hall-of-fame
Preferred-Languages: en, de, vi
Canonical: https://example.com/.well-known/security.txt

Checklist:

1. Replace example.com with your domain on every line.
2. Set Expires to a date within the next 12 months and put a renewal reminder in your calendar.
3. Upload to /.well-known/security.txt and check that it opens over HTTPS as plain text.
4. Publish it on every domain where reports may arrive: your main site, support site and cloud API domain.
5. If you sign it, re-sign after every change.

From policy to process

A policy only works with a process behind it: triage, fix, advisory, and for exploited issues, CRA notification within 24 hours. The CRA checklist for device makers lists the rest, and CRA Annex I explained shows where the VDP fits in the essential requirements.

No in-house team to run it? Softwsp can receive and triage reports, coordinate with researchers and prepare your CRA notifications: PSIRT as a service.

This guide is general information, not legal advice.