A Guide to the EU Cyber Resilience Act (CRA): IoT Cybersecurity Compliance

For product engineering teams, building software and hardware targeted at European markets is undergoing a massive shift. The European Union’s Cyber Resilience Act (CRA) transforms security from a post-release patch game into a non-negotiable core design requirement. Under this regulation, any product with digital elements (PDE) must meet strict technical requirements and affix the CE mark to be legally bought, sold, or distributed within EU member states.

Historically, the CE mark primarily signaled compliance with physical, health, and structural safety standards (such as electrical safety or toy safety). Under the CRA, the CE mark expands to formally incorporate digital and cybersecurity compliance. While vulnerability reporting obligations take effect on September 11, 2026, full CRA enforcement—including mandatory CE marking for cybersecurity—becomes strictly required for products placed on the EU market starting December 11, 2027.

What Is the EU Cyber Resilience Act (CRA)?

To better understand the CRA, we need to briefly examine its precursor: the EU Radio Equipment Directive (EU RED). Building on the foundation of the EU Cybersecurity Act of 2019 (CSA), EU RED Article 3.3 was introduced to establish mandatory security benchmarks for wireless IoT devices. The rules of EU RED Article 3.3 are applicable to any radio equipment capable of communicating over the internet (directly or via intermediary gateways). EU RED presents three essential pillars of protection; compliance with these pillars is mapped directly to the EN 18031 series of harmonized European technical standards:

Network Protection (Article 3.3, sub-article D; compliance mapped to EN 18031-1)

• Goal: Prevent devices from damaging or disrupting communication networks or misusing network resources.
• Key Controls: Protection against Distributed Denial of Service (DDoS) botnet recruitment, prevention of abusive signaling that degrades cellular/Wi-Fi bandwidth, implementation of secure authentication protocols, and resistance to unauthorized network access.

Data Protection and Privacy (Article 3.3, sub-article E; compliance mapped to EN 18031-2)

• Goal: Reinforce GDPR compliance; ensure safeguards exist within devices to protect personal data and user privacy.
• Key Controls: Strong encryption for data at rest and in transit, prohibition of unencrypted default passwords, fine-grained access controls, protection against unauthorized telemetry collection, and mechanisms to clear personal data before device disposal.

Fraud Protection (Article 3.3, sub-article F; compliance mapped to EN 18031-3)

• Goal: Minimize the risk of monetary and identity fraud for devices handling virtual payments or financial transactions.
• Key Controls: Secure Boot to prevent unauthorized firmware modifications, anti-cloning identity mechanisms, multi-factor/biometric user verification for payments, and encrypted payment processing channels.

The application of EU RED Article 3.3 cybersecurity requirements became mandatory on August 1, 2025. Wireless connected devices placed in the EU market must comply to receive the CE mark. While EU RED Article 3.3 covers “Day-1” device security at market entry, it does not cover ongoing product support. CRA encompasses all of EU RED Article 3.3 (so “Day-1” device security at market entry) and the security concerns across the product lifecycle.

The CRA is a mandatory framework for hardware and software manufacturers. It shifts liability directly onto manufacturers, establishing strict baselines before a device or software package can be placed on the market:

• Secure-by-Design and Secure-by-Default: Security must be engineered into initial design phases rather than added reactively. Products must ship with maximum privacy/security settings enabled out of the box (e.g., closing unused ports, default auto-updates).
• Strip away unneeded code, unused libraries, and redundant administrative endpoints. Enforce minimal access permissions across system processes.
• Hardware-Anchored Trust and Cryptography: Leverage hardware mechanisms like a Root of Trust (RoT) to ensure untampered firmware execution, while enforcing encryption for data at rest and in transit.
• Software Transparency: Maintain and continuously update a Software Bill of Materials (SBOM) to track third-party dependencies and open-source packages.

CE Mark Compliance Routing by Risk Tier

Not every product faces the same level of scrutiny. The CRA categorizes products into distinct risk classes, dictating how engineering teams must prove compliance:

Risk Tier	Example Products	Assessment Path
Default (~90% of PDEs)	Smart TVs, fitness trackers, smart home appliances, simple IoT sensors, standard apps	Module A: Self-assessment and internal technical documentation.
Important Class I	Password managers, web browsers, home routers, non-critical microcontrollers	Option A: Self-assessment using EU Harmonized Standards. Option B: Third-party audit by an independent Notified Body.
Important Class II	Firewalls, desktop/server OS, hypervisors, enterprise VPNs, Industrial Control Systems	Mandatory Third-Party Audit: Technical design inspection and testing by a Notified Body (Module B+C or H).
Critical PDEs	Hardware Security Modules (HSMs), smartcard OS (passports/banking), smart grid gateways	Mandatory EU Certificate: Formal European scheme certification (EUCC) at “Substantial” or “High” assurance.

System Architecture: Engineering for End-to-End Secure Design

To satisfy these regulatory requirements, engineering teams must map security principles directly across system hardware, firmware, runtime, and update infrastructure.

Secure-by-Design System Architecture for CRA Compliance

Architecture Breakdown:

