Cyber Resilience Act Compliance: What Is Required, and What Is Already Live

TL;DR Cyber Resilience Act compliance means meeting the Annex I essential requirements and running the vulnerability-handling processes behind them, for the whole supported life of the product. The obligations are phased. Article 14 reporting of actively exploited vulnerabilities and severe incidents applies from September 11, 2026, and under Article 69(3) it reaches products already on the EU market. Everything else, including conformity assessment and CE marking, applies from December 11, 2027. Penalties reach €15 million or 2.5% of worldwide annual turnover.

The first CRA obligation with real enforcement behind it is weeks away, not sixteen months away. It covers firmware you shipped years ago. And as of mid-August 2026, the platform you have to file through did not have a published URL.

That combination is the problem with how most CRA guidance is written. Almost all of it treats December 11, 2027 as the deadline, which makes the work look like documentation you can schedule. The obligation that arrives first is not documentation. It is operational capability, measured against a 24-hour clock, applied to products you may no longer have a build environment for.

If you have read three CRA overviews and still cannot say which obligations bind you today, that is not a gap in your reading. It is a gap in how the topic gets covered.

This guide takes every requirement and does two things with it: gives you the Article it comes from, and tells you whether it binds you now or in 2027.

Who has to comply with the Cyber Resilience Act, and which products are in scope

The exclusion lists in most CRA guides are too clean. "SaaS is out of scope" and "medical devices are out of scope" are both repeated often enough to sound settled, and both are wrong at exactly the edges where connected device manufacturers sit.

Start with who carries the obligations. Manufacturers carry the substantive load: designing the product, declaring its conformity, and handling vulnerabilities across the support period. Importers and distributors carry verification duties, checking that what they place on the market has the right marking and documentation. If you ship into the EU from anywhere in the world, the CRA applies the moment the product reaches the market, and you must designate an authorised representative under Article 18.

Scope is defined by function, not by connectivity or deployment model. A product with digital elements covers hardware containing software or firmware, standalone software, and software and hardware components sold on their own. Software that never connects to anything is still in scope.

The SaaS boundary is where the flat lists break down. Standalone SaaS generally sits under NIS2 rather than the CRA. But a remote data processing solution that is necessary for the product to perform its functions is in scope as part of that product. The test is functional necessity, not where the code runs. If you ship a device with a companion cloud service, the question to answer first is whether the device still does its job when that service is unavailable.

Sectoral exclusions work the same way. Motor vehicles, medical devices, and certain aviation and marine equipment fall outside the CRA because other EU law already governs their cybersecurity, not because of the industry label attached to them. The carve-out is conditional on that other regime covering the same ground.

What does Cyber Resilience Act compliance actually require?

Annex I looks like one list of essential requirements. It is two, and they fail in completely different ways.

Part I covers properties the product must have. No known exploitable vulnerabilities at release. A secure by default configuration. A minimised attack surface. Protection for the confidentiality and integrity of data. A mechanism to deliver security updates securely. These are design outcomes. You can test for them at a point in time, and a product either has them on the day it ships or it does not. Our guide to security by design under the CRA covers that half in depth.

Part II covers processes the manufacturer must run. Identify and document the components in your products, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. Address vulnerabilities without delay. Operate a coordinated vulnerability disclosure policy with a stated point of contact. Notify the maintainer when you find a flaw in a third-party or open source component you have integrated. Distribute security updates across the support period.

Part II is not paperwork, and this is the distinction that decides your sequencing. It is the machinery that makes Article 14 reporting possible at all. Without a current component inventory, a triage workflow, and a disclosure channel, you cannot establish that an actively exploited vulnerability affects your product quickly enough to file inside 24 hours. The reporting obligation does not create that capability. It assumes it.

Most teams structure the disclosure and handling processes on ISO/IEC 29147 and ISO/IEC 30111, which give you a proven shape to build against and map cleanly onto the Part II language.

Part I is what you ship. Part II is what you run. Only one of the two has a deadline three weeks out.

Which CRA compliance obligations are live now, and which arrive in 2027

Two Cyber Resilience Act compliance deadlines have already passed. Most teams can name neither.

The June 2026 date gets listed in almost every CRA timeline without a consequence attached to it. Here is the consequence. Notified bodies could only be notified from that point, which means the pool of accredited third-party assessors has existed for roughly two months. If your product falls into Important Class II or the Critical tier, you need a notified body, capacity is scarce, and that conversation is already late.

