The Cyber Resilience Act (CRA) is one of the most significant cybersecurity regulations introduced by the European Union in recent years.
It is often described as a framework to improve the security of digital products. In reality, it goes further: it defines binding legal obligations for how products must be designed, maintained, and secured over time [1].
For teams working on embedded systems, firmware, or connected devices, understanding the CRA is not optional. It directly impacts how products are built and operated.
A regulation for “products with digital elements”
At its core, the CRA applies to products with digital elements, a deliberately broad category defined in the legal text [1].
This includes:
- connected devices (IoT)
- embedded systems
- software products
- hardware running firmware
If a product can process data, communicate, or be updated, it is likely within scope.
This broad definition reflects the EU’s intent to cover the full spectrum of modern digital products, rather than limiting the regulation to specific sectors [2].
The objective: security over the full lifecycle
The CRA establishes a key principle: products must remain secure throughout their entire lifecycle.
This includes:
- design and development
- placement on the market
- post-market monitoring
- end-of-life considerations
Manufacturers are expected not only to build secure products, but also to manage vulnerabilities and deliver security updates over time [1][3].
This lifecycle approach is central to the regulation and marks a departure from traditional compliance models.
Who is concerned?
The CRA applies to multiple actors involved in bringing products to the EU market:
- Manufacturers
- Importers
- Distributors
However, the primary responsibility lies with the manufacturer, defined as the entity placing the product on the market under its name or trademark [1].
Importantly, the regulation applies regardless of company size.
Small and medium-sized manufacturers are subject to the same obligations, even if implementation complexity differs.
What does the CRA require?
Rather than a single requirement, the CRA defines a structured set of cybersecurity obligations. These are detailed in Annex I of the regulation [1] and further interpreted in supporting documents [5].
They can be understood across three main dimensions.
Secure design and development
Products must be designed according to secure-by-design principles.
This includes minimizing attack surfaces, avoiding insecure default configurations, and implementing appropriate access controls.
Vulnerability management
Manufacturers must establish processes to:
- identify vulnerabilities
- assess their impact
- remediate them in a timely manner
This applies not only to internally developed code, but also to third-party components and dependencies.
The regulation also introduces obligations for coordinated vulnerability disclosure and handling [3].
Transparency and documentation
Organizations must maintain visibility into the composition and security posture of their products.
This includes:
- technical documentation
- security-related information for users
- reporting obligations in case of incidents
Efforts such as ENISA’s standards mapping highlight how these requirements align with existing cybersecurity frameworks [5].
A shift from best practices to legal obligations
Many of the CRA requirements reflect existing industry practices.
However, the key change lies in enforcement.
Practices such as:
- secure development
- vulnerability tracking
- patch management
are no longer recommendations. They become mandatory and auditable obligations [1].
This transforms cybersecurity from a technical discipline into a compliance domain with legal implications.
Risk-based approach and product categories
The CRA introduces a classification of products based on their criticality.
Certain categories of products, considered more sensitive, are subject to stricter conformity assessment procedures [1].
In addition, implementing acts — such as decision C(2025)618 — provide further detail on how specific requirements may be applied in practice [4].
This risk-based approach allows the regulation to scale across different product types while maintaining a consistent baseline.
Enforcement and penalties
As an EU regulation, the CRA is directly applicable across Member States.
Non-compliance may result in:
- financial penalties
- market restrictions
- mandatory corrective measures
The regulation introduces enforcement mechanisms comparable to other major EU frameworks, ensuring that requirements are not purely theoretical [1][2].
Timeline and entry into force
The Cyber Resilience Act entered into force in late 2024 following its publication in the Official Journal of the European Union [1].
However, its application is phased.
Most core obligations will become enforceable after a transition period of approximately 36 months, giving organizations time to adapt their processes and tooling. This places the main compliance horizon around 2027.
Some requirements apply earlier. In particular, obligations related to vulnerability handling and incident reporting are expected to be enforced sooner, typically within 24 months [2][3].
This staggered timeline reflects the operational complexity of the regulation.
Implementing continuous vulnerability management, documentation, and reporting processes cannot be done overnight.
In practice, organizations that delay preparation risk compressing several years of structural changes into a much shorter timeframe.
Why the CRA matters in practice
Beyond regulatory compliance, the CRA reflects a broader evolution in how security is perceived.
Products are increasingly:
- connected
- software-driven
- exposed to continuous threats
At the same time, expectations from regulators and customers are rising.
The CRA formalizes these expectations into a structured and enforceable framework.
For engineering teams, this translates into a need for:
- traceability
- repeatable processes
- continuous visibility
Conclusion
The Cyber Resilience Act establishes a clear direction:
security must be built in, maintained, and demonstrated over time.
For IoT and embedded systems teams, this introduces a new level of accountability.
The challenge is not understanding the regulation — the core principles are well documented.
The challenge lies in operationalizing these requirements within real-world constraints.
References
[1] Cyber Resilience Act – Legal text: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847
[2] Cyber Resilience Act – Summary: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
[3] CRA FAQ: https://ec.europa.eu/newsroom/dae/redirection/document/122331
[4] Implementing decision C(2025)618: https://ec.europa.eu/transparency/documents-register/detail?ref=C(2025)618&lang=en
[5] ENISA CRA Requirements Mapping: https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf