The EU Cyber Resilience Act: A Manufacturer’s Compliance Guide for 2026–2027

Since 11 September 2026, a manufacturer that learns one of its products is being attacked through a software flaw has 24 hours to file an early warning with the authorities. Not 24 hours to fix it. Twenty-four hours to report it. That deadline, set by Article 14 of the EU Cyber Resilience Act, is the first hard obligation product companies face under the new law. It already applies, more than a year before the rest of the regulation does, and reports now go through ENISA’s live Single Reporting Platform.

The Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, is the EU’s first horizontal cybersecurity law for hardware and software. It entered into force on 10 December 2024 and applies in full from 11 December 2027. If you make, import, or distribute a connected product anywhere in the world and sell it into the EU, it almost certainly covers you. This guide maps the whole regulation the way a product-security or compliance lead needs to read it: who is in scope, what the obligations actually are, the two reporting clocks that have run since September 2026, conformity assessment and CE marking, the penalties, how the CRA differs from NIS2, and a practical path to getting ready.

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.

Updated 6 October 2026: the reporting obligations and ENISA’s Single Reporting Platform are now live; the platform section reflects ENISA’s published FAQ.

The deadlines that matter, on one page

Most coverage of the CRA anchors on 11 December 2027, the full-application date. That is a mistake. The obligation that bit first, and the one with the shortest fuse once an incident happens, is reporting, which has applied since 11 September 2026. If your reporting workflow is not in place yet, that is the gap to close before anything else.

Date	What applies	What you must have ready
10 December 2024	Entry into force (Article 71)	Nothing yet, but the clock to readiness starts here
11 June 2026	Notified-body provisions (Chapter IV, Articles 35-51)	Conformity assessment bodies can begin getting designated
11 September 2026 (in force)	Article 14 reporting obligations; ENISA Single Reporting Platform live	24h/72h reporting workflow, registered platform users, decision criteria for what is reportable
11 December 2027	Full application: essential requirements, conformity assessment, CE marking, technical documentation	Secure-by-design product, vulnerability handling process, CE marking, technical file

The split matters because the work behind each date is different. Reporting readiness is a process and governance problem you can solve in weeks, and it is already due; full conformity is a product-engineering and documentation programme that, for complex products, takes most of the time left until 2027. The dates come from Article 71 and are confirmed on the European Commission’s CRA summary.

What the Cyber Resilience Act actually is

Plain-language summary: the CRA sets baseline cybersecurity rules for almost every product that contains software or connects to a network, and it makes the manufacturer responsible for keeping that product reasonably secure for its expected lifetime, not just on the day it ships.

Until now, EU product law treated cybersecurity as an afterthought: a connected toy or a building-management controller could be CE-marked for electrical safety while shipping with hard-coded passwords and no way to receive security updates. The CRA closes that gap by adding cybersecurity to the CE-marking regime. The mechanism is deliberate: tying security to CE marking makes a non-compliant product one that cannot lawfully be sold, a far sharper lever than a fine after the fact.

Two ideas drive the whole regulation. First, secure by design: products must be built and shipped with an appropriate level of cybersecurity given their intended use. Second, vulnerability handling across the lifetime: the manufacturer must find, fix, and disclose security flaws for as long as the product is reasonably expected to be in use, and provide security updates to do it. Everything else in the law, including the reporting duties, follows from those two commitments.

Who is in scope: “products with digital elements”

The CRA applies to products with digital elements placed on the EU market. The European Commission defines this as software or hardware products and their remote data processing solutions, including software or hardware components placed on the market separately. In practice, if a product contains code, or talks to something that does, assume it is in scope until you can show otherwise.

The regulation then sorts in-scope products into risk tiers, because the conformity route gets stricter as risk rises:

Category	Where it is defined	Examples (illustrative)	Conformity route
Default products with digital elements	Body of the regulation	Most connected consumer and business products	Self-assessment against the essential requirements
Important products, Class I	Annex III	Password managers, network management software, VPNs, browsers, certain IoT	Self-assessment if a harmonised standard is applied; otherwise third-party assessment
Important products, Class II	Annex III	Higher-risk categories such as operating systems, firewalls, microcontrollers in some uses	Third-party (notified-body) assessment
Critical products	Annex IV	Hardware devices with security boxes, smart-meter gateways, smartcards and similar	Strictest route, potentially requiring European cybersecurity certification

