CRA Compliance Checklist: 9 Items for the Reporting Duty Live Since 11 September 2026, 16 Due by 11 December 2027
Short answer: Two Cyber Resilience Act dates create duties for manufacturers, and a checklist that ignores the split will put your team on the wrong work. Since 11 September 2026 exactly one manufacturer obligation applies: the Article 14 reporting duty for actively exploited vulnerabilities and severe incidents. Everything else (secure-by-design requirements, vulnerability handling, technical documentation, conformity assessment, CE marking) applies from 11 December 2027. That split is written into Article 71(2) of the CRA: “This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026.” Chapter IV governs the notification of conformity assessment bodies; it places no duties on manufacturers.
The checklist below has 25 items in three groups: 9 items for the reporting duty that already applies, 4 items that become legal duties in 2027 (for products placed on the market from then) but that your Article 14 work leans on today, and 12 items for full application. Each item carries its legal anchor in Regulation (EU) 2024/2847 (where an item rests on Commission guidance or ENISA’s platform rules rather than the regulation, its anchor says so); Parts A and C also list the evidence to keep, and Part B explains why each item matters for reporting now. For the regulation as a whole, start with our Cyber Resilience Act compliance guide.
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.
Disclosure: we sell CRA and NIS2 template packs, shown in two boxes below. Every CRA point in this checklist is sourced to the regulation, the European Commission or ENISA; the status of harmonised standards comes from a specialist tracker, named where it is used; article links point to an unofficial reproduction of the Official Journal text, whose wording we checked against the official text and its corrigenda (the penalties section notes one place where the reproduction lags); and our own readings and advice are labelled as such. Checked on 21 October 2026.
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
Does this checklist apply to you?
Plain-language summary: if you place hardware, or software supplied for local execution, with a data connection on the EU market under your own name or trademark, you are a manufacturer (web apps accessed only through a browser are not products in themselves, guidance para. 21) and, unless an exclusion in Article 2 applies (the main ones are in the table below; identical spare parts are another), the checklist applies to you: Part A for everything you have placed on the EU market, Parts B and C for what you place on the market or substantially modify from 11 December 2027. Importers and distributors have their own, shorter duties, and those start in 2027, unless they sell under their own name or substantially modify a product.
| Your position | What applies now | What applies from 11 December 2027 |
|---|---|---|
| Manufacturer (EU or non-EU) of a product with digital elements | Article 14 reporting, for every in-scope product you have ever placed on the EU market | Parts B and C, for products placed on the market or substantially modified from that date |
| Importer or distributor selling under its own name or trademark, or substantially modifying a product | Treated as the manufacturer, so Article 14 applies (Article 21) | As for a manufacturer |
| Importer | No CRA reporting duty (Article 14 binds manufacturers only) | Article 19: place only conforming products on the market and check the manufacturer’s paperwork |
| Distributor | No CRA reporting duty | Article 20: due care, including checking the CE marking |
| Medical or in-vitro diagnostic devices, type-approved vehicles, EASA-certified aviation products, marine equipment | Outside the CRA (Article 2(2) to 2(4)) | Outside the CRA; the sector rules apply |
| Products developed or modified exclusively for national security or defence | Outside the CRA (Article 2(7)) | Outside the CRA |
If you are also an essential or important entity under NIS2, both laws can apply to you at the same time; the Commission’s guidance (para. 212) notes that manufacturers may be subject to comparable reporting obligations under other EU acts. Our comparison of NIS2 and the CRA for product manufacturers walks through that dual-scope test.
Why the checklist has three parts, not two
Plain-language summary: hardware units you placed on the market before 11 December 2027, and (on our reading of the guidance) software versions first offered before then, never have to meet the 2027 requirements unless you substantially modify them, but you have to report exploited flaws in them now. Units of the same model shipped after that date are a different matter. That gap is where most teams get caught.
Article 69 contains both halves. Paragraph 2 says products placed on the market before 11 December 2027 are subject to the regulation “only if, from that date, those products are subject to a substantial modification.” Paragraph 3 then carves out reporting: Article 14 applies “to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.” The Commission’s CRA guidance of 27 July 2026 (paragraph 210) adds two points: reporting continues after a product’s support period has ended, and for those legacy or unsupported products the manufacturer is not required to comply with the vulnerability-handling requirements of Annex I Part II.
So for a legacy product you must send an early warning within 24 hours of becoming aware of an exploited flaw, with no legal duty to keep the component inventory that tells you whether the flaw is in your product at all. That’s why Part B exists: its items are legally due with Part C in 2027, but they sit apart because your Article 14 work needs them now. The other trap is what “placed on the market” means. The guidance (paragraph 11) follows the EU Blue Guide: the concept applies “to each individual product, not to a type of product.” The result is different for hardware and software:
| Situation | Article 14 reporting? | Annex I, conformity assessment, CE marking? |
|---|---|---|
| Router model launched in 2024; units shipped in 2026 | Yes, since 11 September 2026 | No, for those units (Art. 69(2)) |
| Same router model; units shipped from 11 December 2027 | Yes | Yes, for every new unit. A redesign is not automatically required, but a risk assessment, conformity assessment, declaration and CE marking are (guidance, paras. 33 to 36) |
| Standalone software version first offered in 2025, still downloaded in 2028 | Yes | No, unless substantially modified. Our reading of guidance paras. 13 to 15 (a software version is placed on the market when first offered) together with Art. 69(2) |
| A substantially modified release shipped after 11 December 2027 | Yes | Yes, as a new product (Art. 69(2); guidance, para. 15) |
| Product withdrawn from sale in 2025, support ended | Yes (Art. 69(3); guidance, para. 210) | No |
The hardware row is the one budgets miss. A model you designed in 2023 and still sell in 2028 needs CE marking under the CRA for every unit shipped from the application date, even though nothing about the product changed.
Part A: 9 items for the reporting duty that has applied since 11 September 2026
Plain-language summary: you need to know which products you are answerable for, recognise a reportable event, reach the right authority, and get three filings for each event out on time. Article 14 sets the content and clocks.
| Item: what “done” looks like | Legal anchor | Evidence to keep | Owner / effort |
|---|---|---|---|
| A1. Inventory of every in-scope product ever placed on the EU market, including ones you no longer sell or support | Art. 14(1) and (3); Art. 69(3) for products placed before 11 December 2027; guidance para. 210 | Signed product register (legacy rows included) with an owner per row | Product lead / Medium |
| A2. Written trigger criteria: “actively exploited” means reliable evidence that a malicious actor exploited the flaw without the system owner’s permission | Art. 3(42) | Decision tree approved by the decider | PSIRT lead / Low |
| A3. Written test for when you become aware: assess a suspicious event immediately; you are aware once that assessment gives you “a reasonable degree of certainty” | Guidance para. 213 (non-binding) | Triage procedure with a timestamp field for the assessment | PSIRT lead / Low |
| A4. Component rule: an exploited flaw in a third-party component is reportable by you only if it is exploited in your product; unreachable or unexploited ones are not mandatory | Guidance para. 218 (non-binding) | Component triage step in the decision tree | PSIRT lead / Low |
| A5. Coordinator CSIRT identified: the Member State where cybersecurity decisions on your products are predominantly taken; failing that, where your establishment with the most EU employees is. With no EU main establishment, the order is authorised representative, importer, distributor, then most users | Art. 14(7) | One-line determination with reasoning | Compliance / Low |
| A6. Filers ready: a personal EU Login account with multi-factor authentication for each likely filer; Primary Assigned Representative named in advance | Art. 14(1), Art. 16; platform rules in ENISA FAQ 9 | Filer list with confirmed EU Login access | Compliance / Low |
| A7. Vulnerability track: early warning within 24 hours, notification within 72 hours, final report no later than 14 days after a fix or mitigation is available | Art. 14(2)(a) to (c) | Procedure naming the drafter, the decider and an out-of-hours deputy, plus the coordinator CSIRT’s answer on how a deputy can file | PSIRT lead / Medium |
| A8. Severe-incident track: early warning within 24 hours (stating whether unlawful or malicious acts are suspected), notification within 72 hours, final report one month after the notification | Art. 14(4)(a) to (c), 14(5) | Procedure plus the severity test from Art. 14(5) | PSIRT lead / Medium |
| A9. User notice: inform impacted users, and where appropriate all users, about the event and the measures they can take | Art. 14(8) | Notice template and a customer contact list per product | Product + comms / Medium |
Item A6 departs from the common advice to pre-register on the reporting platform. ENISA’s Single Reporting Platform FAQ (updated 15 October 2026) says manufacturers “are advised to register and initiate the validation process only when they need to submit a notification”, to spare CSIRTs validation work. With an active EU Login account, registration “takes just a few minutes”, and an unverified representative may submit up to 20 notifications “before verification becomes mandatory”. So the step to take now is the EU Login account with MFA, not platform registration. One gap remains: a Primary representative must be verified before inviting Secondary ones, and drafts sit in each representative’s own account. If your out-of-hours plan relies on a deputy filing, ask your coordinator CSIRT how to handle it.
For the clocks on one worked timeline, see our guide to CRA reporting requirements. Two items have dedicated guides: the trigger test in actively exploited vulnerabilities under the CRA, and the user notice in CRA severe incident reporting.
Part B: 4 items due in 2027 that Article 14 work leans on today
Plain-language summary: these are legally 2027 obligations under Article 13 and Annex I Part II. Without them, Part A gets harder: no inventory to assess a reported flaw against, no channel for outside reports to reach you, no record of when you became aware, and no plan for what to tell users of an unsupported product.
| Item | Legal anchor (applies 11 Dec 2027) | Why Article 14 needs it now |
|---|---|---|
| B1. Software bill of materials covering at least top-level dependencies, in a common machine-readable format | Annex I Part II(1) | Item A4 makes an exploited third-party flaw reportable only if it is exploited in your product. The first step is knowing whether the component is in the product at all; without an SBOM, that step turns the immediate assessment the guidance expects (para. 213) into a search |
| B2. Vulnerability contact address, a single point of contact not limited to automated tools, and a coordinated vulnerability disclosure policy | Annex I Part II(5) and (6); Art. 13(17) | The guidance (para. 213) notes that in some cases a third party (an individual, a customer, an authority, the media) will bring the event to your attention. They need a channel that reaches you |
| B3. Documentation of the vulnerabilities you become aware of, including third-party information | Art. 13(7) | Your proof of when you became aware and what you assessed |
| B4. A support period decided per product: at least five years, or the expected use time if shorter | Art. 13(8) | Vulnerability handling ends with support, but reporting does not (guidance para. 210). An exploited flaw in an unsupported product still triggers the A9 user notice, with no fix to offer, so decide now what that notice says |
If you already run NIS2-style vulnerability management, much of B1 to B3 exists in another form; our vulnerability management audit checklist lists the controls auditors test, and most of them carry over.
Part C: 12 items for full application on 11 December 2027
Plain-language summary: classify each product, document a risk assessment against Annex I, run the right conformity route, and ship every unit with its paperwork and CE marking. The effort ratings assume a product line with existing secure-development practice.
| Item | Legal anchor | Evidence to keep | Owner / effort |
|---|---|---|---|
| C1. Each product classified as default, important Class I or II (Annex III) or critical (Annex IV), by its core functionality | Art. 7(1), 8(1); Implementing Reg. (EU) 2025/2392 | Classification memo per product | Compliance, with engineering input / Medium |
| C2. Placing-on-the-market plan: which hardware units ship after the date, and which software versions are new or substantially modified | Art. 69(2); guidance paras. 11, 13 to 15, 33 to 36 | Release and shipment calendar | Product lead / Low |
| C3. Cybersecurity risk assessment, documented and kept up to date, with a justification for each requirement you treat as not applicable | Art. 13(2) to (4) | Risk assessment in the technical file | CISO / security architect / High |
| C4. Gap assessment against the 13 product properties in Annex I Part I point (2), from no known exploitable vulnerabilities to secure data deletion | Annex I Part I | Requirement-by-requirement mapping | Engineering / High |
| C5. Due diligence on third-party and open-source components; vulnerabilities reported upstream to the maintainer, and the code or documentation of any fix you developed shared with them, where appropriate in a machine-readable format | Art. 13(5) and (6) | Component intake checks; upstream report log | Engineering / Medium |
| C6. The remaining Annex I Part II processes running (points 1, 5 and 6 are Part B): fixes without delay, with security updates separate from feature updates where technically feasible; regular security testing; public disclosure once fixed; secure update distribution; updates free of charge with advisories, unless otherwise agreed for a tailor-made product | Annex I Part II(2), (3), (4), (7), (8) | Process descriptions plus records | PSIRT lead / High |
| C7. Support end date (at least month and year) shown at the time of purchase; each security update kept available for at least 10 years after release or the remainder of the support period, whichever is longer (Art. 13(9)’s own wording, which differs from the C8 and C10 retention rule) | Art. 13(9) and (19) | Product page, packaging or listing; update archive | Product + web / Low |
| C8. Annex II user information and instructions, kept available for at least 10 years or the support period, whichever is longer; a type, batch or serial number on the product (or, where that is not possible, on its packaging or an accompanying document) and manufacturer contact details on the product, its packaging or an accompanying document | Art. 13(15), (16), (18); Annex II | Published instructions with version history | Product (technical writing) / Medium |
| C9. Conformity route chosen and booked: module A, B+C, H or a certification scheme, depending on class | Art. 32(1) to (4) | Route decision; notified-body contract where needed | Compliance / High |
| C10. Technical documentation per Annex VII, drawn up before placing on the market and kept for at least 10 years or the support period, whichever is longer | Art. 31; Art. 13(13) | Technical file | Compliance / High |
| C11. EU declaration of conformity (Annex V structure) and CE marking; for software, on the declaration or the accompanying website | Art. 28; Art. 30; Art. 13(20) | Signed declaration; marking record | Compliance / Low |
| C12. Release governance: series production stays in conformity, every release is screened for substantial modification, and non-EU manufacturers agree document access with their EU importers and decide whether to appoint an authorised representative (optional, by written mandate) | Art. 13(14); Art. 18; Art. 19 | Release checklist; importer agreements; any mandate | Product lead / Medium |
Item C9 is the one with the longest lead time. Under Article 32(2), a Class I important product can only use self-assessment if the manufacturer fully applies harmonised standards, common specifications or a European certification scheme at assurance level at least “substantial”. Otherwise it needs module B+C or module H, both of which involve a notified body. According to ibf solutions’ standardisation tracker (last amended 6 October 2026), the vocabulary and principles standards, EN 40000-1-1 and EN 40000-1-2, have “successfully completed the formal approval process at CEN-CENELEC” and await ratification on 2 November 2026, but the tracker does not expect either to be referenced in the Official Journal. Among the horizontal standards, only the vulnerability-handling part (still a draft, so labelled prEN 40000-1-3) is currently expected to be referenced there. The Commission’s standardisation request M/606 covers 41 standards in support of the CRA; under Article 27(1), harmonised standards give a presumption of conformity only once their references are published in the Official Journal. Ratification schedules can slip. If you make a Class I product, budget for third-party assessment now as the fallback: self-assessment needs one of the three Article 32(2) routes (cited harmonised standards, common specifications or a certification scheme) applied in full, and the standards status above gives no assurance that a full set of cited standards covering the Annex I requirements will be available by December 2027. The notified-body rules in Chapter IV have applied since 11 June 2026, so bodies can already be designated.
For C1, Implementing Regulation (EU) 2025/2392 describes the Annex III and IV categories. What decides is the product’s core functionality: under Article 7(1), integrating a component from a listed category “shall not in itself” put the host product on the stricter route.
Who owns what this quarter
| Role | Do now (Part A, plus Part B: legally due in 2027 but scheduled now because Article 14 leans on it) | For December 2027 (Part C) |
|---|---|---|
| CISO / PSIRT lead | A2 to A4, A7, A8; B1 to B3; one timed drill against the 24-hour clock | C3, C6 |
| Product / engineering lead | A1, A9; B4 | C2, C4, C5, C7, C8, C12 |
| Compliance officer / legal | A5, A6; review of the decision tree | C1, C9 to C11; notified-body booking |
| Board / managing director | Approve the decider and deputy, the support periods in B4 (a commercial commitment) and the budget for the Part B tooling | Approve the conformity-route budget for important (Class I/II) and critical products |
SME owners without a PSIRT: the Part A items fit on two pages and two named people: a decider who also drafts, and an out-of-hours deputy. What you can’t skip is A1. Without a product list, nobody can tell whether an exploit report concerns you.
What a missed item costs
Plain-language summary: the top fine tier covers Article 14 and the core 2027 obligations, though how an Article 14 breach before 11 December 2027 is sanctioned is unresolved (see below).
| Breach | Maximum administrative fine (higher of) | Where it bites in this checklist |
|---|---|---|
| Annex I essential requirements; Articles 13 and 14 | EUR 15 million or 2.5% of worldwide annual turnover | Part A (reporting, subject to the timing question below), Part B, and every Part C item anchored in Article 13 or Annex I |
| Articles 18 to 23, 28, 30(1) to (4), 31(1) to (4), 32(1) to (3) and others | EUR 10 million or 2% of worldwide annual turnover | The conformity route under Art. 32(1) to (3) (C9; the critical-product route in Art. 32(4) is not listed in Art. 64(3)), technical documentation (C10), declaration and CE marking (C11), importer and representative duties (C12). An item anchored in both Article 13 and one of these articles can fall under either tier |
| Incorrect, incomplete or misleading information to notified bodies or market surveillance authorities in reply to a request | EUR 5 million or 1% of worldwide annual turnover | Incorrect, incomplete or misleading information or documentation you supply in reply to a request from a notified body or market surveillance authority |
Fines are not the only lever: from 11 December 2027, market surveillance authorities can also restrict, withdraw or recall a product. Fine levels are set by Article 64; Member States lay down the penalty rules and authorities weigh company size. Article 64(10)(a) exempts microenterprises and small enterprises from fines for missing the two 24-hour early-warning deadlines only; the 72-hour and final reports stay enforceable, and the early warning itself is still owed. The original Official Journal text worded paragraph 10 as a derogation “from paragraphs 3 to 9”, which left the Article 14 fine in paragraph 2 outside it. A corrigendum of 2 July 2025 changed that to “paragraphs 2 to 9”, so the exemption now plainly reaches it. Older commentary that flags a gap here is out of date, and some reproductions of the text, including the article mirror linked above, still show the pre-corrigendum wording.
One open timing question: Article 71(2) brings forward Article 14 and Chapter IV, but not Article 64 itself. The Commission services’ CRA FAQ (section 7.1) says “the provisions on market surveillance and enforcement, as well as all the other provisions set out in the CRA, apply from 11 December 2027”, and neither it nor the guidance says how an Article 14 breach before that date is sanctioned. National CRA implementing laws may settle it. The reporting duty itself has been binding law since 11 September 2026, so plan as if it is enforced.
Frequently asked questions
Is CRA Article 71(2) the provision that sets the deadlines?
For the application dates, yes; which pre-December-2027 products are caught is decided by Article 69 (transitional provisions). Article 71(2) sets 11 December 2027 as the general application date and makes two exceptions: Article 14 from 11 September 2026 and Chapter IV (notified bodies, Articles 35 to 51) from 11 June 2026. The regulation entered into force on 10 December 2024, as the Commission’s summary of the CRA confirms.
Do products placed on the market before 11 December 2027 need CE marking under the CRA?
The test applies per unit. Hardware units placed on the market before that date don’t, unless substantially modified (Article 69(2)); for software, on our reading of the guidance, the same goes for versions first offered before that date. Units of an older model shipped from 11 December 2027, however, are newly placed on the market and need a risk assessment, conformity assessment, EU declaration of conformity and CE marking; the Commission’s guidance (para. 33) adds that compliance “does not necessarily require that those units … be redesigned”. And Article 14 reporting covers all of these products already.
Should we register on ENISA’s Single Reporting Platform now?
ENISA’s FAQ (15 October 2026) advises registering and starting validation only when you need to submit a notification. Create EU Login accounts with multi-factor authentication for your filers now, decide who will be the Primary Assigned Representative, and confirm your coordinator CSIRT.
Do we need an SBOM before December 2027?
Not as a legal duty yet. Annex I Part II(1), which requires it, applies from 11 December 2027, and only to units and versions placed on the market (or substantially modified) from that date; units placed earlier, and on our reading software versions first offered earlier, don’t need one unless substantially modified. Part B still lists it because, in practice, you need a component inventory now, because the A4 test (is the flaw exploited in your product?) starts with knowing whether the component is in it, and the B1 SBOM is the practical way to keep one.
Key takeaways
Sort the CRA checklist by date, not topic. Nine items serve the reporting duty that has applied since 11 September 2026 to your whole in-scope installed base, unsupported products included. Four 2027 obligations (SBOM, intake channel, vulnerability records, support periods) make those nine far easier to meet. Part C’s twelve items fall due on the same day as Part B’s four, 11 December 2027, and cover every hardware unit shipped from that date, however old the design. If you do one thing this month, build the A1 product inventory: every other reporting item depends on it.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal text — EUR-Lex. Articles 2, 3(42), 7, 8, 13, 14, 16, 18 to 23, 27, 28, 30 to 32, 64, 69, 71; Chapter IV; Annexes I to V and VII.
- Directive (EU) 2022/2555 (NIS2), Official Journal text — EUR-Lex. Article 21 and Article 23 (reporting obligations).
- Corrigendum to Regulation (EU) 2024/2847, OJ L 2025/90555, 2 July 2025 — EUR-Lex. Article 64(10).
- Cyber Resilience Act, Article 13 (Obligations of manufacturers) — unofficial reproduction of the Official Journal text, european-cyber-resilience-act.com.
- Cyber Resilience Act, Article 14 (Reporting obligations of manufacturers) — unofficial reproduction of the Official Journal text, european-cyber-resilience-act.com.
- Cyber Resilience Act, Article 32 (Conformity assessment procedures) — unofficial reproduction of the Official Journal text, european-cyber-resilience-act.com.
- Cyber Resilience Act, Article 64 (Penalties) — unofficial reproduction of the Official Journal text, european-cyber-resilience-act.com.
- Cyber Resilience Act, Article 69 (Transitional provisions) — unofficial reproduction of the Official Journal text, european-cyber-resilience-act.com.
- Cyber Resilience Act, Article 71 (Entry into force and application) — unofficial reproduction of the Official Journal text, european-cyber-resilience-act.com.
- Commission guidance on the application of Regulation (EU) 2024/2847, Annex to C(2026) 5252 final, 27 July 2026 — European Commission. Paras. 11, 13 to 15, 21, 33 to 36, 210, 212, 213, 218.
- Commission Implementing Regulation (EU) 2025/2392 on the technical description of the categories of important and critical products with digital elements — EUR-Lex, OJ L 1.12.2025.
- CRA Single Reporting Platform: Frequently Asked Questions, FAQ 9, updated 15 October 2026 — ENISA.
- FAQs on the Cyber Resilience Act implementation — European Commission services. Section 7.1.
- The Cyber Resilience Act: summary of the legislative text — European Commission, Shaping Europe’s digital future.
- Cyber Resilience Act: standardisation (standardisation request M/606) — European Commission, last updated 31 July 2026.
- Current status of standardisation for the Cyber Resilience Act, last amended 6 October 2026 — ibf solutions.
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
