Cyber Resilience Act: Obligations and Deadlines 2026-2027

Updated: 13 August 2026

What is the Cyber Resilience Act and when does it apply? The Cyber Resilience Act is an EU product regulation imposing cybersecurity requirements on manufacturers of hardware and software sold in the European Union. It entered into force on 10 December 2024 and most obligations apply from 11 December 2027. The nearest deadline falls much earlier: from 11 September2026 manufacturers must report actively exploited vulnerabilities and severe incidents, including in products sold years before.

Canonical definition: The Cyber Resilience Act (Regulation (EU) 2024/2847) is EU product legislation setting cybersecurity requirements for products with digital elements placed on the European Union market, covering the full product lifecycle and evidenced by CE marking.

Cyber Resilience Act – in brief:

The CRA covers products with digital elements, meaning hardware and software whose intended or reasonably foreseeable use includes a direct or indirect data connection.
The Article 14 reporting obligation starts on 11 September 2026: early warning within 24 hours, full notification within 72 hours, final report within 14 days of a corrective measure becoming available for vulnerabilities, and within one month for severe incidents.
Reports go through a single reporting platform operated by ENISA, addressed to the CSIRT of the member state where the manufacturer has its main establishment.
The obligation also covers products made available before the regulation applies in full, so legacy portfolios are not excluded.
Product classification determines the conformity assessment route: default products may self-assess, important products under Annex III require harmonised standards or a notified body, and critical products under Annex IV always involve a third party.
Penalties for breaching the essential requirements and manufacturer obligations reach EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher.
Patronusec delivers regulatory compliance projects and security testing for software and device manufacturers, pairing reporting-process readiness with technical verification of the product itself.

What is the Cyber Resilience Act and which products does it cover?

The Cyber Resilience Act is Regulation (EU) 2024/2847, setting horizontal cybersecurity requirements for products with digital elements. It is not an industry standard or a voluntary programme. It is product legislation embedded in the mechanics of the internal market, and compliance is signalled by the CE marking, without which the product cannot lawfully be sold in the EU.

The scope is wider than most teams assume on first reading:

Hardware and software together. A product with digital elements covers both a device carrying firmware and software in its own right, together with associated remote data processing solutions.
The connection criterion. If your product contains software or firmware and reaches the EU market, it is very likely in scope.
Economic role matters. A manufacturer, an importer and a distributor each carry different duties. A company selling another party’s product under its own brand takes on the manufacturer’s obligations.
Exclusions are narrow. Products governed by separate sectoral regimes sit outside. Classification has to be done product by product rather than assumed across a portfolio.

The European Commission clarified classification through Implementing Regulation (EU) 2025/2392, adopted on 28 November 2025, which describes in functional and technical terms what constitutes an operating system, a firewall, a secure element or a consumer device listed in Annexes III and IV. Classification follows the product’s core functionality, not each individual feature it contains.

The Cyber Resilience Act moves responsibility for product security from the user to the party placing the product on the market, and non-compliance restricts not only exposure to fines but the right to sell.

Which CRA deadlines apply, and which one comes first?

The CRA phases in, and its three dates correspond to three different kinds of readiness: institutional, operational and product. The nearest is 11 September 2026, when the obligation to report actively exploited vulnerabilities and severe incidents begins.

Date	What starts applying	Type of readiness
10 December 2024	regulation enters into force	no operational duties yet
11 June 2026	rules on notifying conformity assessment bodies; member states designate notifying authorities	institutional
11 September 2026	Article 14 reporting obligation, covering products already on the market	operational
11 December 2027	full application: essential requirements, technical documentation, conformity assessment, CE marking	product

The staggering causes an expensive planning error. Teams schedule the compliance programme against December 2027 and treat September 2026 as an administrative formality, when in fact the reporting duty requires a working process for detecting, classifying and escalating events, not just a form. To report a vulnerability in a product, you first have to know what that product contains.

Patronusec Insight: The same pattern recurs across regulatory projects: the organisation treats the reporting deadline as a legal workstream when it is an engineering workstream with a legal deadline. Twenty-four hours for an early warning means the process has to function at a weekend, during holiday cover, and on a first report arriving from an external researcher. Before drafting procedures we usually test one thing: whether anyone can reconstruct the component list for a product version sold three years ago. If not, that is the first project, not the procedure. We typically run that groundwork under an IT Compliance Officer arrangement, which combines process work with oversight of the implementation.

Is your product in scope, and which class does it fall into?

