The EU Cyber Resilience Act: A Manufacturer’s Compliance Guide to the 2026 Deadline

From 11 September 2026, a manufacturer that learns one of its products is being attacked through a software flaw will have 24 hours to file an early warning with the authorities. Not 24 hours to fix it. Twenty-four hours to report it. That single deadline, buried in Article 14 of the EU Cyber Resilience Act, is the first hard date most product companies will hit under the new law, and it arrives more than a year before the rest of the regulation applies in full.

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 start in 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.

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 bites first, and the one with the shortest fuse once an incident happens, is reporting, which applies from 11 September 2026. Anchor your planning to the earlier date.

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	Article 14 reporting obligations	24h/72h reporting workflow, ENISA platform access, 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 largely solve in 2026; 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.

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 from 11 September 2026 also operates on what you become aware of from that date, so an actively exploited flaw in an older but still-supported product can become 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.

Reporting: Article 14, the duty with the shortest clock

From 11 September 2026, Article 14 requires 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.

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.”

There is a third duty that is easy to miss. Under Article 14(8), where appropriate, the manufacturer must inform the impacted users of the product about the vulnerability or incident and about any 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.

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 the regulation establishes under Article 16 and tasks ENISA with operating. According to ENISA, the SRP is the technical tool through which manufacturers and CSIRTs handle mandatory reporting of actively exploited vulnerabilities and incidents, and it becomes mandatory from 11 September 2026.

The design intent, set out on the European Commission’s reporting page, is one submission that routes to the right place: a manufacturer reports to the CSIRT of the member state where it has its main establishment, and the report is shared simultaneously with ENISA. You file once; the platform distributes. The operational implication is simple but easy to defer: identify now which member state hosts your main establishment, therefore which CSIRT is your coordinator, and make sure the people who would actually file at 02:00 during an incident have platform access and know the workflow before they need it. A 24-hour clock is not the moment to discover you have no account.

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: a practical path to 11 September 2026

Plain-language summary: solve reporting readiness first because its deadline is earliest and its scope is narrowest, then run the longer product-conformity programme in parallel toward 2027.

Treat readiness as two streams with different deadlines.

Stream 1: reporting readiness (target 11 September 2026)

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 prepare for ENISA Single Reporting Platform access ahead of go-live.
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 exception is the Article 14 reporting obligations on actively exploited vulnerabilities and severe incidents, which apply earlier, from 11 September 2026, and the notified-body provisions, which apply from 11 June 2026.

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, due 11 September 2026, is a process you can build this year; 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 the deadline rather than after an exploit. Scope your products, confirm your CSIRT, 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