OnwynOnwyn › Standards › EU Cyber Resilience Act (Regulation (EU) 2024/2847)
Regulation · 2024/2847EU Cyber Resilience Act (Regulation (EU) 2024/2847)
The Cyber Resilience Act is EU product law for anything with digital elements — hardware, embedded devices, and software — placed on the EU market. It works like CE marking for safety, but for cybersecurity: the manufacturer must design the product against essential cybersecurity requirements, run a documented vulnerability handling process for a defined support period, compile technical documentation, carry out a conformity assessment, draw up an EU declaration of conformity, and affix the CE mark. It entered into force on 10 December 2024 and applies in full from 11 December 2027, with two earlier milestones: the rules on notified bodies from 11 June 2026 and the manufacturer's obligation to report actively exploited vulnerabilities and severe incidents from 11 September 2026. Anyone who places a product on the EU market under their own name or trademark, or who substantially modifies one, is the manufacturer for these purposes — which catches many companies that consider themselves resellers or integrators. Penalties for breaching the essential requirements reach EUR 15 million or 2.5 percent of worldwide annual turnover.
What this standard asks for
Every requirement in EU Cyber Resilience Act (Regulation (EU) 2024/2847), grouped the way the standard groups them. In the Compliance Engine each one carries what to do, how to evidence it, what auditors commonly reject, and a button to bring in a consultant if you would rather not work it out alone.
Scope, roles, product classes & dates
5 requirements
- Art. 2Determine whether your product is in scope
- Art. 71Application dates and a dated readiness plan
- Annex III / Annex IVClassify each product: default, important class I or II, or critical
- Ch. II — economic operator rolesEstablish your role, including when you become the manufacturer
- Art. 24Open-source stewards and the commercial-activity boundary
Essential cybersecurity requirements (Annex I, Part I)
11 requirements
- Annex I, Part I (1) / Art. 13(2)Risk-based secure design and the documented cybersecurity risk assessment
- Annex I, Part I (2)(a)No known exploitable vulnerabilities at release
- Annex I, Part I (2)(b)Secure by default configuration, with a reset option
- Annex I, Part I (2)(c)Updatability, including automatic security updates by default
- Annex I, Part I (2)(d)Protection from unauthorised access
- Annex I, Part I (2)(e)-(f)Confidentiality and integrity of data, commands and configuration
- Annex I, Part I (2)(g)Process only the data that is necessary
- Annex I, Part I (2)(h)-(i)Availability of essential functions, and no harm to other systems
- Annex I, Part I (2)(j)-(k)Limit the attack surface and reduce the impact of an incident
- Annex I, Part I (2)(l)Security-relevant logging and monitoring, with a user opt-out
- Annex I, Part I (2)(m)Secure removal and transfer of user data
Vulnerability handling (Annex I, Part II)
7 requirements
- Annex I, Part II (1)Identify components and produce a software bill of materials
- Annex I, Part II (2) and (8)Remediate without delay and distribute security updates free of charge
- Annex I, Part II (3)Test and review the security of the product regularly
- Annex I, Part II (4)Publish information about fixed vulnerabilities
- Annex I, Part II (5)-(6)Coordinated vulnerability disclosure policy and reporting contact
- Annex I, Part II (7)Secure distribution of updates
- Art. 13 — support periodDetermine, honour and communicate the support period
Third-party and open-source components
2 requirements
- Art. 13 — component due diligenceDue diligence on integrated third-party components
- Art. 13 — upstream reportingReport vulnerabilities upstream and share your fixes
Conformity assessment, CE marking & documentation
5 requirements
- Art. 32Choose and complete the right conformity assessment procedure
- Art. 27Use harmonised standards for presumption of conformity
- Art. 31 / Annex VIITechnical documentation, drawn up before placing on the market
- Art. 28-30EU declaration of conformity and CE marking
- Annex IIInformation and instructions for the user
Reporting exploited vulnerabilities & severe incidents
3 requirements
- Art. 14(1)-(2)Report actively exploited vulnerabilities: 24 hours, 72 hours, 14 days
- Art. 14(3)-(4)Report severe incidents affecting product security: 24 hours, 72 hours, one month
- Art. 14(8)Inform your users about the vulnerability or incident
The documents you will end up with
The recommended document set for EU Cyber Resilience Act (Regulation (EU) 2024/2847) — 16 in total. The engine tracks which you have, which are missing, and which of your existing documents already cover a requirement.
For each product you place on the EU market: whether the CRA applies, which class it falls into, and which economic operator role you are playing.
The dated plan to the reporting obligations and the main application date, with an owner against each gap.
The documented analysis of what could go wrong with this product in the hands of real users, which drives every design decision that follows.
The Annex VII dossier a market surveillance authority can demand: what the product is, how it was designed and tested, and the evidence behind the conformity claim.
Requirement by requirement, how the product actually meets each Annex I security property — and where the code or configuration that does it lives.
The machine-readable list of components in the product, so that when a component turns out to be vulnerable you know within minutes whether you ship it.
How vulnerabilities in your product are found, triaged, fixed and shipped — including that security updates go out free of charge and separately from features.
The public page telling a researcher where to send a finding, what you will do with it, and how long you will take — plus the contact address you commit to monitoring.
How you publish what was fixed, how bad it was and what users must do — and how you reach users directly when something urgent happens.
What you checked before integrating each third-party or open-source component, and what you do when its maintainer goes quiet.
The end date after which the product stops receiving security updates, how you arrived at it, and where users can read it before they buy.
Which assessment route the product went through, which harmonised standards you relied on, and the notified body involvement if any.
The one-page signed statement that the product meets the regulation, which is what allows the CE mark to go on it.
What ships with the product: how to install and run it securely, the secure defaults, how to reset it, and where security updates come from.
The 24-hour, 72-hour and follow-up clocks for telling ENISA and your CSIRT about an actively exploited vulnerability or a severe incident, and who is allowed to press send.
If you steward open-source software commercially: how you support secure development in the project and handle vulnerabilities in it.
Work that counts twice
EU Cyber Resilience Act (Regulation (EU) 2024/2847) overlaps with 3 other frameworks in the engine. When you start one of these, the requirements you have already settled here are carried across as suggestions for you to confirm — you review them, we never mark them done on your behalf.
Start EU Cyber Resilience Act today
Every live framework is included in one subscription — no per-framework pricing. Your first 30 days are free, we ask for no card, and there is nothing to cancel. On any requirement you can bring in a senior consultant for a review, a call, or done-for-you implementation.