Classification runs in two stages: first whether the product falls within the regulation at all, then which of three categories applies. The category determines the conformity assessment route, so an error here changes the budget and timeline of the whole programme.

Does the product contain software or firmware and reach the EU market?
  NO  -> outside CRA scope
  YES -> Does intended or foreseeable use include a data connection
         (direct or indirect)?
        NO  -> outside scope
        YES -> Does the core functionality match an Annex IV category?
               YES -> CRITICAL product: notified body involvement is
                      mandatory in every case
               NO  -> Does the core functionality match an Annex III
                      category?
                      YES -> IMPORTANT product (Class I or II): self-
                             assessment only where harmonised standards,
                             common specifications or a certification
                             scheme are applied; otherwise a notified body
                      NO  -> DEFAULT product: self-assessment permitted

Three rules settle the most common questions:

Core functionality decides, not components. Embedding a component from an important category does not make the whole product important. What matters is what the product is fundamentally for.
Where several categories fit, the stricter applies. This removes any incentive to pick the more convenient route.
Baseline duties apply to everyone. The default category does not exempt a manufacturer from the essential requirements or from a cybersecurity risk assessment. It changes only how conformity is demonstrated.

Important categories include operating systems, firewalls, antivirus software and routers; the Implementing Regulation additionally described smart home virtual assistants, smart home security devices, internet-connected toys and wearables used for health monitoring. Critical categories include smart cards, secure elements and smart meter gateways.

What exactly must be reported from 11 September 2026, and within what deadlines?

Two kinds of event are reportable: an actively exploited vulnerability in a product with digital elements, and a severe incident affecting the security of that product. A manufacturer reports once, through a single platform operated by ENISA, addressed to the CSIRT of the member state where it has its main establishment.

The three stages and their deadlines:

Early warning within 24 hours of becoming aware of the event.
Full notification within 72 hours, describing the event and the measures taken.
Final report no later than 14 days after a corrective measure becomes available for an actively exploited vulnerability, and within one month for a severe incident.

Not every vulnerability crosses the threshold. The duty attaches to an actively exploited vulnerability, meaning one with evidence of real-world exploitation. A proof of concept or a research finding without confirmed exploitation does not start the clock.

Two circumstances are routinely missed in planning. First, the obligation covers products made available on the EU market before the regulation applies in full, so an industrial controller or an application sold five years ago remains in scope. Second, manufacturers that qualify as micro or small enterprises may not be fined for missing the 24-hour deadline, although the reporting obligation itself still applies to them.

The CRA reporting duty measures response time rather than documentation quality: the clock starts when the manufacturer becomes aware, not when internal analysis concludes.

A few weeks to 11 September 2026, and no confidence your reporting process holds under pressure?

We run a reporting readiness review: whether you can detect and classify an event, whether you hold a component inventory for the product versions in the field, and whether the escalation path fits inside 24 hours. The output is a gap list with deadlines and named owners.

Book a free CRA readiness call

What has to be in place by 11 December 2027?

From 11 December 2027 a product placed on the EU market must meet the CRA essential requirements and carry complete documentation evidencing conformity. The requirements split into two groups: security properties of the product itself, and vulnerability handling processes maintained throughout the support period.

The principal product and process duties:

A cybersecurity risk assessment carried out for the product and documented, forming the basis for the controls selected.
Secure default configuration and design that limits the attack surface.
A component inventory, including an SBOM in a commonly used, machine-readable format. Without it, vulnerability handling remains a declaration rather than a process.
A support period set by the manufacturer and reflecting the period the product is reasonably expected to be in use. Commission guidance indicates this should generally be at least 5 years unless expected use is shorter.
Free security updates and vulnerability handling processes for the duration of the support period.
Technical documentation retained for 10 years from the product being placed on the market, an EU declaration of conformity, and CE marking.

The practical difficulty is that none of this can be bolted on at the end. The support period has to be planned into the commercial model and the SBOM into the build process. Retrofitting compliance onto a product ready for release costs several times more than designing these elements into the development cycle.

Patronusec Insight: Manufacturers most often underestimate the support period, because they look at the sales cycle rather than the usage cycle. In industrial automation and networking equipment the real service life is frequently double the assumed figure, and a declared support period is a regulatory commitment rather than a marketing promise. Before an organisation declares one, it is worth costing the maintenance of the dependency chain across that horizon. In practice this means running vulnerability scans across the whole supported version portfolio, not just the current development branch.

