Writing a coordinated vulnerability disclosure policy for your apps

Q: Does a small app agency need a CVD policy?

If you are the manufacturer of an app, Annex I Part II point (5) of the CRA requires you to put in place and enforce a coordinated vulnerability disclosure policy. Whether you are the manufacturer depends on whose name or trademark the app is placed on the market under.

Q: Is security.txt mandatory under the CRA?

The CRA text does not mention it. It requires a contact address and a CVD policy, and ENISA's advisory presents security.txt (RFC 9116) as a way to support the contact requirement.

Q: Do I have to run a bug bounty?

Nothing in the CRA provisions on disclosure requires rewards. A policy can state that you do not pay and that you credit reporters if they want it.

Q: Can one policy cover NIS2 and the CRA?

According to ENISA's advisory, medium and large manufacturers in scope of NIS2 can use one security.txt file and one reporting channel for both, and the policy should say whether a report concerns CRA products or NIS2 network systems.

Updated 10 November 2026 · 8 min read · Based on Regulation (EU) 2024/2847, RFC 9116 and ENISA's October 2026 technical advisory

Short answer: the CRA requires a coordinated vulnerability disclosure (CVD) policy and one contact point, and for an app team both can be small, as long as someone actually answers.

Annex I, Part II, point (5) requires manufacturers to "put in place and enforce a policy on coordinated vulnerability disclosure". Point (6) requires measures that make it easier to share information about potential vulnerabilities, such as providing a contact address.
Article 13(17) requires a single point of contact that users can reach directly and rapidly, and Annex II, point 2 puts that contact, and the place where your CVD policy can be found, into the information you give to users.
A policy is a short public page: scope, how to report, what reporters can expect, rules for testing, a disclosure timeline. A security.txt file (RFC 9116) makes the contact machine-readable.
ENISA's advisory stresses that publishing is not enough: the policy has to be backed by real internal processes.

What the CRA requires

The vulnerability handling requirements are in Annex I, Part II of the Cyber Resilience Act, Regulation (EU) 2024/2847. These provisions matter for a disclosure policy:

Provision	What it asks of you
Annex I, Part II, point (4)	Once a security update is available, share and publicly disclose information about the fixed vulnerability: a description, the affected products, the impact, the severity and guidance on remediation. Publication may be delayed in duly justified cases so that users can apply the update first.
Annex I, Part II, point (5)	Put in place and enforce a policy on coordinated vulnerability disclosure.
Annex I, Part II, point (6)	Take measures to facilitate the sharing of information about potential vulnerabilities, including in third-party components, for example by providing a contact address for reports.
Article 13(17)	Designate a single point of contact that lets users communicate directly and rapidly with you, including to report vulnerabilities. It must be easy for users to identify and must not force them through automated tools only.
Annex II, point 2	The user information must state the single point of contact where vulnerabilities can be reported and received, and where your CVD policy can be found.

These obligations apply from 11 December 2027 together with the rest of Annex I; see the dates in our scope guide. The earlier reporting duty for actively exploited vulnerabilities is separate and is covered in CRA vulnerability reporting for app teams. Nothing stops you from publishing a policy now, and a reporter who finds a flaw today has no way of reaching you without one.

What ENISA published to help

ENISA has released a technical advisory on security.txt, CVD policies and security advisories (October 2026). The file name of the PDF marks it as a public-consultation version, so details may change. It is aimed at manufacturers, especially SMEs, and contains templates for a security.txt file, a CVD policy and a security advisory. It does not cover secure development, internal remediation workflows or incident response, and ENISA states that it imposes no regulatory obligation.

Two of its points are worth repeating to any team that wants to get this done in an afternoon. First: "Publication alone is not sufficient." The policy has to be implemented through real internal processes. Second: assign a named owner and a deputy, and use a role-based mailbox rather than one person's inbox.

What a CVD policy for an app should contain

ENISA's CVD policy template covers the sections below. The right-hand column is how they translate to a team that ships mobile apps; those are our practical suggestions, not legal requirements.

Section (ENISA template)	For an app team
Introduction	Who you are and why you want to hear about problems. Two sentences.
Scope	List each app by name and store identifier (Android package name, iOS bundle ID), the backend APIs it needs, and what is out of scope, such as your marketing website or third-party services you do not control.
How to report	A role-based address such as `[email protected]`, or a web form. Say which languages you read.
Rules for responsible testing	No testing on real users' accounts, no data exfiltration beyond what is needed to prove the issue, no denial of service. Test accounts, if you can offer them, make this easier.
What to include in a report	App and version, platform and OS version, steps to reproduce, impact in the reporter's view. A mobile report without a version is hard to act on.
What reporters can expect	Acknowledgement, triage, status updates and mitigation, with the timeframes you can really meet.
Safe harbour	A statement that you will not take action against good-faith research that follows the policy. Have a lawyer read this one.
Coordinated disclosure timeline	An embargo window. ENISA's template asks that details are "not made public without prior coordination with us".
Recognition	Whether you credit reporters, and whether you pay rewards. Do not imply a bug bounty if you do not run one.
Data protection	How you handle the reporter's personal data.

Choose the timeframes by what your team can honour on a bad week, not by what looks impressive. A policy that promises a 48-hour response and misses it does more damage than one that promises five working days and keeps to it.

What has to happen behind the policy