Penalties are tiered by the seriousness of the breach under Article 64:

Fines are not the expensive part. Market surveillance authorities can order a product withdrawn or recalled across the EU, and for a manufacturer with an installed base that usually costs more than the penalty attached to it. They can also require information and order corrective action, which is where the evidence question in the section below becomes operational rather than theoretical.

Why the September 11, 2026 deadline reaches products you already shipped

The CRA compliance programme most teams have built covers the products they are building. The obligation arriving in September covers the products they already sold.

Article 69(3) applies the reporting obligations from September 11, 2026 to in-scope products with digital elements that were made available on the EU market before the CRA applies in full. Not products placed on the market after the deadline. Products already out there.

This is the single most consequential fact about the September date, and it is absent from every major CRA compliance guide currently ranking. The practical implication, as Hogan Lovells put it in their analysis of the reporting regime, is that reporting procedures have to cover legacy products and not only upcoming launches and current development projects.

Work out what that means for a device manufacturer with a ten-year installed base. Within 24 hours of becoming aware, you need to be able to say whether an actively exploited vulnerability affects a firmware image built four years ago, by a team that has since been reorganised, using a toolchain that may not exist anymore. You need to know which product variants carry the affected component and which member states they are available in.

That is an inventory problem before it is a reporting problem, and it is a harder inventory problem than the one your current pipeline solves. Source-based analysis covers the code you compile. It does not cover the vendor firmware, the RTOS image, or the third-party binary blob that shipped inside the product and for which no build ever existed on your infrastructure. For those components, identification has to happen against the shipped binary itself, because there is nothing else left to analyse.

If you do one thing before September 11, establish which of your shipped products are in scope and what is actually inside them.

What Article 14 requires you to report, and what it does not

The most common misreading of Article 14 is that it turns every CVE into a regulatory filing. It does not, and the distinction is the difference between a workable process and an impossible one.

Two things trigger the obligation.

An actively exploited vulnerability is one where there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. Both halves of that matter. Reliable evidence, not plausible concern. Exploitation without permission, which excludes your own penetration testing and authorised research. Routine bugs and ordinary patches fall outside it entirely.

A severe incident is one where the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive information is compromised, or where malicious code has been introduced into the product and can be executed.

Once either trigger fires, three windows open.

"From becoming aware" is the phrase to sit with. It is not from finishing triage, and not from confirming a fix. Work the 24 hours backward and you get a list of things that must already be true: you know the exploitation is real, you know the vulnerable component is in your product, you know which products and versions carry it, and you know which member states they are available in. Every one of those depends on inventory you either have on September 11 or do not. Narrowing that candidate set quickly is what exploitability-based prioritization is for.

There is also a judgement call the regulation handles more gracefully than most teams expect. Where it is genuinely unclear whether exploitation is active, the CRA does not penalise reasonable over-reporting, and honest interpretation is treated very differently from wilful concealment. Practitioners broadly read this as: when in doubt, file the early warning. Confirm the position with your own counsel.

Set this against your existing PSIRT severity threshold and you will find they diverge. A critical CVSS score with no evidence of exploitation is not reportable. A medium-severity flaw being actively exploited in the field is.

The ENISA Single Reporting Platform: what exists today and what does not

As of mid-August 2026, with the deadline weeks away, the platform manufacturers must file through did not have a published public URL.

The Single Reporting Platform is established under Article 16 as a single electronic entry point. You file once instead of notifying each national CSIRT separately. The submission routes simultaneously to your designated coordinating CSIRT and to ENISA, and the receiving CSIRT then disseminates it to other CSIRTs in territories you flag as affected.

Guidance has arrived recently and in pieces. ENISA published step-by-step instructions on July 31, 2026, then re-dated the guidance to August 3, 2026. Three guides now exist: registration and notification submission, both updated August 3, and platform interface functions, updated August 14. Registration runs through EU Login. Each manufacturer gets two seats, a primary representative and a secondary who joins by email invitation and holds a backup role, and that invitation link expires after seven days.

Three gaps in what has shipped so far have direct operational consequences:

