EU Cyber Resilience Act scoper

How the classification works

Scope first

The CRA covers products with digital elements — hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That phrase is doing a lot of work. "Indirect" pulls in devices that never touch a network themselves but exchange data with something that does, and "reasonably foreseeable" means a debug port you did not intend anyone to use still counts.

Out of scope: products already regulated for cybersecurity under sector law — medical devices, type-approved motor vehicles, civil aviation, marine equipment — and products developed exclusively for national security, defense or classified information. Free and open-source software supplied outside a commercial activity is also excluded, though that exclusion is narrower than most maintainers assume once support contracts or paid hosting enter the picture.

Then the class, because it decides who signs off

Class	Examples	Conformity assessment
Default	Most connected products	Self-assessment — internal control
Important, Class I Annex III	Routers, operating systems, MCUs with security functions, password managers, smart home devices	Self-assessment only if harmonised standards are applied in full — otherwise a notified body
Important, Class II Annex III	Firewalls, IDS/IPS, hypervisors, tamper-resistant microcontrollers	Third-party assessment required
Critical Annex IV	Hardware security modules, smart meter gateways, smart cards	Third-party, and a European cybersecurity certification scheme may be mandated

The step that costs money is Class I to Class II. Self-assessment is a documentation exercise you can run internally; a notified body is a external process with lead times measured in months and fees to match. If your product is near that boundary, finding out now is worth considerably more than finding out in 2027.

The essential requirements, in plain terms

Annex I Part I — properties of the product:

• Ship with a secure default configuration, and make reset to that state possible
• No known exploitable vulnerabilities at the point of placing on the market
• Protect confidentiality and integrity of stored, transmitted and processed data — encryption where appropriate
• Process only data that is adequate, relevant and limited to what the function needs
• Protect availability of essential functions, including resilience against denial of service
• Limit attack surfaces, including external interfaces
• Reduce the impact of an incident with mitigation techniques
• Record and monitor security-relevant activity, with opt-out
• Provide security updates — automatic where appropriate, with a clear opt-out
• Allow secure deletion of all data and settings

Annex I Part II — vulnerability handling by the manufacturer:

• Identify and document components, including a machine-readable SBOM of at least the top-level dependencies
• Address and remediate vulnerabilities without delay, including by issuing updates
• Apply effective and regular tests and reviews
• Publicly disclose fixed vulnerabilities once a fix is available, with descriptions and remediation guidance
• Have a coordinated vulnerability disclosure policy, and a contact address for reporting
• Distribute updates securely and without delay, free of charge

Why the update path is the expensive one

Almost every requirement above can be satisfied by documentation and process changes late in a project. The secure update path cannot. It needs flash capacity for two images plus a recovery path, a boot ROM with verified boot, key storage that is not simply a constant in the binary, and monotonic counters to stop a rollback to a vulnerable version. All four are hardware decisions, and all four are fixed by the time the schematic is signed off.

What this tool is not

• Not legal advice. It is a planning aid, and the classification depends on facts about your product that eight questions cannot capture.
• Annex III and IV lists are summarized. Read the actual annexes before making a commercial decision, and take advice on borderline cases.
• Harmonised standards under the CRA are still being developed. The route available to Class I products depends on standards that do not all exist yet.
• Member state enforcement practice will vary, and guidance is still emerging.

Related: compliance and certification · embedded security · EMC design support

Design guidance, not a manufacturing instruction. Verify every result against your fabricator's stack-up and the applicable standard before release. Closed-form models are approximations; the fab's field solver and process window are the authority.