Your product under the Cyber Resilience Act: a complete guide for manufacturers

By Kike Gandia · Co-Founder & CEO, OSCP

Regulation (EU) 2024/2847, the Cyber Resilience Act, does not treat all products alike: it sorts them into four tiers, and that sorting decides whether you can sign off conformity yourself or need an external body. As of today, no CRA harmonized standard has been cited in the Official Journal of the EU and no notified body has been designated under the regulation — two zeros which, combined, leave much of the catalog of important products with no self-assessment route open. There are 15 months left until full application on December 11, 2027, but part of the regulation has already been mandatory since September 11, 2026. This guide explains how your bucket is decided, what each date requires and which paths remain open — not all of them do.

Already mandatory: Article 14, since September 11

While the industry looks ahead to December 2027, Article 14 became applicable on September 11, 2026 and is already binding: twenty-four hours for the early warning of an actively exploited vulnerability or a severe incident, seventy-two for the notification, and fourteen days for the final report once a patch is available. What almost nobody has taken on board is the scope: under Article 69(3), that obligation covers the entire catalog, including products that have been on the market for years. There is no exception for age or for discontinued products.

Notification goes through ENISA's single reporting platform, live since that same day, which today works only through a browser, with no API. Registration itself is quick — ENISA advises completing it and requesting validation only when a notification is actually due, and the CSIRT's validation runs in parallel with the report — but what cannot be improvised on the day of the incident is everything behind it: EU Login accounts with two-factor authentication for the people who will file, the coordinating CSIRT identified, and the product data at hand.

Does the CRA apply to you? The initial filter

Before classifying, it pays to rule things out. The CRA covers products with digital elements: software or hardware, plus their remote data processing solutions, whose intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network.

The definition is broader than it looks. Software sold on its own is in scope, with no accompanying hardware required. A component marketed separately is not an accessory of the end product: it is a product in its own right, with its own marking and its own declaration. And an "indirect" connection is enough, so a module that only talks to the board hosting it is in scope if that board connects.