• No reporting API is being provided at this stage. Filing is manual, through a web interface, inside a 24-hour window. You cannot wire your triage tooling to the platform, which means the handoff from detection to filing is a human process that has to be designed, staffed, and rehearsed before it is needed.
• The list of national CSIRTs designated as coordinators had not been published, even though the registration flow asks you to select yours from a drop-down.
• ENISA's guidance uses "Assigned Representative" (AR) for a platform account role. This is not the authorised representative under Article 18 of the CRA. Two different things, one abbreviation, and the wrong person gets assigned if nobody catches it.

Three pieces of readiness do not depend on the platform existing. Create the EU Login accounts now for your named primary filer and the backup, because doing it mid-incident is a delay you have chosen. Determine your main establishment under Article 14(7), which for EU-established manufacturers is the member state where cybersecurity decisions for your products are predominantly made rather than wherever the headquarters sits. And confirm the authorised representative route under Article 18 if you are outside the EU.

The account takes about ten minutes. It is the cheapest CRA compliance action available to you this week.

How the Commission's July 2026 guidance changed CRA compliance planning

The Commission's own guidance on applying the CRA is three weeks old, and none of the guides currently ranking for CRA compliance mention it.

Communication C(2026) 5252, published July 27, 2026 under Article 26, runs to 84 pages with 67 worked examples. It is explicitly non-binding: it creates no new obligation and moves no date, and it is a harmonised standard rather than a guidance note that confers presumption of conformity. Alongside it sits the Commission's CRA implementation FAQ, first published December 3, 2025 and updated July 2, 2026.

Where the fourteen pages added since the March draft landed tells you where the Commission saw the most confusion: products designed before the CRA entered into force, the consequences of a substantial modification (including modifications carried out by someone other than the original manufacturer), and how substantial modification interacts with the support period.

The clarification that matters most to this audience concerns software updates. A new software version is only considered placed on the market again if it constitutes a substantial modification. Minor updates and iterations do not require a new conformity assessment and do not change the original placing-on-the-market date.

Read the carve-out before you plan around the rule. That treatment applies only to standalone software provided digitally. It does not apply where software is delivered on a physical carrier, or where it is distributed together with hardware as a product. If you ship firmware inside a device, you do not get the standalone-software treatment for it.

Spare parts follow similar logic. Maintenance, repair, or replacement does not automatically constitute a substantial modification, and replacing a defective part with an equivalent or better component generally does not. The worked examples turn on whether you still produce the original part. Take a connected industrial controller placed on the market in 2026 whose communication chip fails in 2028. Replace it with the same part and you are inside the exemption. Replace it with a module built on a different chipset, or carrying updated firmware, and it becomes a product in its own right.

If your release process currently treats firmware updates as compliance-neutral, the guidance says otherwise for anything that ships with hardware.

How your product class sets your conformity route

Most readers can name the four tiers. Far fewer can say which one their own product sits in, and the test is narrower than it looks.

A product is taken to have a single core functionality, identified in its technical documentation. Ancillary functions do not change its class, and integrating an important or critical component does not pull the whole product up a tier. The Commission's own illustration is a smartphone that embeds an operating system: the smartphone is not itself an operating system for classification purposes.

The tiers run Default, Important Class I, Important Class II, and Critical. Default covers the large majority of products. Important Class I and II are set out in Annex III and cover products whose core function is critical to the cybersecurity of other products, networks, or services, with Class II carrying higher risk. Critical products are listed in Annex IV. Every tier meets the same essential requirements; the tier only changes how you prove it.

Article 32 and Annex VIII set the routes:

• Default: Module A internal control, self-assessed. No notified body, but the full technical file and EU Declaration of Conformity are still required.
• Important: self-assessment is available where you apply the relevant harmonised standards in full. Otherwise a notified body must be involved, under Article 32(2) and (3).
• Critical: conformity under a European cybersecurity certification scheme at a defined assurance level, under Article 32(4).

There is a problem with the middle route right now. No CRA harmonised standard has been cited in the Official Journal, which means the Article 27 presumption of conformity is not available for any product category. Standardisation request M/606 was accepted by CEN, CENELEC, and ETSI on April 3, 2025, calling for 41 standards. On August 13, 2026, ETSI put 17 final draft CRA product standards under Public Enquiry, with comments closing from mid-September. None is harmonised yet.

If you are Default tier, plan on self-assessment and spend your effort on evidence. If you are Important Class II or Critical, book notified body time now. Our breakdown of CRA conformity assessments covers the routes in full.

The evidence you have to be able to produce on demand

