CRA Templates: The 8 Documents Article 14 Requires Now Across Its Two Tracks, and the Annex I Part II Set Due From 11 December 2027

CRA templates come in two sets with different start dates. Article 14 has applied since 11 September 2026 and names eight written outputs across its two tracks: six reports, an intermediate report the CSIRT can ask for, and a notice to users. Each is due only when its trigger occurs. An actively exploited vulnerability, or a severe incident, triggers its own three reports, plus the user notice and any intermediate report requested. Those obligations cover every in-scope product, including products placed on the market years ago. The Article 13 and Annex I Part II documents apply from 11 December 2027, and only to products placed on the market from that date, or substantially modified on or after it. A template set that blends the two either over-builds for legacy products or leaves you short on the reports that are due now.

This guide maps the reporting and vulnerability-handling documentation duties in Articles 13 and 14 and Annex I Part II of Regulation (EU) 2024/2847 to its legal source and start date. It also says what each duty demands in writing and what a reporting pack leaves to other work. For the wider obligations, see our Cyber Resilience Act compliance guide.

Which set applies to which product

Plain-language summary: Article 14 covers all your in-scope products today. The vulnerability handling duties in Annex I Part II attach only to products you place on the market from 11 December 2027 (or substantially modify on or after that date); the handling duties run for the support period, and some retention duties run longer.

The split comes from three provisions. Article 71(2) applies the Regulation from 11 December 2027 but Article 14 from 11 September 2026. Article 69(2) exempts products placed on the market before 11 December 2027 unless they are substantially modified from that date. Article 69(3) then carves Article 14 back in for all of them. The Commission’s guidance on applying the CRA (C(2026) 5252, para. 210) draws the consequence explicitly. Where a product was placed on the market before 11 December 2027, or its support period has ended, “the manufacturer is not required to comply with the vulnerability handling obligations set out in Part II of Annex I”. The reporting obligations, by contrast, “continue to apply after a product with digital elements is no longer supported”.

Your product	Article 14 reporting (8 outputs)	Annex I Part II and Article 13 documents
Placed on the EU market before 11 Dec 2027, not substantially modified since	Yes, since 11 Sep 2026	No
Placed on the market on or after 11 Dec 2027	Yes	Yes, from placing on the market; handling duties run for the support period, some retention periods longer
Pre-2027 product substantially modified on or after 11 Dec 2027	Yes	Yes, from the modification
Support period has ended	Yes, reporting continues (guidance para. 210)	Handling duties end (para. 210); for products placed on the market from 11 Dec 2027, retention duties for the technical file and published updates can run longer

The table’s main point: for most manufacturers in October 2026, the binding written work is the Article 14 set, and it must work for products where you never built the 2027 set.

The 8 documents Article 14 requires now, across its two tracks

Plain-language summary: two incident types, three reports each, plus an update on request and a notice to users. Each of the six reports goes simultaneously to the CSIRT designated as coordinator and to ENISA through the ENISA Single Reporting Platform, which ENISA deployed in initial operating capability on 11 September 2026, the date manufacturers had to start submitting through it.

#	Document	Deadline	Minimum content the text names
1	Early warning, actively exploited vulnerability (Art. 14(2)(a))	24 hours from awareness	Member States where the product is made available, where applicable
2	Vulnerability notification (Art. 14(2)(b))	72 hours from awareness	Product, nature of exploit and vulnerability, measures taken, measures users can take, sensitivity
3	Final vulnerability report (Art. 14(2)(c))	14 days after a corrective or mitigating measure is available	Description with severity and impact; malicious actor, where available; security update details
4	Early warning, severe incident (Art. 14(4)(a))	24 hours from awareness	At least whether unlawful or malicious acts are suspected; Member States, where applicable
5	Incident notification (Art. 14(4)(b))	72 hours from awareness	Nature of the incident, initial assessment, measures taken, measures users can take, sensitivity
6	Final incident report (Art. 14(4)(c))	1 month after the incident notification	Detailed description with severity and impact; type of threat or root cause; applied and ongoing mitigation
7	Intermediate report (Art. 14(6))	When the CSIRT designated as coordinator that received the notification requests it	Relevant status updates
8	Notice to impacted users (Art. 14(8))	After becoming aware; no hour count in the text	The vulnerability or incident and, where necessary, mitigation and corrective measures users can deploy

Two clocks behave differently from the rest. The vulnerability final report runs from the availability of a fix or mitigation, not from awareness. The incident final report runs from the submission of the 72-hour notification. The 72-hour notifications and both final reports are also due “unless the relevant information has already been provided”, so the text allows one well-filled earlier report to cover a later stage. How the platform handles that, field by field, is in our CRA vulnerability reporting template guide. Deadline counting and the awareness test are in CRA reporting requirements.