• Hardware and Silicon Layer: Establishes device identity in physical silicon. Cryptographic keys and anti-rollback counters reside in One-Time Programmable (OTP) eFuses or dedicated Secure Elements.
• Boot and Firmware Verification: Executes a cryptographic chain of trust. Immutable ROM code verifies the stage-one bootloader, which in turn authenticates the system firmware signature before execution.
• Runtime OS and Isolation Layer: Strips unneeded interfaces, disables physical debug ports (like JTAG), and enforces process sandboxing. Non-volatile memory (Flash/NVM) is fully encrypted.
• External Lifecycle and Connectivity: Integrates cryptographically signed Over-The-Air (OTA) update ingestion and maintains real-time dependency tracking through automated SBOM generation.

Post-Release Lifecycles and Exploitation Timelines

Compliance does not end at product release. Manufacturers must explicitly declare a “period of support” matching expected product lifespan to guarantee security patches and vulnerability management.
When an actively exploited vulnerability occurs, meaning a flaw is being used in real-world attacks, engineering and incident teams must report to ENISA’s central Single Reporting Platform (SRP) under strict timelines:

• 24-Hour Early Warning: Basic product identification and confirmation of active exploit.
• 72-Hour Technical Notification: Exploit mechanics, impact assessment, and immediate user workarounds.
• 14-Day Final Report: Complete root-cause analysis and patch deployment metrics (clock starts as soon as a workaround or fix is available).

Documentation and Processes for CRA Self-Assessment

For those products that fall into CRA’s Default tier, manufacturers can self-assess compliance using the official procedure as outlined in Module A of the CRA (located in Annex VIII, Part I).
While external auditors are not mandated for this tier, self-certification remains a formal legal undertaking, necessitating comprehensive engineering protocols, robust internal safeguards, and meticulously maintained technical records.

The Five Mandatory Internal Processes

There are five mandatory internal processes that must run to fruition before a manufacturer can declare compliance:

1. Cybersecurity Risk Assessment: A formal risk assessment analysis encompassing the products’ entire lifecycle is executed. Potential vulnerabilities, threat models, and attack surfaces are identified. Mitigation actions for each risk are recorded.
2. Secure-by-Design Development: Security controls are integrated in product design. Secure default settings are used; data is encrypted; access controls are applied; attack surface is minimized.
3. Vulnerability and Patch Management: Coordinated Vulnerability Disclosure (CVD) policy is established; mechanisms to build and push automatic, signed security updates are created; a dedicated communication channel for security researchers is established and publicized.
4. Support Period Determination: The product’s support period is formally calculated. This period is based on expected product lifespan, customer expectations, and technological standards.
5. Market Monitoring and Incident Reporting: Real-time telemetry/monitoring is created to detect actively exploited vulnerabilities, often necessitating enterprise-level cybersecurity infrastructure to maintain operational readiness to report severe incidents via ENISA’s platform.

The Technical Documentation File and EU DoC

All evidence from self-assessment must be compiled into a central Technical Documentation File (see CRA, Annex VII) and supported by official declarations. The Technical File serves as legal proof of compliance. If a national market surveillance authority (MSA) audits the company, they will start with the Technical Documentation File. The file contains:

• General Product Description: Contains purpose, software/hardware versions, user manuals, and safety instructions.
• System Architecture and Design: Diagrams detailing system components, software dependencies, external interfaces, and data flow.
• Cybersecurity Risk Assessment: Detailed matrix of identified risk and technical mitigations applied.
• Software Bill of Materials: Must be machine-readable format (i.e., JSON, XML). A dynamic inventory tracking of open-source components, third-party libraries, and dependencies.
• Applied Standards List: Record of applicable EU Harmonized Standards (or alternative technical specifications) applied during development.
• Testing and Validation Reports: Documentation of internal security testing, static/dynamic code analysis (SAST/DAST), penetration testing, or vulnerability scanning.
• Support Period Justification: Documented rationale explaining how the support timeframe was determined.

Also, the EU Declaration of Conformity (DoC) (see CRA, Annex V/VI) document is required. The EU DoC is a legally binding document signed by a senior executive stating that the product complies with the CRA. The document must contain:

• Manufacturer’s legal name and address
• Product identification code (e.g., model name, software/hardware versions)
• Statement of Sole Responsibility
• List of reference legislation (i.e., CRA and any other applicable EU acts like EU RED)
• List of harmonized standards or technical specifications
• Signature, date, and title of authorized corporate officer

Once self-assessment has completed (meaning that the EU DoC is signed and the technical file is finalized), then the CE mark is affixed to the physical product, packaging, or digital interface.

The technical documentation is not a static, one-time document. It is a living document. It must be continuously updated whenever there are software updates, feature changes, and/or new vulnerabilities emerge throughout the product support period.

The technical file and EU DoC must be retained and made available to EU market surveillance authorities for 10 years after the product is placed on the market or for the duration of the support period (whichever is longer).

Engineering for CRA Compliance and the CE Mark

By aligning system architecture, hardware trust mechanisms, and automated incident pipelines, engineering teams can turn CRA compliance into a structural standard for product engineering.

The EU Cyber Resilience Act turns security into a non-negotiable hardware and software baseline. Contact Cardinal Peak to discuss how our embedded security services can de-risk your product roadmap and ensure CE mark compliance for the European market.