The precise lists in Annex III and Annex IV are technical, and the detailed product descriptions sit in a separate Commission Implementing Regulation, (EU) 2025/2392, rather than in the CRA itself. Treat the examples above as orientation, not a classification decision: confirm your product’s exact category against the current Annex III/IV text before you choose a conformity route.

Non-EU manufacturers are squarely in scope

This catches exporters by surprise, so it is worth stating bluntly. The CRA applies to products placed on the Union market regardless of where the manufacturer is established. A US, UK, or Asian company selling a connected product into the EU carries the same obligations as a German one. If you have no EU establishment, you will generally need an EU-based importer and, in many cases, an authorised representative to carry compliance responsibilities such as keeping the technical documentation available to authorities. The market, not your headquarters, determines whether the law reaches you.

One nuance: the CRA itself makes the authorised representative optional, because Article 18(1) says a manufacturer “may” appoint one. Our guide to the CRA for non-EU manufacturers explains when other EU product law still requires an EU-based operator, and how the Article 14(7) ladder decides which CSIRT receives your reports if you have no main establishment in the EU.

Legacy and already-marketed products

The CRA is not purely forward-looking; products already on the market are not exempt simply because they shipped before the dates. The clearest practical trigger is change: where a product is substantially modified after the application dates, it is generally treated as a new product and the full requirements apply to the modified version. Reporting is the exception that reaches back: under Article 69(3), the Article 14 obligations apply to all in-scope products placed on the market before 11 December 2027, not only to new ones, so an actively exploited flaw in an older but still-supported product that you become aware of now is reportable. Keep an inventory of supported products and their support windows so you can answer “is this one in scope” without scrambling during an incident.

The manufacturer’s obligations

Plain-language summary: build it securely (Annex I Part I), keep finding and fixing flaws for the product’s lifetime (Annex I Part II), prove it (conformity assessment and a technical file), mark it (CE), and report serious problems fast (Article 14).

Secure by design: Annex I Part I

Annex I Part I lists the essential cybersecurity requirements a product must meet by design and by default. They are outcome-based rather than a checklist of named technologies, which means you document how each applies to your product. The recurring themes: ship with a secure default configuration; protect against unauthorised access, including by appropriate authentication; protect the confidentiality and integrity of data; minimise attack surface and the data the product processes; and provide a mechanism to deliver security updates, where the product’s nature allows it. Article 13 ties these together as the core duties of the manufacturer placing the product on the market.

Vulnerability handling: Annex I Part II

Annex I Part II is where many companies have the most work to do, because it demands an ongoing process, not a one-time gate. It requires manufacturers to:

• Identify and document the vulnerabilities and components in the product, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies.
• Address and remediate vulnerabilities without delay, including by providing security updates, and where technically feasible, deliver them automatically with a clear opt-out.
• Apply effective and regular security tests and reviews.
• Publicly disclose information about fixed vulnerabilities once an update is available, including a description and remediation guidance.
• Operate a coordinated vulnerability disclosure policy and provide a contact address so researchers and users can report problems.

The SBOM requirement is frequently overstated by tooling vendors. The CRA requires you to draw up and keep an SBOM, in a common machine-readable format, and make it available to market surveillance authorities on request. It does not require you to publish it to the world. The legal obligation and the commercial pitch for a continuous SBOM scanner are not the same thing, so separate them when you budget.

For the eight Part II duties turned into a seven-step procedure with owners, records and the evidence file a market surveillance authority can request, see our guide to CRA vulnerability handling requirements as a PSIRT procedure.

Reporting: Article 14, the duty with the shortest clock

Since 11 September 2026, Article 14 has required manufacturers to report two distinct things, on two parallel timelines. Both clocks start when you become aware, and you report to the CSIRT designated as coordinator and to ENISA simultaneously through one platform. Which events actually start those clocks, and when you count as aware, is worked through with a decision tree and nine cases in our guide to actively exploited vulnerabilities under the CRA.

Track 1: an actively exploited vulnerability in your product.

Stage	Deadline from awareness	What it contains
Early warning (Art 14(2)(a))	Within 24 hours	Initial heads-up that an actively exploited vulnerability exists
Vulnerability notification (Art 14(2)(b))	Within 72 hours	Fuller detail: nature, any corrective or mitigating measures taken
Final report (Art 14(2)(c))	No later than 14 days after a corrective or mitigating measure is available	Description, severity and impact, any known exploitation, the fix

Track 2: a severe incident having an impact on the security of your product.

Stage	Deadline from awareness	What it contains
Early warning (Art 14(4))	Within 24 hours	Initial notification that a severe incident has occurred
Incident notification (Art 14(4))	Within 72 hours	Assessment of the incident, including severity and impact
Final report (Art 14(4))	Within one month of the incident notification	Detailed description, root cause, mitigations applied

Note the two tracks have different final-report clocks: the vulnerability final report is keyed to when a fix becomes available (14 days after), while the incident final report is a fixed one month after the 72-hour notification. Mixing these up is the most common reporting error, because the headlines only ever mention “24 and 72 hours.”

For both tracks on one worked timeline, what each of the six filings must contain, and how the deadlines are counted (including the portal counter that runs from 48 hours after the early warning), see our guide to CRA reporting requirements.

There is a third duty that is easy to miss. Under Article 14(8), after becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform the impacted users of the product, and where appropriate all users, about it and, where necessary, about the risk-mitigation and corrective measures they can take. Regulatory reporting does not discharge your duty to your customers, and the two communications serve different audiences. Article 14(8) sets no hour count for the user notice; our guide to CRA severe incident reporting and the user notice reads the provision clause by clause and explains when to send it.

The Single Reporting Platform: how reports are actually filed

The mechanics matter because the deadlines are short. Reports are not emailed to 27 different national authorities. They go through one channel: the Single Reporting Platform (SRP), which Article 16 establishes and ENISA operates. It went live on 11 September 2026 at portal.cra-srp.enisa.europa.eu. You file once: the report reaches the CSIRT designated as coordinator for your company and ENISA at the same time, and the coordinator CSIRT shares it with the other member states where the product is available (European Commission).

What ENISA’s SRP FAQ says you need before the first real report:

Platform rule (ENISA FAQ)	What it means for your team
Every user needs an EU Login account with multi-factor authentication (FAQ 9)	Set up EU Login and MFA for each person who may file, before an incident
One Primary Assigned Representative per manufacturer, who invites up to 20 Secondary representatives (FAQ 9)	Name a deputy now, but expect a wait: the Primary AR can invite a Secondary AR only once the CSIRT shows the association as “Verified”
The coordinator CSIRT verifies that each representative acts for your company; you can submit while verification is pending, up to 20 notifications (FAQ 9)	ENISA advises registering only when you need to file; Finland’s national CSIRT lists registration of both representatives in its preparation checklist, so ask your coordinator CSIRT what it expects
No API at launch; notifications are entered through the interface, which is in English only at launch (FAQ 15, FAQ 24)	Pre-draft reports offline in English and copy them in; budget time for manual entry
Non-EU manufacturers report to the CSIRT of their authorised representative, then importer, then distributor, then the member state with most users (FAQ 18)	Record which rule applies to you and why
If the platform is temporarily unavailable, wait and submit when it is back; contact the CSIRT directly only where immediate communication is necessary (FAQ 25)	Log the outage with timestamps; the formal submission through the platform is still required

ENISA also publishes a user manual, step-by-step guides, a field glossary and a helpdesk address on its SRP page. The practical lesson has not changed: the people who would file at 02:00 during an incident need working accounts and a rehearsed workflow before they need them. A 24-hour clock is not the moment to discover you have no account. Our ENISA Single Reporting Platform walkthrough follows registration screen by screen, including why a deputy cannot be added until the CSIRT verifies the Primary AR and why platform drafts stay invisible to everyone but their author.

The glossary is also where the platform’s required fields differ from the minimum content Article 14 sets. Our CRA vulnerability reporting template guide maps all six report forms, early warning, notification and final report on both tracks, field by field against it.

Conformity assessment and CE marking

Plain-language summary: before a product can be sold from 11 December 2027, you must run it through a conformity assessment, draw up a technical file and an EU declaration of conformity, and affix the CE mark.

The route depends on the risk tier from the scope table above. Default products with digital elements can use internal self-assessment, where you demonstrate conformity with the essential requirements yourself and document it. Important products in Annex III may use self-assessment when a relevant harmonised standard is applied, and otherwise need third-party involvement; Class II generally requires a notified body. Critical products in Annex IV face the strictest route and may require European cybersecurity certification. In every case you produce technical documentation that evidences how the product meets Annex I, and you issue an EU declaration of conformity before affixing the CE mark. The notified-body system itself only switches on from 11 June 2026 (Chapter IV), which is why that earlier date appears in the timeline: bodies need to be designated before they can assess anyone.

Penalties: what non-compliance costs