The notice to users is not the CSIRT notification. Article 14(8) addresses “the impacted users … and where appropriate all users”, where appropriate in a machine-readable format. If you fail to inform them in a timely manner, the notified CSIRTs may inform users themselves where they consider it proportionate and necessary.

What Article 14 does not name is just as useful. There is no “reporting procedure”, “decision tree”, “reporting log” or “RACI” anywhere in Article 14. Those are practical documents, not statutory ones. You write them because the 24-hour clock starts at awareness and doesn’t stop for weekends. Someone on call has to decide whether an event is an actively exploited vulnerability (Art. 3(42)) or a severe incident (Art. 14(5)) before the first deadline passes. Our test for any internal document is whether it shortens the path to filings 1 and 4, or proves afterwards when you became aware and what you filed. If it does neither, it can wait.

The Annex I Part II set, with its Article 13 duties, due from 11 December 2027

Plain-language summary: Part II has eight points, but only five name something you write or publish. The other three (remediation, testing and update distribution) are processes you evidence, although Annex VII asks for a description of the distribution solution. Article 13 adds a risk assessment, records of vulnerabilities, an upstream report to component maintainers and support-period information.

Duty	Source	Written output the text names	Where it ends up
Identify and document vulnerabilities and components	Annex I Part II (1); Art. 13(7)	SBOM, at least top-level dependencies, machine-readable; records of vulnerabilities and third-party information	Technical documentation (Annex VII, 2(b)); SBOM requirements
Remediate without delay; security updates separate where feasible	Part II (2)	None named: evidence of remediation	Vulnerability register, release records
Effective and regular tests and reviews	Part II (3)	None named: test evidence	Test reports
Disclose fixed vulnerabilities once an update exists	Part II (4)	Public advisory: description, affected product, impact, severity, remediation help	Published security advisories
Coordinated vulnerability disclosure	Part II (5); Art. 13(8), sixth subparagraph	CVD policy, plus policies and procedures to process and remediate reports	Wherever users can find it, as stated in the Annex II user information (often a public web page); technical documentation
Facilitate vulnerability reports	Part II (6); Art. 13(17)	Contact address; single point of contact, not limited to automated tools	Annex II user information; technical documentation
Secure update distribution	Part II (7)	None named in Part II; Annex VII 2(b) asks for a description of the technical solutions chosen	Technical documentation
Disseminate updates without delay and free of charge, unless otherwise agreed with a business user for a tailor-made product	Part II (8)	Advisory messages accompanying updates	Release notes, update channel
Report component flaws upstream	Art. 13(6)	Report to the component’s maker or maintainer; share fix code or documentation where appropriate	Vulnerability register
Risk assessment	Art. 13(3)	Documented assessment that states how Part II is applied	Technical documentation (Art. 13(4))
Support period	Art. 13(8), fifth subparagraph; Art. 13(19)	Information used to set it; end date (month and year) at time of purchase	Technical documentation; sales channel

The table’s main point: Annex VII point 2(b) pulls the SBOM, the CVD policy, evidence of the contact address and the update-distribution description into the technical file. Your 2027 templates therefore have two audiences. Users and researchers see the published policy and advisories, while market surveillance sees the file. Each of the eight Part II duties, turned into PSIRT tasks, is in our guide to CRA vulnerability handling requirements.

The retention periods are longer than most document controls assume. Each security update must stay available for at least 10 years after issue or for the rest of the support period, whichever is longer (Art. 13(9)). Article 13(13) sets a similar rule for the technical documentation and EU declaration of conformity: at least 10 years after the product is placed on the market or the support period, whichever is longer. The support period itself is at least five years unless the product’s expected use is shorter, and the Commission’s guidance (para. 126) warns that five years “is therefore not to be considered as the default for all products with digital elements”.

If your organisation is also a NIS2 entity, much of this overlaps work you already do. Our vulnerability management policy template covers the patch-SLA side. The guide on how to write a vulnerability disclosure policy covers the CVD structure, which can serve both laws once you add the CRA’s product focus.

The legacy-product trap: reporting without handling

Plain-language summary: for an old product you may have to report an exploited flaw within 24 hours even though the CRA requires no SBOM, no patch and no handling process for it.

The Commission services’ CRA FAQ (version 1.4, entry 5.3) is blunt about why. Tooling to scan old versions may no longer exist, build environments may be impossible to recreate, and “staff with knowledge of old codebases may have left”. For such products, “manufacturers are required to notify the vulnerability or incident but are not required by the CRA to comply with other obligations, e.g. in relation to vulnerability handling”. The FAQ adds that the Article 14(8) user notice still applies.

