01What is the Cyber Resilience Act?
The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets common cybersecurity rules for connected products with software or hardware placed on the EU market. It requires manufacturers to design products securely, fix vulnerabilities throughout a support period and report actively exploited vulnerabilities within 24 hours. Reporting has applied since 11 September 2026; all requirements apply from 11 December 2027.
For the latest implementation developments (standards, Commission acts, the ENISA platform, notified bodies), see the EU CRA status page.
Cyber Resilience Act summary
- Who: manufacturers placing products with digital elements on the EU market; importers and distributors have checking duties. For your field, see our industry pages.
- What: the Annex I security requirements, vulnerability handling including an SBOM, a support period of at least five years unless the product's expected use is shorter, technical documentation and the CE marking.
- How: internal control by the manufacturer or assessment by a notified body, depending on the product class. See your likely class with the class check.
- When: Article 14 reporting since 11 September 2026, everything else from 11 December 2027.
- Penalties: administrative fines of up to €15 million or 2.5% of worldwide annual turnover.
02Timeline
- December 10, 2024Regulation enters into forcePublished in the Official Journal on 20 November 2024, in force 20 days later.
- June 11, 2026Notified bodiesProvisions on notifying conformity assessment bodies started to apply.
- September 11, 2026Article 14 reportingThe obligation to report actively exploited vulnerabilities and severe incidents started.
- December 11, 2027Full applicationAll provisions apply, including essential requirements and conformity assessment.
03Who is covered
Any product with software or hardware that can connect, directly or indirectly, to a device or network counts as a "product with digital elements". Smart home devices, industrial controllers, network equipment, wearables and the software sold with them all fall under this definition.
Most obligations sit with the manufacturer. Importers and distributors must check that the manufacturer has met its obligations. An importer or distributor that sells a product under its own name, or substantially modifies it, is treated as the manufacturer.
Examples and typical classes by industry: network and telecom equipment, smart home and appliances, industrial automation and electronics.
Out of scope
- Products with their own sector rules: medical devices, type-approved motor vehicles (Regulation (EU) 2019/2144), civil aviation and marine equipment
- Products developed exclusively for national security or defence
- Open-source software developed outside a commercial activity
- Spare parts made to replace identical components
04Essential requirements (Annex I)
Annex I has two parts. Part I is about the product itself, Part II about how the manufacturer handles vulnerabilities.
Part I: Product properties
- Placed on the market without known exploitable vulnerabilities
- Secure by default configuration, with a way to reset to the original state
- Security updates can be applied, automatically where possible
- Authentication and access control against unauthorised access
- Confidentiality and integrity of stored and transmitted data
- Minimal attack surface and minimal data
- Security-relevant events are logged and can be monitored
- Availability of essential functions and resilience against denial-of-service attacks
- Minimal negative impact on services provided by other devices or networks
- Exploitation mitigation mechanisms that reduce the impact of an incident
- Secure deletion of data and settings, and secure transfer to another product
Part II: Vulnerability handling
- Components documented in a machine-readable SBOM, covering at least top-level dependencies
- Vulnerabilities addressed without delay through security updates
- Regular testing of the product
- Public disclosure of fixed vulnerabilities
- A coordinated vulnerability disclosure policy and a contact address
- Secure distribution of updates, with security patches provided free of charge
05Product classes and conformity assessment
The class of your product decides whether you can declare conformity yourself or need an independent body to assess it.
See your product's likely class with our short class check, and read the product classes guide for the details.
| Class | Examples | Conformity assessment |
|---|---|---|
| Default | Products not listed in Annex III or IV, which is most products with digital elements | Manufacturer's internal control (Module A) |
| Important, Class I (Annex III) | Microcontrollers and microprocessors with security functions, routers and modems, smart locks, security cameras, alarm systems, VPNs, password managers | Internal control if a harmonised standard is applied, otherwise third-party assessment |
| Important, Class II (Annex III) | Hypervisors, firewalls, intrusion detection systems, tamper-resistant microprocessors and microcontrollers | Third-party assessment by a notified body |
| Critical (Annex IV) | Hardware devices with security boxes, smart meter gateways, smartcards and secure elements | European cybersecurity certificate (where required), otherwise as Class II |
06Article 14: Reporting deadlines
When a manufacturer becomes aware of an actively exploited vulnerability in its product or a severe incident affecting the product's security, it must report it to the competent CSIRT through ENISA's single reporting platform. This has applied since 11 September 2026 and also covers products placed on the market before that date.
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Within 24 hours of becoming aware |
| Notification | Within 72 hours | Within 72 hours |
| Final report | No later than 14 days after a corrective measure is available | Within 1 month of the notification |
The manufacturer must also inform affected users and, where needed, tell them what they can do to mitigate the issue.
07Support period and documentation
- Support period: Must reflect the expected lifetime of the product and be at least 5 years, unless the product is expected to be used for less. Security updates must be provided throughout.
- Technical documentation: Including the risk assessment, SBOM and test results. Kept for 10 years after placing on the market, or for the support period if that is longer.
- EU declaration of conformity and CE marking: Drawn up after the conformity assessment; the product is placed on the market with the CE mark.
08Penalties (Article 64)
| Infringement | Maximum |
|---|---|
| Annex I essential requirements, Articles 13 and 14 | €15 million or 2.5% of worldwide annual turnover |
| Other obligations | €10 million or 2% |
| Incorrect, incomplete or misleading information to authorities | €5 million or 1% |
In each case the higher amount applies. Market surveillance authorities can also require a non-compliant product to be withdrawn.
09How TegmenSoft maps to it
This is which module of our platform serves which obligation.
To try these modules on your own firmware, see our pilot programme.
| Obligation | Module |
|---|---|
| Annex I Part II(1): SBOM | Dynamic SBOM Engine (CycloneDX 1.6, SPDX 2.3) |
| Annex I Part II(2-3): remediation and testing | Matching against OSV and NVD, CISA KEV and EPSS prioritisation, VEX (CSAF 2.0, OpenVEX) |
| Article 13(8): monitoring during the support period | Earlier SBOMs re-checked as new vulnerability data arrives |
| Article 14: 24/72 hours and final report | CRA Reporting Assistant: deadline tracking and report drafts |
| Annex I Part I and II(7-8): secure update distribution | Secure OTA Manager: signed releases, A/B slots, anti-rollback protection |
| Article 31 and Annex VII: technical documentation | Annex VII draft, EU declaration of conformity draft, signed evidence packages kept for 10 years or the support period, whichever is longer |
10Frequently asked questions
What is the Cyber Resilience Act (CRA)?
The Cyber Resilience Act is Regulation (EU) 2024/2847. It sets common cybersecurity rules for connected products with software or hardware placed on the EU market: secure design, fixing vulnerabilities throughout a support period and reporting actively exploited vulnerabilities within 24 hours. Reporting has been mandatory since 11 September 2026; all requirements apply from 11 December 2027.
When did the CRA enter into force and when does it apply?
The Regulation entered into force on 10 December 2024. Article 14 reporting has applied since 11 September 2026. All provisions, including essential requirements and conformity assessment, apply from 11 December 2027.
How high are CRA penalties?
For Annex I essential requirements and Articles 13 and 14: €15 million or 2.5% of worldwide annual turnover; for other obligations: €10 million or 2%; for incorrect information to authorities: €5 million or 1%. The higher amount applies in each case. These rules are in Article 64.
Is "CRA Article 35" the penalties article?
No. In the adopted text, Regulation (EU) 2024/2847, Article 35 covers the notification of conformity assessment bodies. Penalties are set out in Article 64, with the amounts above.
Which companies help with CRA compliance?
Compliance work usually involves legal advisers, testing and certification bodies and technical tool providers. TegmenSoft works on the technical side: SBOM, vulnerability matching, Article 14 reporting drafts and signed OTA updates for embedded and IoT manufacturers.
What is the difference between EN 18031 and the CRA?
The EN 18031 series supports the cybersecurity requirements of the Radio Equipment Directive (RED), which apply to wireless products since 1 August 2025. The CRA is a separate regulation; its harmonised standards are being prepared by CEN, CENELEC and ETSI.
Does the CRA apply if my product is not sold in the EU?
The CRA applies to products made available on the EU market. If your product is sold in the EU through a distributor or importer, the manufacturer obligations fall on you.
Guides
- CRA Article 14: vulnerability and incident reportingWhen, to whom and how fast to report. 24 hours, 72 hours and the final report, with a free deadline calculator.
- CRA product classes, conformity assessment and CE markingDefault, important (Class I and II) and critical products; which module applies and when you need a notified body.
- EN 18031 and RED: how they relate to the CRACybersecurity requirements for radio equipment in force since 1 August 2025, and the move to the CRA.
- CRA readiness guideFor every manufacturer selling into the EU: roles, timeline, extra points for non-EU manufacturers and a step-by-step checklist.
- What is an SBOM? A guide for firmware teamsWhat goes into an SBOM, SPDX and CycloneDX, why firmware makes it hard, what the CRA and BSI TR-03183-2 expect, and VEX.
- IEC 62443 and the CRA: mapping and gapsWhere IEC 62443-4-1 and 4-2 meet CRA Annex I, the obligations they leave open, the CENELEC amendments and what certification is worth.
- ENISA SRP: before your first reportEU Login and representatives, choosing the coordinating CSIRT, the platform's counters, closing a submitted notification and a short checklist.
- EU CRA: current status and timelineTimeline, harmonised standards, Commission acts, the ENISA SRP and notified bodies; checked against the official sources every month.
Which class is your product in?
Answer a few questions to see your product's likely class and conformity assessment route; for a firm assessment we can go through it together using your product.