How does conformity assessment work, and when do you need a notified body?

Conformity assessment is the procedure confirming that essential requirements are met, concluding with an EU declaration of conformity and CE marking. The manufacturer keeps discretion over the procedure, except for important and critical products where the regulation requires a stricter route.

Three routes in practice:

Default products. Self-assessment is permitted regardless of the technical specification used. The manufacturer compiles the documentation and issues the declaration.
Important products (Annex III, Class I and II). Self-assessment is available only where the manufacturer has applied harmonised standards, common specifications or a European cybersecurity certification scheme. Otherwise a notified body must be involved.
Critical products (Annex IV). Notified body involvement is mandatory in every case.

This is where a genuine scheduling risk sits. The rules on notifying conformity assessment bodies apply only from 11 June 2026, and harmonised standards supporting the CRA are being developed in parallel with manufacturers’ own preparations. A company whose product falls into an important or critical category competes for a limited pool of notified bodies with the entire market, and the queue lengthens as December 2027 approaches.

What penalties does the CRA carry?

Penalties are tiered by the type of breach. Breaching the essential requirements and manufacturer obligations carries a fine of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher.

Type of breach	Maximum penalty
Essential requirements and manufacturer obligations	EUR 15m or 2.5% of worldwide turnover
Obligations of other economic operators and EU declaration of conformity requirements	EUR 10m or 2% of worldwide turnover
Supplying incorrect, incomplete or misleading information to a market surveillance authority	EUR 5m or 1% of worldwide turnover

The fine is not the sharpest sanction. Enforcement sits with market surveillance authorities, which can order a product to be withdrawn from the market or recalled from users. For a manufacturer that means sales stop in the EU, rather than a one-off cost. It is also worth noting that open-source software stewards are not liable to fines for CRA infringements.

What must be ready before 11 September 2026?

A checklist written from the perspective of an assessor reviewing reporting readiness. Each item corresponds to a question that actually gets asked.

Is there a current list of products in CRA scope, including versions sold in previous years and still in use?
Can a component inventory be reconstructed for every supported version, including external dependencies?
Has “actively exploited” been defined operationally, so the team can apply it without legal consultation on every report?
Is there a channel for receiving reports from external researchers, and does someone own it outside working hours?
Does the escalation path fit inside 24 hours, including the decision to report rather than just internal notification?
Is a named individual accountable for the report, with cover for absence?
Has the organisation registered on the reporting platform and tested the path before the first real event?
Does the process cover products supplied by subcontractors, and do contracts oblige them to inform you in time to meet the deadline?

Items one to three determine whether the rest are achievable at all. An organisation without a component inventory cannot establish whether a reported vulnerability affects its product, and that decision has to be made within a day.

FAQ – Cyber Resilience Act

Does the Cyber Resilience Act apply to software sold as a service?

As a general rule the CRA covers products with digital elements placed on the market rather than services. The boundary is not sharp, because the regulation also captures remote data processing solutions associated with a product. A SaaS model should be classified individually, taking the delivery architecture into account.

Does the CRA apply to manufacturers outside the European Union?

Yes, where the product is made available on the EU market. What matters is where the product is placed on the market, not where the manufacturer is established. A non-EU manufacturer meets the obligations directly or through an authorised representative, while importers and distributors carry their own separate duties.

Does NIS2 or ISO 27001 compliance mean CRA compliance?

No. NIS2 addresses the security of an organisation providing services and ISO 27001 an information security management system. The CRA governs the security of a specific product placed on the market. A mature management system makes CRA implementation easier and supplies some evidence, but it does not replace product conformity assessment.

Does every discovered vulnerability have to be reported?

No. The duty applies to actively exploited vulnerabilities, meaning those with evidence of real-world exploitation, and to severe incidents affecting the security of the product. A proof of concept or research finding without confirmed exploitation does not trigger the reporting obligation.

How long must technical documentation be retained?

For 10 years from the product being placed on the market. The technical documentation is the evidence file for market surveillance authorities and must cover the risk assessment, a description of the security controls, and evidence of the conformity assessment carried out.

How does Patronusec support CRA preparation?

We run a readiness review covering product classification, assessment of the reporting process, and technical verification of the product through security testing. Following a free scope assessment call we provide a fixed quotation with a delivery date for the report.

Blog space

Cyber Resilience Act (CRA) – 11 September 2026 starts mandatory vulnerability reporting. What you need in place?

In this article you will learn:

Table of Contents