This breaks a common template design. A reporting procedure that starts “check the SBOM, run the scanner, open a ticket in the PSIRT queue” fails for a 2019 gateway that has none of those. The procedure has to branch early. For a legacy or end-of-support product, the inputs are what you know about the product and the exploitation evidence, the outputs are filings 1 and 2 (plus filing 3 if a fix or mitigation becomes available) or filings 4 to 6, any intermediate report the CSIRT requests, and the user notice, while the Part II handling process is not required for such products (FAQ entry 5.3). Keep a register of which products sit in that branch, so the on-call engineer doesn’t have to work out the product’s placing-on-market date at 2 a.m.

Third-party components add a second branch. Under FAQ entry 5.4, an integrator must notify an actively exploited vulnerability that originates in a component of its product. The component maker must also notify if it placed the component on the market. If the flaw cannot be exploited in your product, it is not actively exploited there. Reporting becomes voluntary under Article 15, but the Article 13(6) upstream report still applies once Article 13 does. The actively exploited vulnerability guide works through nine cases, including a component flaw that cannot be reached in your product.

Three checks before you trust any CRA template

Plain-language summary: templates copied from summaries inherit their errors, so test any template, ours included, against the Regulation’s own wording.

The OpenSSF PSIRT obligations checklist is a useful, freely available map of Articles 13 and 14. Its legal-text column matched the Regulation in the rows we compared. Its one-line summary column, checked on 21 October 2026, does not always match. For Article 14(4)(c) the summary says “within 14days”, where the text says “within one month after the submission of the incident notification”. For Article 14(2)(b) it describes a 72-hour advisory “to consumers”, but that provision is a notification to the CSIRT and ENISA. A procedure drafted from those summary lines would set the wrong deadline on filing 6.

1. Clock anchors. Filing 3 must run from a fix or mitigation being available and filing 6 from submission of filing 5. Neither runs from awareness.
2. Recipient split. Filings 1 to 6 go to the CSIRT designated as coordinator and ENISA via the platform, and filing 7 only when the CSIRT designated as coordinator that received the notification asks for it. Filing 8 goes to users. A template that merges them leaves one duty undone.
3. Date split. The template should say Annex I Part II applies from 11 December 2027, and not to products placed on the market before that date unless they are substantially modified on or after that date. One that presents the SBOM as a current legal duty for every product overstates the law.

What a reporting pack does not cover

Plain-language summary: a reporting pack makes you able to file on time. It does not make a product conformant, and it cannot stand in for the technical file or the declaration of conformity.

When we mapped our own 18-document pack (the full file list is on the CRA reporting pack page) against Articles 13 and 14 for this guide, two of the Article 13 outputs listed above had no home in it at all (vulnerability records, for example, sit in its Vulnerability Register): the Article 13(3) risk assessment and the Article 13(19) end-of-support date shown at purchase. Conformity assessment, the EU declaration of conformity and CE marking are missing too, and the technical file and Annex II user information are covered only in part. Our pack covers reporting plus the Part II basics (SBOM, CVD policy, contact point); the items listed here belong to product conformity rather than reporting, so this is by design, but you still need to know they’re missing. The design requirements of Article 13(1) are not a document a pack could hold. The full list of what sits wholly or partly outside it:

Obligation	Source	Applies from	In a reporting pack?
Essential cybersecurity requirements for design and production	Art. 13(1); Annex I Part I	11 Dec 2027	No
Documented cybersecurity risk assessment	Art. 13(3)–(4)	11 Dec 2027	No
Technical documentation	Art. 31; Annex VII	11 Dec 2027	Partly: the pack supplies the SBOM, CVD policy and contact-point evidence named in point 2(b); the technical description of your own update solution is yours to write
Conformity assessment, EU declaration of conformity, CE marking	Arts. 28, 30, 32; Annex V	11 Dec 2027	No
Information and instructions to the user	Art. 13(18); Annex II	11 Dec 2027	Partly: contact point and CVD policy location (Annex II points 1–2)
Support-period end date at purchase	Art. 13(19)	11 Dec 2027	No

The fines split along different lines. Article 64(2) puts non-compliance with Annex I and Articles 13 and 14 at up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Article 64(3) sets up to EUR 10 million or 2% for, among others, the declaration of conformity (Art. 28), CE marking (Art. 30(1)–(4)) and technical documentation (Art. 31(1)–(4)). Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities in reply to a request carries up to EUR 5 million or 1% (Art. 64(4)). Member States set the national penalty rules (Art. 64(1)). Article 64 itself applies only from 11 December 2027: Article 71(2) brings forward only Article 14 and Chapter IV (Articles 35 to 51), and Article 64 sits in Chapter VII.

Who owns which document

