Annex I · Annex III · Annex IV · exclusions
The scope sentence is broad on purpose: products with digital elements made available on the Union market, whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That takes in hardware with firmware, standalone software sold commercially, and remote data processing solutions integral to the product. Then the annexes narrow it into classes, the exclusions remove whole sectors, and the open-source carve-out changes the answer for a large part of the industry. This page works through all of it.
DefaultImportant IImportant IICriticalExcluded
Most products are default, and default means self-assessment under module A: you apply the essential requirements, you draw up the documentation, you sign the declaration and you affix the CE mark. No notified body, no external certificate, and no shortcut either.
| Product | In scope? | Why |
|---|---|---|
| Smart home device with an app | Yes | Hardware with digital elements and a data connection |
| Industrial sensor with firmware | Yes | Same test; business use does not exclude it |
| Desktop or mobile application sold commercially | Yes | Software is a product with digital elements |
| Cloud service behind the product | Only if it is a remote data processing solution integral to the product | Otherwise it is NIS2 territory, not CRA |
| Medical device | No | Covered by the MDR and IVDR |
| Motor vehicle systems | No | Covered by automotive type-approval rules |
| Civil aviation and marine equipment | No | Covered by their own regimes |
| Free and open-source software outside commercial activity | Largely no | With a lighter regime for open-source stewards |
This produced more anxiety than any other part of the regulation and the final text is narrower than the early drafts. Three positions are worth distinguishing.
Someone publishing a library for free, outside a commercial activity, is not a manufacturer under the regulation and carries no CE obligations.
A legal person systematically providing sustained support for open-source software intended for commercial activities has a lighter set of duties, focused on a security policy and cooperation.
If you integrate a library into a product you sell, you are the manufacturer of that product. The component's licence does not transfer your responsibility, and your SBOM is where this becomes visible.
Dependency hygiene stops being a matter of taste. Vulnerability handling under Annex I part II applies to what you ship, including what you did not write.
Delivered without known exploitable vulnerabilities, with a secure default configuration and the ability to reset to it.
Minimised, with exposed interfaces limited to what the product needs.
Confidentiality and integrity of stored, transmitted and processed data, with encryption where appropriate.
Authentication and authorisation appropriate to the product, with no universal default credentials.
Security updates available for the support period, delivered securely, automatically where appropriate with the ability to opt out.
An SBOM in a commonly used machine-readable format, a coordinated disclosure policy, and a contact address for reports.
| Step | Output |
|---|---|
| List every product you place on the Union market | A row per product, with firmware and software listed separately where they are sold separately |
| Check the exclusions first | Medical, automotive, aviation, marine drop out immediately |
| Check Annex III and IV | Important class I, class II or critical, if the product appears there |
| Everything else is default | Module A self-assessment, which is most catalogues |
| Note the conformity route per row | Self-assessment, harmonised standard, or notified body |
| Note the support period per row | At least five years unless the lifetime is shorter, and it has to be published |
Doing this early matters because the notified body capacity for important class II and critical products is finite, and the queue at the end of 2027 will not be short.
If it connects and you sell it in Europe, assume it is in scope until an exclusion says otherwise. Most products are default class and self-assessed; important and critical products need a notified body and planning. Open source outside a commercial activity is largely outside, but what you ship inside your own product is yours regardless of who wrote it. And if you have no establishment in the Union, the optional Article 18 mandate is what fixes your reporting route.
Read as engineering rather than law, the CRA rewrites three assumptions that most hardware companies have been running on for a decade.
| Old assumption | What the regulation requires instead |
|---|---|
| Ship it and move on | Security updates for at least five years, resourced as a product line |
| Default passwords are fine if documented | No universal default credentials, and secure configuration out of the box |
| Dependencies are somebody else's problem | An SBOM and vulnerability handling for what you ship, whoever wrote it |
| Security disclosure is a mailbox nobody reads | A coordinated disclosure policy and a published contact point |
| Updates are optional for users | Automatic security updates where appropriate, with the ability to opt out |
| Documentation is written at launch | Technical documentation kept for ten years or the support period, whichever is longer |
None of that is exotic in 2026, and most serious manufacturers already do half of it. What changes is that it becomes a market access condition with a CE mark attached rather than a maturity goal, and that it applies to the cheap end of the catalogue exactly as much as to the flagship.
Self-assessment, so the constraint is internal capacity. Start with the essential requirements and the SBOM; the paperwork follows.
Applying harmonised standards in full avoids a notified body. Watch the standards as they are published; that decision saves months.
Notified body always. Capacity is finite and the queue will lengthen through 2027, so engage early.
Notified body and possibly a European certification scheme. The longest lead time of all, for a short list of products.
The reporting route and the runbook, because that date arrives more than a year before full application.
Essential requirements, documentation, declaration of conformity, CE marking.
If it connects and you place it on the Union market, assume the Cyber Resilience Act applies until an exclusion says otherwise. Most catalogues are default class and self-assessed; important and critical products need a notified body and a plan that starts now rather than in 2027. Security updates for at least five years, an SBOM, no default credentials and a disclosure policy are the requirements that change engineering rather than paperwork. Open source outside a commercial activity is largely outside, but anything you ship inside your own product is yours regardless of who wrote it. And if no entity of yours is established in the Union, the optional Article 18 mandate fixes the one thing you cannot research during an incident.
Check Annexes III and IV first, before anything else. A default-class catalogue is a self-assessment exercise you can schedule; a single important class II product changes the plan entirely, because a notified body has to be engaged, capacity is finite and the queue lengthens as December 2027 approaches. Companies that answer this question in 2026 have options; companies that answer it in late 2027 have whatever slot remains.
At least five years unless the expected lifetime is shorter, and the period has to be communicated to users. That single sentence reaches into pricing, roadmap and end-of-life planning, and it applies to the cheapest item in the catalogue as much as to the flagship. Deciding it deliberately per product line, and writing it down, is the part most teams postpone and then regret.
A connected consumer device sits under both, and teams regularly assume one covers the other. It does not, and the two obligations even attach to different parts of the same box.
| Point | Cyber Resilience Act | GPSR |
|---|---|---|
| Protects against | Cybersecurity risk | Physical safety risk |
| Representative | Optional, Article 18 | Mandatory, Article 16 |
| Where it appears | Technical documentation and CE marking | Printed on the product or its packaging |
| Enforced by | Market surveillance, with CSIRTs for reporting | Market surveillance and the marketplaces |
| First sign of a problem | An authority request or an exploited vulnerability | Your listings disappearing from the European sites |
A software or hardware product and its remote data processing solutions, including components placed on the market separately, whose intended or reasonably foreseeable use includes a data connection.
Yes, where it is placed on the market in the course of a commercial activity. Software is explicitly a product with digital elements.
Only where they are remote data processing solutions integral to the product. Cloud services as such fall under NIS2 rather than the CRA.
Medical devices, in vitro diagnostics, motor vehicles, civil aviation and marine equipment, each governed by their own legislation.
Default, important class I, important class II and critical. Annexes III and IV list the important and critical categories.
Self-assessment under module A: apply the essential requirements, draw up the technical documentation, sign the declaration and affix the CE mark.
Always for important class II and critical products; for important class I where harmonised standards are not applied in full.
Yes, from full application on 11 December 2027, based on the applicable conformity assessment route.
At least five years unless the expected product lifetime is shorter, with security updates available throughout and the period communicated to users.
Yes, as part of the vulnerability handling requirements, in a commonly used machine-readable format covering at least the top-level dependencies.
Software developed or supplied outside a commercial activity is largely outside. Open-source stewards have a lighter regime. What you ship in your own product remains yours.
Optional under Article 18, and it determines the CSIRT that receives your reports if you have no establishment in the Union.
Up to €15 million or 2.5% of worldwide annual turnover for the most serious breaches, with lower ceilings for other infringements.
Yes, where they are placed on the market separately. The integrator is the manufacturer of the finished product.
Substantial modification makes you the manufacturer for the modified product, as in the rest of Union product law.
Yes, the technical documentation and the declaration of conformity for ten years or the support period, whichever is longer.
The reporting obligations apply: actively exploited vulnerabilities and severe incidents, through the ENISA platform.
€490 a year, and it covers holding the documentation and cooperating with market surveillance, not the assessment itself.
Related: the Article 18 mandate · the reporting clock
Europe Services, SE in Prague as your Article 18 representative, holding the declaration of conformity and technical documentation for the full retention period.
Request this service