Plain-language summary: the most serious breaches can cost up to 15 million euro or 2.5 percent of worldwide turnover, enforced by national market surveillance authorities, who can also order a product off the market.

Article 64 sets three tiers of administrative fines:

Breach	Maximum fine (whichever is higher)
Non-compliance with the essential requirements (Annex I) and the obligations in Articles 13 and 14	EUR 15,000,000 or 2.5% of total worldwide annual turnover
Non-compliance with most other obligations under the regulation	EUR 10,000,000 or 2% of total worldwide annual turnover
Supplying incorrect, incomplete, or misleading information to notified bodies or authorities	EUR 5,000,000 or 1% of total worldwide annual turnover

The top tier is the one that matters most for the topics in this guide, because secure-by-design (Annex I), the manufacturer duties (Article 13), and reporting (Article 14) all sit in it. Fines are not the only consequence. Enforcement runs through national market surveillance authorities, who can require corrective action, restrict a product’s availability, or order its withdrawal or recall from the market. For a product business, losing the right to sell into the EU is usually a larger threat than the fine. The Commission’s summary also notes proportionality safeguards: microenterprises and small enterprises may not be fined for missing certain reporting deadlines, and open-source software stewards are not subject to these penalties, reflecting the regulation’s lighter touch for non-commercial open source.

CRA vs NIS2: different laws that can both apply

This is the single most common point of confusion, and getting it wrong leads companies to either double up unnecessarily or assume one law covers the other. They do not. The CRA and the NIS2 Directive regulate different things and can apply to the same company at the same time.

Dimension	Cyber Resilience Act (CRA)	NIS2 Directive
Legal form	Regulation (EU) 2024/2847 – directly applicable EU-wide	Directive (EU) 2022/2555 – transposed into each member state’s law
Regulates	The product you sell	The organisation that operates essential or important services
Who it targets	Manufacturers, importers, distributors of products with digital elements	Medium and large entities in covered sectors (energy, health, digital infrastructure, manufacturing of certain products, and more)
Core duty	Secure-by-design products, vulnerability handling, CE marking, Article 14 reporting	Risk management measures, governance, and incident reporting at the entity level
Report what, where	Actively exploited vulnerabilities and severe product incidents, via the ENISA Single Reporting Platform	Significant incidents affecting your services, to your national CSIRT/competent authority
Key dates	Reporting from 11 Sep 2026; full application 11 Dec 2027	Already applicable; national transposition ongoing

A worked example shows why both can apply. Suppose you manufacture industrial network controllers and also run the cloud service that manages them. Your controllers are products with digital elements, so the CRA governs how you build them and obliges you to report an actively exploited vulnerability in them through the SRP. Separately, if your organisation qualifies as an important or essential entity under NIS2, that directive governs how you manage risk across your operations and obliges you to report significant incidents affecting your services to your national authority. Same company, two regimes, two reporting channels. For a fuller side-by-side, see the dedicated NIS2 vs CRA comparison; if you are new to the directive itself, start with the NIS2 scope overview. Notably, NIS2 itself anticipates this overlap in its own provisions on coordinated vulnerability disclosure and incident notification.

How to get ready: close the reporting gap now, then work toward December 2027

Plain-language summary: reporting readiness is already due, so solve it first; then run the longer product-conformity programme in parallel toward 11 December 2027.

Treat readiness as two streams with different deadlines. For both streams as one dated list of 25 items, each with its legal anchor and the evidence to keep, use our CRA compliance checklist.

For the documents behind both streams, mapped one by one to Article 13, Article 14 and Annex I Part II with the date each applies, see our guide to CRA templates.

Stream 1: reporting readiness (already due: Article 14 applies now)

1. Confirm scope. Inventory your products, decide which are products with digital elements, and for each note whether it is default, important (Annex III), or critical (Annex IV). Include legacy products still under support.
2. Establish the reporting channel. Identify your main establishment, therefore your coordinating CSIRT, and register a Primary and at least one Secondary Assigned Representative on the ENISA Single Reporting Platform, each with EU Login and multi-factor authentication.
3. Write the procedures. Document who decides what is reportable, who drafts each report, and who can authorise submission within 24 hours, including out of hours. Define the difference between an actively exploited vulnerability and a severe incident so the right clock starts.
4. Stand up a contact point and CVD policy. Publish a security contact and a coordinated vulnerability disclosure policy so external reports reach you in the first place.
5. Rehearse. Run a tabletop exercise against the 24-hour clock. The first time your team fills in an early-warning report should not be during a live exploit.