A market surveillance authority does not ask whether you run a good security program. It asks for the file.

The SBOM obligation sits in Annex I Part II(1): identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format, covering at least the top-level dependencies of the product.

"At least the top-level dependencies" is a floor, not a specification. You also do not have to publish it. The SBOM must be current and available to authorities on request, and Annex II Part I point 9 only requires you to tell users where it can be accessed if you choose to share it.

The floor can move without the regulation reopening. Article 13(24) empowers the Commission to specify the format and elements of the SBOM by implementing act. None has been issued yet, but building strictly to today's minimum carries forward risk.

The technical file is set out in Annex VII: product description, design and development information, the risk assessment, vulnerability handling, the support period, standards applied, and test reports. Annex II sets the information you ship to users, Annex V the Declaration of Conformity. We cover the contents in our guide to CRA SBOM and technical documentation.

Retention is where a lot of published guidance has been imprecise. Article 13(13) requires the technical documentation and the EU Declaration of Conformity to remain available to authorities for ten years after the product is placed on the market, or for the support period, whichever is longer. Declare a twelve-year support period and ten years is not your number.

The support period must reflect how long the product is expected to be in use, and is generally expected to be at least five years unless the expected use period is genuinely shorter.

Every artifact on that list assumes one thing: that you can enumerate what is inside the product. For third-party firmware, vendor binaries, and RTOS images you never compiled, there is no build to instrument and no dependency manifest to read. Component identification has to happen against the binary that actually shipped.

The test is not whether you are secure. It is whether you can prove what shipped, when, and what was inside it.

What to do with the time before September 11

The highest-value action available to you this week takes about ten minutes and does not depend on the platform existing.

In triage order:

1. Create the EU Login accounts at ecas.ec.europa.eu for your named primary filer and the backup. Ten minutes now against a blocker in the middle of an incident.
2. Determine your main establishment under Article 14(7) and therefore your designated CSIRT. Outside the EU, confirm the authorised representative route under Article 18.
3. Name who has authority to file and write the escalation runbook. Publish it internally. A 24-hour clock does not survive an ambiguous escalation path.
4. Scope the obligation to shipped products, not just products in development. Article 69(3) puts your installed base inside the September date.
5. Draft the report templates now for the 24-hour, 72-hour, and final filings, so that drafting is not happening while the clock runs.
6. Run a tabletop end to end. With no reporting API, the first manual submission through the platform should not be a live one.

None of that is a compliance programme. It is the subset that survives contact with a three-week runway, ordered so that the cheapest and most reversible actions come first. For the full readiness sequence running to December 2027, our step-by-step CRA preparation guide lays out the whole thing.

Want to see what continuous, audit-ready CRA evidence looks like against products you have already shipped? Request a CRA walkthrough.

FAQ

Does the September 2026 reporting obligation apply to products we already shipped?

Yes. Article 69(3) applies the Article 14 reporting obligations from September 11, 2026 to in-scope products made available on the EU market before the CRA applies in full. Your reporting procedures have to cover the installed base, not only new launches and products in active development.

Do we have to report every CVE under the CRA?

No. Article 14 covers actively exploited vulnerabilities, meaning reliable evidence exists that a malicious actor exploited the flaw in a system without the owner's permission, and severe incidents. Routine bugs and ordinary patch cycles fall outside it. See the Article 14 section above for the definitions and the three filing windows.

Do we need an SBOM by September 2026?

Not formally. The CRA SBOM obligation in Annex I Part II(1) binds from December 11, 2027. In practice you cannot establish that an actively exploited vulnerability affects your product inside 24 hours without a current component inventory, so the SBOM is a prerequisite for the September date rather than a 2027 deliverable.

Does a firmware update reset our conformity obligations?

Only if it constitutes a substantial modification. Minor updates do not require a new conformity assessment and do not change the original placing-on-the-market date. That treatment applies to standalone software provided digitally. Software distributed together with hardware, or on a physical carrier, does not get it.

Do we have to publish our SBOM?

No. It must be current and available to market surveillance authorities on request. Annex II Part I point 9 only requires you to tell users where the SBOM can be accessed if you choose to make it available to them, which remains your decision.

How long do we have to keep CRA technical documentation?

Ten years after the product is placed on the market, or for the length of the support period, whichever is longer, under Article 13(13). The same retention applies to the EU Declaration of Conformity.