Role	Owns now (Article 14)	Owns by 11 Dec 2027
Compliance officer	Product scope list with placing-on-market dates; EU Login accounts with MFA for the people who will file; reporting log	Technical file index; retention schedule (security updates: 10 years from issue or the rest of the support period; technical file and declaration: 10 years from placing on the market or the support period; the longer period in each case)
CISO / PSIRT lead	Track decision (actively exploited vulnerability per Art. 3(42); severe incident per Art. 14(5)); filings 1–7	SBOM process, vulnerability register, test evidence, advisories
Product / engineering lead	Exploit and fix facts for filings 2, 3, 5 and 6	Risk assessment, update distribution description, support-period rationale
Legal / communications	Filing 8 user notice and its channel	Published CVD policy, Annex II user information
Board / SME owner	Approves out-of-hours authority to file without sign-off	Approves support periods and the 2027 budget for product compliance

For an SME owner with one product line, the honest minimum this week is three things. List your in-scope products with their placing-on-market dates, so the legacy products are flagged. Have the people who will file create EU Login accounts with multi-factor authentication now; ENISA’s platform FAQ (question 9) advises registering on the platform itself only when you need to submit a notification, which takes a few minutes once the account exists. Our ENISA Single Reporting Platform guide walks through registration. Give one named person the authority to send a 24-hour early warning without waiting for you. In a group, the manufacturer of each product is the legal entity that develops or manufactures it, or has it designed, developed or manufactured, and markets it under its own name or trademark (Art. 3(13)), and each such entity needs its own reporting route. Our CRA Enterprise Licence covers up to five legal entities and adds a multi-entity deployment guide.

A dated build order

• Now (Article 14 applying since 11 Sep 2026): product scope list with legacy flag; report forms for filings 1–6; a named owner for answering a CSIRT request for an intermediate report (filing 7); a user-notice routine for filing 8; a reportability decision rule; a reporting log; EU Login accounts with MFA for the filers.
• Well before 11 Dec 2027 (processes that need run-in time): CVD policy and contact point published; SBOM generation in the build; vulnerability register; advisory format for Part II points (4) and (8).
• By 11 Dec 2027, for each product placed on the market, or substantially modified, from then: risk assessment stating how Part II is applied; support period set and shown at purchase; technical file and declaration of conformity for each new product.

For the same split as a tick-list with owners, see our CRA compliance checklist.

Frequently asked questions

Does the CRA prescribe official templates?

The Regulation contains no notification templates; Annexes V and VI give only a model structure for the EU declaration of conformity. Article 14(10) lets the Commission specify the format and procedures of notifications by implementing act, and Article 13(24) does the same for the SBOM. In practice, reports are submitted through ENISA’s Single Reporting Platform, whose data fields ENISA describes in its platform documentation.

Do I need an SBOM for products already on the market?

Not under the CRA, unless the product is substantially modified on or after 11 December 2027 (Art. 69(2)). The SBOM is part of the Annex I Part II vulnerability handling requirements, and the Commission’s guidance (para. 210) confirms those do not apply to products placed on the market before that date, while Article 14 reporting does.

How many documents does the CRA require for reporting?

Article 14 names eight outputs, each due only when its trigger occurs: three reports for an actively exploited vulnerability, three for a severe incident, an intermediate report when the CSIRT asks, and a notice to impacted users. Each track produces three reports for a given event, so one event usually means three reports plus the user notice, and any intermediate report the CSIRT requests. Internal procedures and logs are practical additions, not statutory ones.

Is the final report for a severe incident due in 14 days?

No. Article 14(4)(c) sets one month after submission of the 72-hour incident notification. The 14-day deadline belongs to actively exploited vulnerabilities and runs from the availability of a corrective or mitigating measure (Art. 14(2)(c)).

Does reporting stop when the support period ends?

No. The Commission’s guidance (para. 210) states that reporting obligations continue after a product is no longer supported, while the vulnerability handling duties end with the support period (retention duties for the technical file and published updates can run longer).

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the European Union — EUR-Lex. Articles 3, 13, 14, 15, 28, 30, 31, 32, 64, 69 and 71; Annex I Parts I and II; Annexes II, V, VI and VII (linked above).
2. European Commission. Commission guidance on the application of Regulation (EU) 2024/2847, Annex to C(2026) 5252 final, 27 July 2026, paras. 126 and 210 (linked above).
3. European Commission services. FAQs on the Cyber Resilience Act, version 1.4, 4 September 2026, entries 5.3 and 5.4 (linked above).
4. ENISA. Single Reporting Platform (SRP) — EU Agency for Cybersecurity (linked above).
5. ENISA. CRA Single Reporting Platform: Frequently Asked Questions, question 9, checked 21 October 2026 (linked above).
6. OpenSSF Global Cyber Policy Working Group. PSIRT Obligations Checklist, checked 21 October 2026 (linked above).