ENISA's template asks you to check every report for active exploitation and to decide in advance who assesses it and who notifies, with reference to Article 14. If a report shows that someone is already exploiting a flaw in your app, the 24-hour early warning clock of Article 14 may be running, so the person who reads security@ needs a route to whoever can file on the ENISA Single Reporting Platform.

Reports about a third-party component should not stop at your door. ENISA's advisory points to Article 13(6): vulnerabilities in a component should be forwarded to the component's maintainer. For an app that means analytics, payment and crash-reporting SDKs and open-source libraries. The free scanner shows which components an app contains, so you know whom to forward to.

Once a vulnerability is fixed, point (4) asks for public information about it. ENISA suggests a security advisory for each resolved vulnerability once the coordinated disclosure date has been reached, a public index of advisories, and machine-readable CSAF where feasible. For a small app team a short page per advisory is a reasonable start.

Add a security.txt file

security.txt is a small text file that tells researchers how to reach you. It is defined in RFC 9116. The points that matter:

Serve it over HTTPS at /.well-known/security.txt, as text/plain in UTF-8. A copy at the top-level path is allowed for legacy compatibility, and if both exist the /.well-known/ copy is used. ENISA recommends redirecting a root-level copy rather than duplicating it.
It applies only to the exact domain it is served from, so a file on www.example.com says nothing about app.example.com.
Expires must always be present and must not appear more than once. It is recommended to be less than a year ahead, and ENISA's advisory says to set it no more than 12 months out and put a reminder in the calendar. After that date the file is stale and should not be used.
Contact is the field for the address to use when reporting vulnerabilities, and it can appear more than once.
Policy links to your disclosure policy and, as a web URI, must begin with https://. Acknowledgments links to a page where reporters are recognised, with the same rule.
Other registered fields include Canonical, Encryption, Hiring and Preferred-Languages. IANA's registry also lists CSAF and Bug-Bounty. Parsers must ignore fields they do not know.
Signing the file with an OpenPGP cleartext signature is recommended but not required, and ENISA says an accurate, maintained file matters more than a signed one that is out of date.

A minimal example for a company with one domain (add Canonical if the file is served from more than one address):

Contact: mailto:[email protected]
Expires: 2027-06-30T00:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security

Publishing the file does not give anyone permission to test your systems, and not publishing it does not forbid testing (RFC 9116, Section 5.5), which is why the policy's testing rules matter. Our free security.txt generator builds the file and a starter disclosure policy for your apps in the browser.

Where to put the contact so users and researchers find it

The policy page and /.well-known/security.txt on your company domain.
The information and instructions you give users. Annex II, point 2 requires the single point of contact and the location of the policy to be in them. In an app, an "About" or "Security" entry in settings, linked from the store listing's support or website field, is a natural place.
Your own footer, as long as it is easy to find. The CRA asks that the contact is easily identifiable (Article 13(17)).

If you are an agency that maintains apps for clients, decide per app whether reports go to you or to the client, and say so in the maintenance contract. See who the manufacturer is first, because the manufacturer is the one the policy must come from.

Common mistakes

A mailbox nobody reads. Use a role address with at least two people behind it and test it by sending a message every few months.
An expired security.txt. RFC 9116 warns that stale or wrong information can send reports to the wrong place. Put the Expires date in a calendar.
One policy for everything. If you publish several apps, list them all in scope, or reports about an app you forgot will bounce.
Hard deadlines you cannot meet. State the timeframes you can honour and ask reporters to coordinate before publishing.
No link to Article 14. Decide today who files a report if a researcher shows an exploited vulnerability.

Checklist

Name an owner and a deputy, and create a role-based security mailbox.
List the apps and backends in scope with store identifiers.
Write the policy page using the sections above, with timeframes you can keep.
Publish /.well-known/security.txt with an Expires date under 12 months ahead and a calendar reminder.
Put the contact and the policy location into the information you provide to users, in the app and on the store listing.
Write down who checks a report for active exploitation and who files under Article 14.
Prepare a short advisory template for fixed vulnerabilities.

FAQ

Does a small app agency need a CVD policy?

If you are the manufacturer of an app, Annex I, Part II, point (5) applies to you. Whether you are the manufacturer depends on whose name or trademark the app is placed on the market under; see the manufacturer guide linked above.

Is security.txt mandatory under the CRA?

The CRA text does not mention it. It does require a contact address and a CVD policy, and ENISA's advisory presents security.txt as a way to support the contact requirement.

Do I have to run a bug bounty?

Nothing in the CRA provisions above requires rewards. A policy can simply say that you do not pay, and that you credit reporters if they want it.

Can one policy cover NIS2 and the CRA?

ENISA's advisory says that medium and large manufacturers in scope of NIS2 can use one security.txt file and one reporting channel for both, and that the policy should say whether a report concerns CRA products or NIS2 network systems.

A disclosure policy is easier to write when you know what is inside your app. Check its components and known vulnerabilities first.

Open the free scanner

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Annex I Part II points (4)–(6), Article 13(17), Annex II point 2. The wording of these provisions was checked against the text as reproduced on SpringLex (Annex I), SpringLex (Annex II) and Cyberday (Article 13(17)), because EUR-Lex could not be opened while preparing this guide.
ENISA: Technical Advisory on security.txt, CVD Policies and Security Advisories, October 2026.
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, read through a reader mirror.
IANA: security.txt fields registry.

This guide summarises EU law and non-binding ENISA material for practical use. It is not legal advice. Related: CRA vulnerability reporting · CRA risk assessment template · Who is the manufacturer? · security.txt generator.