Out of scope: software as a service in the strict sense (what runs on the provider's server and is consumed through a browser is not "placed on the market"), the manufacturer's own internal infrastructure, and free and open-source software distributed outside any commercial activity, which is never made available on the market. Also excluded, expressly, are the sectors that already have their own cybersecurity regulation:

The four buckets: how the CRA decides your category

The CRA divides the universe into four tiers: default products, important class I products, important class II products and critical products. The first holds the vast majority (around 90% of the market); the other three are set out in closed lists, Annexes III and IV, which only the European Commission can amend by delegated act.

The rule that decides the bucket is the product's core functionality (Art. 7(1)), and this is the first thing to internalize because it runs against intuition. Integrating a listed component does not drag the host product onto the list: a news app that embeds a browser engine is not a browser, and a phone that includes an operating system and a password manager is classified by what it is, not by what it contains. The right question is not "does my product contain something on the list?" but "is the thing my product exists to do on the list?".

Since December 21, 2025, that question can no longer be answered by eye. Implementing Regulation (EU) 2025/2392 sets out the technical description of each of the twenty-six categories in Annexes III and IV, and classifying today means checking your product against that legal text, not against whatever marketing label you have given it. It is the document to keep open during the exercise, and the one that explains why many of the articles published in 2025 fell short.

The order of the five questions that decide the bucket — the first one that applies closes the classification:

• Does the product have a data connection, direct or indirect, to a network or device? If not, it falls outside the CRA's scope.
• Is it covered by a sectoral exclusion (medical, automotive, aviation, marine, defense) or is it an identical spare part? If so, it is out of scope and subject to its sectoral legislation.
• Is its core functionality in Annex IV, critical products? If so: European certification where a delegated act under Art. 8(1) requires it; failing that, a third party is mandatory.
• Is it in Annex III, class II (hypervisors, firewalls, IDS/IPS, tamper-resistant chips)? If so: module B+C, module H or "substantial" certification — never self-assessment.
• Is it in any of the 19 categories of Annex III, class I? If so: self-assessment only if harmonized standards cover all applicable requirements — today there are none, so a third party is mandatory here too. If it is on no list: default product, self-assessment with module A, no third party.

The essential requirements of Annex I are the same in all four buckets. What changes is who is authorized to certify that they are met.

The 19 class I categories, and the 7 class II and critical ones

They are worth reading in full even if you think they do not apply to you, because some categories catch out manufacturers who never saw themselves as security companies: any wearable with health-monitoring functionality that is not a medical device, any connected toy that talks or tracks location, any microcontroller with secure boot.

Verbatim technical descriptions of the 26 categories: Implementing Regulation (EU) 2025/2392, Annex I (important) and Annex II (critical), in force since December 21, 2025.

Where your bucket leaves you: outcomes table

A shortcut to the practical conclusion of the five questions above — what applies to you today depending on where you land:

This table is no substitute for a conformity analysis: always check your product's core functionality against the verbatim technical description in Implementing Regulation (EU) 2025/2392 before taking the result as settled.

What changes by bucket: conformity assessment routes

A widespread misunderstanding needs clearing up: the bucket does not change the requirements. The thirteen product requirements in Annex I Part I and the eight vulnerability handling requirements in Part II apply equally to a thermostat and to a firewall. What changes is who is authorized to sign off that they are met, and that translates into money, months and dependence on third parties.

There is a nuance in Article 32(2) that is worth money and usually overlooked: the rule works requirement by requirement, not product by product. If you apply harmonized standards covering eleven of the thirteen requirements in Annex I Part I, only the remaining two go to the notified body. Partial application does not send the whole product to audit, provided the risk assessment documents precisely what is covered and what is not. That document, the one required by Article 13(2), stops being paperwork and becomes the hinge of the whole strategy: it justifies which requirements apply and how they have been adapted, it is the only thing a market surveillance authority will be able to examine if you self-assessed, and it is the first thing the auditor will open if you did not.

The 2026 bottleneck nobody is talking about

Two facts, each verifiable on its own, which together lead to a dead end.

First: as of today, not a single CRA harmonized standard has been cited in the Official Journal. The horizontal standards — the EN 40000 series, developed by CEN-CENELEC JTC 13 WG 9 — have three parts whose public enquiry has closed and a fourth still being drafted. The ETSI vertical standards, the EN 304 6xx series, one per Annex III category, opened for public enquiry on August 13, and their comment periods close in stages between September and November. Standardization request M/606 set delivery for August and October 2026; in July the Commission circulated a draft pushing those deadlines back by two months, and that draft has not been published either. None of these drafts confers a presumption of conformity today: applying them is good engineering and early preparation, not legal cover.

Second: there is no record of any notified body designated under Regulation 2024/2847. Chapter IV, which empowers Member States to designate them, has applied since June 11, 2026, and the regulation itself asks them to aim for a sufficient number before December 11 of this year.

Put the two together and the result is uncomfortable: with no cited harmonized standards, Article 32(2) pushes all of class I toward the branch that requires a notified body; class II was already there by definition; so are critical products, pending the delegated act under Article 8(1). That makes twenty-six product categories whose conformity assessment currently depends on an entity that does not exist yet, with fifteen months to go and a designation process that takes months per body — and on top of that comes the audit capacity needed to serve thousands of manufacturers.

The two problems are coupled and will be solved together: if the horizontal standards are cited in time, class I regains self-assessment and the pressure on notified bodies collapses. If they are not, the system seizes up for almost all of Annex III. The practical consequence for a class I manufacturer is that its plan has to work in both scenarios: prepare the technical file as if it were going to an external audit, even if you expect to be able to sign it off yourself.

That leaves the safety valve of European certification. The EUCC scheme has existed since Implementing Regulation (EU) 2024/482, and in February 2025 ENISA published an analysis of how it could serve the CRA. But Article 32 makes that route conditional on the scheme being "applicable pursuant to Article 27(9)", and the delegated act that would declare this has not been adopted. On top of that comes a substantive limitation: EUCC evaluates the product, using Common Criteria methodology, whereas much of Annex I Part II consists of organizational process requirements — coordinated disclosure, SBOM, secure distribution of updates — which a product scheme does not cover on its own. It is the natural candidate to clear the bottleneck; today it is not a way out you can build a strategy on.

"I already have CE marking. Isn't that enough?"

No. And the reason is worth understanding properly, because it determines how much work you can reuse and how much is genuinely new.

CE marking is not a generic quality seal: it is granted per legislative act. Each piece of harmonization legislation has its own essential requirements, its own assessment procedure and its own declaration of conformity. A product CE-marked under the Low Voltage Directive, the EMC Directive or the Radio Equipment Directive demonstrates exactly what that legislation covers, and nothing more. There is no mutual recognition, no equivalence clause, and no way for an old technical file to cover a requirement that was never assessed in it.

The only bridge the CRA builds backward is Article 69(1), and it is narrower than it looks: EU-type examination certificates and approval decisions concerning cybersecurity requirements issued under other Union harmonization legislation remain valid until June 11, 2028. Remaining valid is not the same as conferring a presumption of conformity with the CRA: it is a certificate validity clause, not a conformity bridge, and it runs out six months after full application.

Do you need to retest? It depends on the test. What carries over is the evidence; what does not carry over is the conformity. A test report remains a verifiable technical fact and goes into the CRA technical file as evidence (Annex VII expressly provides for this), but the certificate that accompanied it does not transfer its legal effect.

You will need to retest in two cases: when you rely on a CRA harmonized standard — once there are any — whose test cases do not overlap with the ones you already passed, and when the product undergoes a substantial modification, which reopens the assessment of the affected part, or of the whole product if the change compromises its overall cybersecurity. A practical note: when a product is subject to several Union acts requiring a declaration of conformity, Article 28 requires a single declaration identifying all of them — not two documents living side by side, but one that grows.

What each date requires

The CRA does not take effect all at once. It rolls out in three stages aimed at different addressees, and confusing them is the usual source of both premature alarm and false calm:

The two Article 14 clocks are parallel sequences with different starting points, and confusing them is the easiest way to miss a deadline while believing you are compliant. For an actively exploited vulnerability: 24h for the early warning and 72h for the notification from the moment you become aware; the final report is due 14 days after a corrective measure is available, not after awareness. For a severe incident: 24h and 72h from awareness; the final report is due one month after the 72-hour notification. The "severe incident" threshold is framed in terms of capability, not actual harm: it is enough that the incident could affect availability, authenticity, integrity or confidentiality, or could lead to the execution of malicious code. The notification goes simultaneously to the coordinating CSIRT and to ENISA.

The December 11, 2027 cutoff

Of the entire regulation, Article 69(2) is probably the provision with the most money riding on it, and it almost never appears in explainer summaries.

It states that products placed on the market before December 11, 2027 are only subject to the CRA's requirements if, from that date, they undergo a substantial modification. The criterion is not the design date, the manufacturing date or the catalog date: it is the date each individual unit is first made available on the Union market. A unit placed on the market on December 10, 2027 is exempt from the substantive requirements indefinitely; the next unit, placed on the 11th, is fully in scope. It is a binary cut, and it applies SKU by SKU and unit by unit.

One very concrete consequence follows: documenting precisely when each SKU was placed on the market has direct economic value. It is the proof of which side of the line your inventory falls on, and anyone who cannot demonstrate it will be held to the more onerous regime.

What is a substantial modification? A change that alters the cybersecurity risk level in a way the manufacturer had not already foreseen in its risk assessment. The Commission's July 2026 guidance clarifies that a security patch does not count on its own, because its purpose is to reduce risk, provided it does not change the intended purpose or introduce new risks. A functional update that does alter the risk profile, on the other hand, knocks out the exemption and pulls the product into the full regime. Besides being the hinge of conformity, the risk assessment is the document that determines whether a future change costs you an engineering cycle or a full conformity assessment.

That said, this should not turn into a race to flood the channel before the date. The exemption covers the substantive requirements, not Article 14, which expressly reaches everything placed on the market before that date (Art. 69(3)). And a legacy catalog that nobody will be able to update remains a technical and reputational liability even if it is legally unimpeachable. The cutoff is a planning lever, not a compliance strategy.

Coming from the RED: what EN 18031 gives you and what it does not

For a manufacturer of connected radio equipment, last year was the year of EN 18031 and Delegated Regulation 2022/30. The natural question is whether that effort counts. It does, but less than you might expect, and on a different level than you might expect.

First, the fact that frames everything else: Delegated Regulation (EU) 2026/339 of February 16, 2026 repeals 2022/30 with effect from December 11, 2027, exactly the CRA's full application date. The recitals are clear: the CRA's essential requirements include all the elements of points (d), (e) and (f) of Article 3(3) of the Radio Equipment Directive, and the aim is to avoid the same equipment being subject to two cybersecurity regimes at once. Until December 10, 2027 both coexist and market surveillance under the RED remains active; from the following day, only the CRA remains.

Second, the uncomfortable part: EN 18031 is cited in the Official Journal in support of the RED, not the CRA. The presumption of conformity is specific to the instrument for which a standard is cited, so EN 18031 presumes conformity with Article 3(3)(d), (e) and (f) of the RED and nothing else. When the CRA harmonized standards arrive, that presumption will not transfer by itself.

And third, what really matters for planning: the work the CRA adds for a manufacturer that already complies with the RED is fundamentally about process, not product. The technical requirements of Annex I Part I overlap substantially with what EN 18031 already requires you to demonstrate on access control, updates, confidentiality and integrity. What has no equivalent is everything else: vulnerability handling as a living process, the SBOM, coordinated disclosure, the reporting channel, the declared support period, patch availability for a decade and Article 14 notification. None of those pieces existed in the RED world, and none of them can be solved in a lab.

The operational recommendation follows naturally: do not build two technical files. Structure the current one so that each piece of EN 18031 evidence is mapped to the Annex I requirement it satisfies, so that when the CRA standard is cited, migration is a traceability exercise rather than a round of repeat testing.

Spain: who you notify and who supervises you

A European regulation is directly applicable, but enforcement is national. In Spain the picture is only half built, and it is worth knowing which part already works and which does not.

What already works. Spain has designated INCIBE as the coordinating CSIRT for CRA purposes, and it appears as such on the list published by ENISA. It is not CCN-CERT or ESPDEF-CERT, even if intuition suggests otherwise. All twenty-seven Member States have completed their designations. Notification, however, does not go through the usual national channels: it goes through ENISA's single reporting platform, and as of today INCIBE-CERT has not published a CRA-specific national procedure.

What does not work yet. The draft royal decree designating the market surveillance authority and the notifying authority — the State Secretariat for Telecommunications for the former, the National Cryptologic Center (Centro Criptológico Nacional) for the latter, with ENAC as the accreditation body and INCIBE as the supporting technical laboratory — has been working its way through the approval process since late 2025; the CNMC (Spain's National Markets and Competition Commission) issued its report in May 2026 and there is no record of publication in the BOE (Spain's Official State Gazette). Nor is there a national penalty regime, and there could not be one by royal decree: penalties must be established by a law with statutory rank, and no specific bill is known.

The fact that there is not yet a national channel for imposing fines exempts nobody from anything. The Article 14 obligation has been directly applicable and enforceable since September 11; what is missing is the administrative plumbing, and plumbing eventually gets installed. Counting on that gap as a strategy is betting that the delay will outlast the paper trail.

There is also a latent overlap in Spain: NIS2 has still not been transposed. Once the Cybersecurity Coordination and Governance Act (Ley de Coordinación y Gobernanza de la Ciberseguridad) is passed, a company that is both a manufacturer of a product with digital elements and an essential or important entity will have to notify twice, through two channels, for the same event: the CRA looks at the product and goes to the ENISA platform; NIS2 looks at the entity and goes to the national channel. There is no anti-duplication clause.

Penalties: what getting it wrong costs

Article 64 sets three tiers, and in each one the higher of the two amounts applies:

The point worth underlining: Article 14 sits in the top tier, on the same level as a failure to meet the essential cybersecurity requirements. It is not a second-order formality; the legislator put it there on purpose. There are two mitigating provisions: microenterprises and small enterprises are exempt from fines for missing the notification deadlines, and open-source software stewards are exempt from administrative fines altogether.

And it does not end with money. The full chain runs from notification to the CSIRT, referral to the market surveillance authority, evaluation of the product and a demand for corrective action to, if that demand is not met, prohibition, withdrawal or recall with effect across all twenty-seven Member States. A notification can end with the withdrawal of the very product being notified, which is why the internal decision procedure cannot be improvised at three in the morning.

What to do, and in what order

Ordered by the date each obligation becomes enforceable, not by difficulty. The first actions cannot wait because Article 14 is already in force; the rest sets the pace until December 2027.

This month

• Get access to the ENISA platform ready before you need it. Access is through an EU Login account with two-factor authentication; you designate a primary representative and up to twenty secondary ones by invitation, and those invitations expire after seven days. ENISA advises registering and requesting validation only when a notification is due: with the EU Login account in place it takes minutes, and the CSIRT validates in parallel. What has to be ready beforehand is everything else: two-factor accounts for the people who will file and the coordinating CSIRT identified. With no API and no SOC integration, notification is manual, and the platform's 72-hour counter currently shows the due time 48 hours after the early warning: keep your own clock running from the moment of awareness.
• Define what "becoming aware" means in your organization and who starts the clock. It is the event that triggers the deadline, and the one you will have to prove.
• Set up two timers, not one: the final vulnerability report runs from the moment the patch exists; the final incident report, from the 72-hour notification.
• Prepare the user communication template required by Article 14(8). It is a standalone, cumulative obligation: meeting your duty to the regulator does not exempt you from informing the people who use the product.

This quarter

• Classify every SKU in the catalog against Implementing Regulation 2025/2392, not against intuition, and keep a written record of the core-functionality reasoning.
• Build a register of market placement dates by SKU. It is what decides which side of the 2027 cutoff each unit falls on.
• Write the Article 13(2) risk assessment for your main product families. It underpins the applicability of each requirement, the partial application of standards and the future classification of modifications as substantial or not.

Depending on your bucket

• Default: the path is clear and you can move forward without depending on anyone. The priority is the vulnerability handling process, the SBOM and the support period, which is where the real work lies.
• Class I: prepare the technical file as if it were going to an external audit, even if you are betting on signing it off yourself. Track the citation of the EN 40000 horizontal standards and of the ETSI EN 304 vertical standard for your category, and take part in the public enquiry if it is still open.
• Class II and critical: a third party is unavoidable and none is available yet. Get into conversations with notified body candidates before the rest of the market does, and assess whether bringing forward the market placement of the current generation ahead of the 2027 cutoff buys you the margin you are missing.

Where QuantumSec fits

We support manufacturers on the pieces that cannot be solved in a lab: a defensible classification, the technical file and the process behind it.

• Classification and applicability analysis of each SKU against Annexes III and IV and Implementing Regulation 2025/2392, with the reasoning documented.
• Gap analysis against Annexes I, II and VII, explicitly reusing EN 18031 evidence or previous audits.
• Cybersecurity risk assessment under Article 13, written to support the partial application of standards and future decisions on substantial modification.
• Article 14 notification procedure: platform registration, defining the awareness threshold, clocks, templates and a rehearsal of the process.
• IoT and hardware penetration testing that produces evidence you can use in the technical file, not just a report.

FAQ

Who takes on the manufacturer's obligations if I don't make the product?

An importer or distributor that markets a product under its own brand, or that substantially modifies a product already on the market, takes on the manufacturer's obligations (Art. 21). So does any other third party that makes a substantial modification and places the product on the market (Art. 22), although only for the affected part unless the modification compromises the cybersecurity of the product as a whole. The authorized representative (Art. 18) acts under a written mandate, with obligations that cannot be delegated and a duty to keep the technical file for ten years.

What regime applies to open-source software?

The open-source software steward (Art. 24) is the legal person that systematically sustains the development of an open-source product intended for commercial activities. Its regime is very light — a documented cybersecurity policy, cooperation with market surveillance and limited notification duties — with no CE marking or conformity assessment, and it is exempt from administrative fines. Its obligations do not arise until December 11, 2027. In addition, open-source software with publicly available technical documentation regains module A self-assessment even if it is an important product (Art. 32(5)).

Which conformity assessment modules does the CRA provide for?

Four, in Annex VIII. Module A (internal control): the manufacturer draws up the technical file, ensures that design, development, production and vulnerability handling comply with Annex I, affixes the marking and signs the declaration; documentation is kept for ten years or for the support period, whichever is longer. Module B (EU-type examination): a notified body examines the technical file, verifies the specimens and issues the certificate. Module C (conformity to type): production in conformity with the type approved under module B, with internal control. Module H (full quality assurance): a quality system approved and monitored by a notified body, with on-site audits; the CE marking carries the body's number. A CRA-specific feature: modules B and H explicitly audit the vulnerability handling process, not just the product — a flawless technical file with no process behind it does not pass.

How exactly do the two Article 14 clocks work?

They are two parallel sequences with different starting points. For an actively exploited vulnerability: 24h for the early warning and 72h for the notification from the moment you become aware, and a final report 14 days after a corrective or mitigating measure is available (not from awareness). For a severe incident: 24h and 72h from awareness, and a final report one month after the 72-hour notification. The "severe incident" threshold is defined in terms of capability, not actual harm: it is enough that the incident could affect availability, authenticity, integrity or confidentiality, or could lead to the execution of malicious code. The notification goes simultaneously to the coordinating CSIRT (INCIBE in Spain) and to ENISA.

Related service

Cyber Resilience Act (CRA) consulting

Related content

• CRA scoping form (interactive tool)
• What is the Cyber Resilience Act
• Cyber Resilience Act requirements
• Cyber Resilience Act timeline
• Cyber Resilience Act fines
• CRA vs NIS2: the differences
• CRA reporting is now mandatory: what to do this quarter

Sources

• Regulation (EU) 2024/2847 — Cyber Resilience Act
• Implementing Regulation (EU) 2025/2392 — technical description of important and critical products
• Delegated Regulation (EU) 2026/339 — repeal of Delegated Regulation (EU) 2022/30
• European Commission — Cyber Resilience Act
• European Commission — CRA reporting obligations
• Commission implementation guidance C(2026) 5252, July 27, 2026
• ENISA — launch of the CRA single reporting platform
• ENISA — Single Reporting Platform (SRP) FAQ
• CEN-CENELEC — CRA horizontal standards and standardization request M/606

Assess my CRA readiness