Stream 2: product conformity (target 11 December 2027)

1. Gap-assess against Annex I. For each product, map current state to the essential requirements (Part I) and vulnerability-handling requirements (Part II); rate the effort to close each gap as low, medium, or high.
2. Build the SBOM process. Generate machine-readable SBOMs (SPDX or CycloneDX both work) and integrate them into your build pipeline.
3. Choose and start the conformity route. For Annex III Class II and Annex IV products, engage a notified body early, since assessment capacity will be in demand as 2027 approaches.
4. Assemble the technical file and prepare the EU declaration of conformity ahead of CE marking.

Frequently asked questions

When does the Cyber Resilience Act apply?

The CRA entered into force on 10 December 2024 and applies in full from 11 December 2027. The exceptions are the Article 14 reporting obligations on actively exploited vulnerabilities and severe incidents, which have applied since 11 September 2026, and the notified-body provisions, which have applied since 11 June 2026.

How do you file a report on the CRA Single Reporting Platform?

Through ENISA’s portal at portal.cra-srp.enisa.europa.eu, live since 11 September 2026. Each person who files needs an EU Login account with multi-factor authentication; one Primary Assigned Representative registers the manufacturer and can invite up to 20 Secondary representatives, according to ENISA’s SRP FAQ. There is no API at launch, so reports are entered through the interface.

Does the CRA apply to non-EU manufacturers?

Yes. The CRA applies to products with digital elements placed on the EU market regardless of where the manufacturer is established. A company outside the EU that sells a connected product into the EU has the same obligations as an EU-based manufacturer and will generally need an EU importer, and often an authorised representative, to carry certain compliance responsibilities.

What is a “product with digital elements”?

It is any software or hardware product, and its remote data processing solutions, including components placed on the market separately. In practice, most products that contain software or connect to a network are in scope. Risk tiers (default, important under Annex III, critical under Annex IV) then determine how strict the conformity route is.

What has to be reported under Article 14, and how fast?

Two things: an actively exploited vulnerability in your product, and a severe incident affecting the security of your product. Both require an early warning within 24 hours of becoming aware and a fuller notification within 72 hours, filed via the ENISA Single Reporting Platform. The final report is due within 14 days of a fix being available for a vulnerability, or within one month of the notification for a severe incident.

What are the penalties for non-compliance?

Under Article 64, breaches of the essential requirements (Annex I) and the obligations in Articles 13 and 14 can attract fines of up to EUR 15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher. National market surveillance authorities can also restrict, withdraw, or recall a non-compliant product from the market.

Is the CRA the same as NIS2?

No. The CRA regulates the security of products you place on the market; NIS2 regulates how organisations in covered sectors manage cyber risk and report incidents at the entity level. They can both apply to the same company, with separate obligations and separate reporting channels.

Do I have to publish my SBOM?

No. The CRA requires you to draw up an SBOM in a commonly used machine-readable format and make it available to market surveillance authorities on request. There is no obligation to publish it publicly.

Key takeaways

The CRA turns cybersecurity into a condition of selling a connected product in the EU, backed by CE marking and fines of up to 15 million euro or 2.5 percent of worldwide turnover. The work divides cleanly: reporting readiness has been mandatory since 11 September 2026, so if it is not in place it is overdue; full product conformity, due 11 December 2027, is a longer engineering and documentation programme. The reporting clocks are unforgiving, 24 hours to an early warning, with two separate tracks for vulnerabilities and incidents, so the single highest-value move you can make now is to stand up and rehearse the reporting workflow before your first reportable event rather than after it. Scope your products, confirm your CSIRT, register your platform users, write the procedures, and test them.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), full text – EUR-Lex, Official Journal of the European Union
• Cyber Resilience Act, Article 14 (Reporting obligations of manufacturers)
• Cyber Resilience Act, Article 64 (Penalties)
• Cyber Resilience Act, Article 71 (Entry into force and application)
• The Cyber Resilience Act: Summary of the legislative text – European Commission, Shaping Europe’s digital future
• Cyber Resilience Act: Reporting obligations – European Commission
• Single Reporting Platform (SRP) – ENISA, European Union Agency for Cybersecurity
• ENISA, CRA Single Reporting Platform: Frequently Asked Questions (FAQ 9, 15, 18, 24, 25; checked 6 October 2026)
• ENISA, The CRA Single Reporting Platform is launched (11 September 2026)