ENISA's draft SME Vulnerability Kit: what app teams should take from it
· 6 min read · CRA news
In short: ENISA has drafted three ready-to-use templates (a security.txt file, a coordinated vulnerability disclosure policy and a security advisory) to help small manufacturers meet the CRA's vulnerability handling duties.
- The draft is dated October 2026 and is open for comments. Two independent summaries give 15 November 2026 as the closing date.
- It is guidance, not law: the document says it imposes no regulatory obligations.
- For an app team, the three templates cover how researchers reach you, what you promise them, and how you tell users about a fix.
- It does not cover SBOMs, security testing or update distribution, so it is one part of CRA readiness, not all of it.
What ENISA published
The EU cybersecurity agency released a draft Technical Advisory on security.txt, CVD Policies and Security Advisories, subtitled SME Vulnerability Kit. It is aimed at manufacturers of products with digital elements, with small and medium-sized companies in mind, and offers fill-in templates rather than another explanation of the law.
The PDF itself does not state how or until when to comment. According to Luxgap, ENISA opened the consultation on 27 October 2026, and both Luxgap and cyber-regulierung.de give 15 November 2026 as the deadline. If you want your view on the templates to count, check ENISA's consultation material this week.
Why this matters for app teams
The templates map onto specific CRA provisions in Regulation (EU) 2024/2847 that every manufacturer of an app in scope will have to meet:
| CRA provision | What the kit helps with |
|---|---|
| Annex I, Part II, point (5) | Having and enforcing a coordinated vulnerability disclosure policy: the CVD policy template. |
| Annex I, Part II, point (6) | Making it easy to report vulnerabilities, including through a contact address: security.txt. |
| Annex I, Part II, point (4) | Publicly disclosing fixed vulnerabilities with the information users need: the security advisory template. |
| Article 13(17) and Annex II, point 2 | A single point of contact that is easy to find and stated in the user information. |
| Article 14(8) | Informing users about an actively exploited vulnerability, possibly before a fix exists. |
The vulnerability handling requirements of Annex I, Part II apply from 11 December 2027. Reporting of actively exploited vulnerabilities under Article 14 has applied since 11 September 2026, and the kit ties the two together: it asks manufacturers to check every incoming report for signs of active exploitation and to decide in advance who assesses that and who submits the notification. Our reporting guide explains those deadlines.
security.txt: the details that trip people up
security.txt is the small text file defined in RFC 9116 that tells researchers where to send a vulnerability report. ENISA's draft adds practical points that are easy to get wrong:
- Put it at
/.well-known/security.txton the primary domain and on every domain associated with the product. A file only at/security.txtis not enough; a root copy should just redirect. - Serve it over HTTPS as
text/plain; charset=utf-8, and check the header with curl, because hosting providers often get the content type wrong. ContactandExpiresare mandatory. Expires should be no more than 12 months ahead, so set a reminder to renew it.- Use a stable role address such as security@ that will outlive staff changes, and give the file an owner.
- Signing the file is recommended by the RFC but optional. ENISA says an accurate, maintained file matters more than a signature you cannot keep up.
For a mobile app, "every domain associated with the product" plausibly includes the app's website and the API domains it talks to. That reading is ours, not ENISA's, but it costs little to cover them.
The disclosure policy: promises you must be able to keep
The CVD policy template has ten parts, from scope and how to report to safe harbour, a disclosure timeline, credit for reporters and data protection. Three points stand out for small teams:
- Response targets. The draft recommends minimum targets, including acknowledging a report within 7 calendar days, with reference to the draft harmonised standard prEN 40000-1-3. Pick targets you can meet with the people you have.
- Publishing is not enough. ENISA stresses that the internal process and responsibilities have to exist and be followed, with a named owner, a deputy and an annual review.
- Safe harbour has limits. It can only cover your own systems and waive your own claims; it cannot authorise anyone to test third-party systems, such as the app stores or an SDK vendor's backend.
The template also covers reports about third-party components, which you forward to their maintainer under Article 13(6). In apps, that is where most vulnerabilities live.
Security advisories: human and machine-readable
The advisory template asks for an identifier, CVE or EUVD references, CVSS severity, affected and fixed versions, a plain-language summary without exploit detail, remediation steps, a timeline and credit. ENISA recommends keeping a public index of advisories and also publishing in machine-readable form, preferably CSAF, whose VEX profile can state that a product is not affected. Teams without CSAF tooling can use publication services from coordinators or sector CERTs.
For apps, the version fields matter most: users update at different speeds, so an advisory should make it obvious which app version is safe.
What the kit leaves out
ENISA is explicit that the templates do not support Annex I, Part II point (1), identifying and documenting components including an SBOM, point (3), regular testing and review, or point (7), secure distribution of updates. Those still need their own process. For SBOMs, see our guides for Flutter and React Native.
What we would do this week
- Read the draft and, if a template does not fit how apps are built and shipped, say so before the consultation closes.
- Check that
/.well-known/security.txtexists on every domain tied to your apps, with a valid Expires date and the right content type. - Write a one-page CVD policy from the template with response times your team can actually meet, and link it from security.txt. Our free security.txt and policy generator gives you a first draft of both.
- Agree who reads the security mailbox, who decides whether a report shows active exploitation, and who submits to ENISA.
- Create an advisory page you can publish to, even if it stays empty for now.
Advisories and exploitation checks both start with knowing what is in each app version. Build an SBOM and check it against known vulnerabilities in seconds.
Open the free scannerSources
- ENISA: Technical Advisory on security.txt, CVD Policies and Security Advisories (SME Vulnerability Kit), draft, October 2026 (PDF).
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Articles 13(6), 13(17), 14 and Annexes I and II.
- Luxgap: ENISA consultation on security.txt and CVD (consultation dates).
- cyber-regulierung.de: SME Vulnerability Kit der ENISA (consultation deadline).
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure.
This article summarises a draft ENISA document and EU law for practical use. The draft may change after the consultation. It is not legal advice. Related: CRA vulnerability reporting for app teams · Does the CRA apply to mobile apps?