Cyber Resilience Act Compliance

Cybersecurity for
Embedded Devices.
CRA Enforced Oct 2027.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) mandates security requirements for every connected product sold in the EU. Mikronexis helps embedded product companies achieve compliance — from gap assessment through to complete CRA technical file.

Full Enforcement: October 2027 — Reporting obligations active September 2026 Products placed on the EU market after October 2027 must be fully CRA compliant. Non-compliant products cannot bear CE marking.
Reg. (EU) 2024/2847
EN 18031 Series
Secure Boot & Code Signing
SBOM Ready
Threat Modelling
mikronexis-cra-audit v2.4.1
$ cra-audit --product embedded-iot --standard EN18031
Initialising CRA compliance scan...
─────────────────────────────────────
[01] Secure boot chain ✓ PASS
[02] Code signing verification ✓ PASS
[03] OTA update integrity ✓ PASS
[04] Key storage (hardware) ⚠ REVIEW
[05] Vulnerability disclosure proc. ✓ PASS
[06] SBOM generation ✓ PASS
[07] Network attack surface ✓ PASS
[08] Default credentials check ✓ PASS
[09] Security update lifetime (5yr) ✓ PASS
[10] Incident reporting (24hr) ✓ PASS
─────────────────────────────────────
Score: 97/100 — CRA Class I Ready
Status: COMPLIANT — CE marking eligible
─────────────────────────────────────
$
Oct '27
CRA full enforcement deadline
24 hrs
Max incident reporting window to ENISA
5 yrs
Minimum security update support period
4
CRA product risk classifications

What Is the EU Cyber Resilience Act?

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU's first mandatory cybersecurity law covering all "products with digital elements" — hardware and software with intended or foreseeable network connectivity.

Unlike voluntary frameworks, the CRA is a legal obligation. It establishes essential security requirements that must be met before placing a product on the EU market. Non-compliant products cannot obtain CE marking — meaning they cannot be legally sold in any EU member state. It also introduces ongoing obligations: manufacturers must actively manage vulnerabilities, maintain a Software Bill of Materials (SBOM), and report actively exploited incidents to ENISA within 24 hours of discovery.

Who this applies to

Any manufacturer, importer, or distributor placing a connected product on the EU market — including IoT devices, embedded controllers, industrial equipment, consumer electronics, and software products. If it connects to a network, the CRA likely applies.

Security by Design and Default

Products must be designed with security as a core requirement — not added retrospectively. Default configurations must be secure out of the box.

Vulnerability Lifecycle Management

Manufacturers must have coordinated vulnerability disclosure processes and deliver security updates for the expected product lifetime (minimum 5 years).

SBOM & Technical Documentation

A Software Bill of Materials must be maintained. Full technical documentation covering security architecture, threat model, and test evidence is required for conformity assessment.

Incident Reporting to ENISA

Actively exploited vulnerabilities must be reported to ENISA within 24 hours of awareness, with a full report within 72 hours.

CRA Enforcement Timeline
November 2024
CRA Published — Official Journal of EU
Regulation (EU) 2024/2847 formally published. The clock to compliance starts now.
PUBLISHED
December 2024
CRA Entered Into Force
Regulation legally in force across all EU member states. Transition period begins.
IN FORCE
!
September 2026
Reporting Obligations Active
Incident reporting and vulnerability notification to ENISA becomes mandatory for all manufacturers.
14 MONTHS AWAY
!
October 2027
Full CRA Enforcement
All products placed on the EU market must be CRA compliant. No CE marking without compliance. Market surveillance authorities begin enforcement.
HARD DEADLINE

CRA Product Risk Classes

The CRA classifies products into four categories based on cybersecurity risk. Your class determines the conformity assessment route required.

Default Class
Standard Products
Self-assessment allowed

The majority of connected products. Manufacturers can self-declare conformity using internal processes aligned to CRA essential requirements.

Smart home devices
Consumer IoT gadgets
Basic connected sensors
Peripheral connected equipment
Important — Class I
Elevated Risk
Harmonised standard or third-party assessment

Products where a breach could have significant impact. Conformity requires either applying a harmonised standard (e.g. EN 18031) or third-party evaluation.

Identity management software
Password managers / VPNs
Firewalls & network routers
Microcontrollers (security role)
Important — Class II
High Risk
Mandatory third-party conformity assessment

Products with high systemic risk. Only a notified body third-party assessment satisfies the conformity requirement — self-declaration is not permitted.

Operating systems (industrial)
Hypervisors
PKI infrastructure
Industrial automation systems
Critical
Critical Infrastructure
EU cybersecurity certification scheme required

Highest-risk products. Must comply with a European cybersecurity certification scheme under the EU Cybersecurity Act (ENISA).

Smart cards / HSMs
Secure elements
Critical infrastructure controllers
Tamper-resistant hardware

Standards We Work To

The CRA mandates essential requirements. Harmonised standards define how to meet them technically.

European Union Regulation
Regulation (EU) 2024/2847
Cyber Resilience Act — Horizontal cybersecurity requirements for products with digital elements across the EU single market
CRA — Mandatory Law

The CRA establishes essential security requirements that all products with digital elements must meet before CE marking. These requirements are not guidance — they are legal obligations enforceable by market surveillance authorities in each member state. Non-compliance can result in market withdrawal, fines, and liability.

Requirement What it means Type
No known exploitable vulnerabilities at launch Products must ship without known unmitigated security vulnerabilities. Vulnerability scanning and dependency analysis are mandatory pre-launch activities. MANDATORY
Secure by default configuration Default settings must be secure. No default passwords. Unnecessary ports, services, and interfaces must be disabled by default. TECHNICAL
Data confidentiality & integrity Personal and sensitive data must be protected at rest and in transit. Integrity of transmitted commands and data must be verifiable. TECHNICAL
Minimal attack surface Only necessary interfaces, services, and communication channels should be exposed. Every exposed interface must be justified and protected. TECHNICAL
Security update mechanism Products must have mechanisms to receive and apply security updates securely and reliably for a minimum of 5 years from last placement on the market. MANDATORY
Software Bill of Materials (SBOM) Manufacturers must maintain a machine-readable SBOM covering all software components including third-party and open-source dependencies. PROCESS
Vulnerability handling & disclosure Coordinated vulnerability disclosure policy must exist and be publicly accessible. Vulnerabilities must be addressed without undue delay. PROCESS
ENISA incident reporting (24hr) Actively exploited vulnerabilities must be reported to ENISA within 24 hours (early warning), full report within 72 hours, final report within 14 days. MANDATORY
Harmonised Standard Series
EN 18031 Series
Common security requirements for radio equipment and internet-connected devices — the primary harmonised standard path for CRA conformity
CRA Harmonised Standard

The EN 18031 series is the key harmonised standard family developed to give manufacturers a defined technical path to CRA conformity. Applying EN 18031 creates a presumption of conformity with the corresponding CRA essential requirements — meaning manufacturers who fully implement the standard can self-declare compliance (for default and Class I products) without requiring individual regulatory interpretation of each requirement.

EN 18031-1 — General IoT Requirements

Security baseline for all internet-connected radio equipment and IoT devices. Covers authentication, access control, data protection, and update mechanisms.

EN 18031-2 — Internet-Connected Devices

Extended requirements for devices with direct internet connectivity, covering network-level attack surface management and remote access security.

EN 18031-3 — Wearables & Personal Devices

Security requirements specific to wearable and personal-use connected devices, with additional considerations for personal data handling.

Authentication & Access Control

Requirements for user authentication, administrative access protection, and credential management — no default credentials permissible.

Data Protection in Transit & at Rest

Cryptographic requirements for protecting sensitive data — encryption standards, key management, and integrity verification mechanisms.

Secure Update Mechanisms

Technical requirements for OTA and physical update processes — signed firmware, rollback protection, atomic update procedures, and update integrity verification.

Our CRA Compliance Process

A clear, structured path from your current state to a CRA-compliant product — with full documentation and evidence at every step.

01

CRA Gap Assessment

We review your product's current security posture against CRA essential requirements and EN 18031 controls — identifying every gap and scoring priority by risk and enforcement dependency.

Gap assessment report
Risk-prioritised remediation plan
CRA classification determination
02

Threat Modelling (STRIDE)

Systematic threat analysis of your product's architecture using the STRIDE methodology — identifying all realistic attack vectors, threat actors, and the impact of each successful attack.

Threat model document
Attack surface map
Security control mapping
03

Secure Architecture Design

Security controls are designed into the product architecture — secure boot chain, hardware security (TPM/SE), encrypted storage, minimal attack surface, and segmented communication channels.

Security architecture document
Hardware security specification
Cryptographic design doc
04

Secure Firmware Development

Implementation of all security controls — secure boot, code signing, OTA update verification, key management, runtime protections (stack canaries, ASLR where applicable), and hardened network stack.

Reviewed secure firmware
Static analysis (SAST) results
Component SBOM
05

Security Testing & Pen Test

End-to-end security validation — vulnerability scanning, fuzzing of communication interfaces, authentication bypass testing, and targeted penetration testing against the threat model attack vectors.

Vulnerability scan reports
Penetration test report
Residual risk register
06

CRA Technical File & SBOM

Complete CRA technical documentation package — security assessment, EN 18031 conformity evidence, SBOM, vulnerability disclosure policy, security update commitment, and Declaration of Conformity.

CRA technical file
Machine-readable SBOM
EU Declaration of Conformity

Who Needs CRA Compliance

Any company placing a connected product on the EU market. These sectors are most directly impacted by the CRA's scope.

Embedded & IoT Product Companies

Hardware startups and product companies building connected embedded devices — from prototype to mass market. CRA compliance is required for EU market access.

Secure Boot OTA Updates SBOM

Industrial & Manufacturing

Industrial controllers, PLCs, SCADA interfaces, and condition monitoring systems connected to OT/IT networks. Often Class I or Class II products under CRA.

Network Segmentation Access Control Third-Party Assessment

Smart Home & Consumer IoT

Connected home devices, wearables, and consumer electronics. Typically default class — self-assessment permitted but requires proper security design and documentation.

Default Security EN 18031-1 Vuln. Disclosure

Medical & Healthcare

Connected diagnostic devices, remote monitoring equipment, and clinical IoT. CRA overlaps with MDR obligations — dual compliance pathway planning is essential.

Data Encryption MDR Alignment ENISA Reporting

Automotive & Transport

Connected vehicle components, telematics units, and fleet management devices. CRA applies alongside UN R155 for automotive cybersecurity — coordinated compliance required.

UN R155 Secure Comms Lifecycle Mgmt

Energy & Smart Grid

Smart meters, grid monitoring systems, EV charging infrastructure, and renewable energy controllers. Critical infrastructure context often places these in Class II or Critical.

Critical Class 3rd-Party Audit Incident Reporting

Security Engineering in Practice

Security-aligned development applied to shipped embedded products.

Embedded Security — Shipped Product
Air OTG & OTG CO — Connected Air Quality Monitors

Customer-facing IoT devices with mobile app connectivity, cloud data sync, and firmware update capability. Designed with security-first architecture — secure communication, authenticated updates, minimal attack surface, and no hardcoded credentials. Live on the App Store. The type of connected product the CRA directly governs.

ESP32 BLE / Wi-Fi iOS & Android Cloud Backend OTA Updates Secure Comms Auth'd Updates No Default Creds
Encrypted BLE communication with authenticated pairing — no unauthenticated device access
Signed OTA firmware updates with integrity verification before application — rollback protection included
Minimal network interface exposure — only required services enabled, all others disabled by default
Successfully published on Apple App Store and Google Play — live in customer hands
THREAT MODEL — AIR OTG
MONITORED
BLE Eavesdropping
T-BLE-01 · Spoofing
MITIGATED
Firmware Injection via OTA
T-OTA-02 · Tampering
MITIGATED
Credential Extraction
T-AUTH-03 · Info Disclosure
MITIGATED
Man-in-the-Middle (Cloud)
T-NET-04 · Tampering
MITIGATED
Physical Debug Port Access
T-PHY-05 · Elevation of Privilege
ACCEPTED
DoS via BLE Flooding
T-DOS-06 · Denial of Service
MITIGATED

CRA — Frequently Asked Questions

Technical and commercial questions about CRA compliance for embedded product companies.

Products with Digital Elements (PDEs), including software, firmware, cloud systems, and SDKs. This encompasses both hardware with embedded software (IoT devices, smart sensors, industrial controllers) and standalone software products. If your product contains any form of digital logic or code, it likely falls under the CRA.
Yes. The CRA's definition of "network connectivity" is broad — it covers any means of data exchange including Bluetooth, Wi-Fi, Zigbee, LoRa, NFC, and wired interfaces. If your product can communicate with another device or system in any form, it is within scope. The only products explicitly excluded are those with purely passive data storage (no processing or connectivity), products covered by specific sector regulations that already include equivalent cybersecurity requirements (e.g. some medical devices under MDR), and open-source software published outside of commercial activity.
Products already on the market before full enforcement (October 2027) have transition protection — they are not immediately required to be withdrawn. However, any product placed (or re-placed) on the market after October 2027 must be CRA compliant, even if it is an updated version of an existing product. This means that if you release a new firmware version, new hardware revision, or market the product to a new customer after the enforcement date, compliance is required. Starting your compliance programme now (especially the gap assessment and threat model) avoids the October 2027 crunch and positions you ahead of competitors still scrambling.
Yes. Standalone software is explicitly covered, even if it's not pre-installed on hardware. This includes mobile apps, desktop applications, cloud services, firmware images distributed separately, and software development kits (SDKs). The CRA does not distinguish between software embedded in hardware and software distributed independently.
Key dates:

November 2024: CRA officially in force
September 2026: Vulnerability and incident reporting obligations begin
October 2027: Full compliance required for all products placed on the EU market

Products already on the market before October 2027 are not immediately required to be withdrawn, but any new versions, updates, or re-placements after this date must be fully compliant.
The CRA impacts a broad range of stakeholders: manufacturers (those who develop or have products developed), authorized representatives (EU-based entities representing non-EU manufacturers), importers (bringing products from outside the EU), distributors (making products available on the market), and software developers (including open-source contributors engaged in commercial activity). If you design, sell, or distribute connected products in the EU, compliance is mandatory.
Risk assessments (threat modelling and TARA), implementing secure-by-design principles (EN 18031 series), vulnerability handling (disclosure, patching, ENISA reporting), conformity assessments (self-assessment or Notified Body depending on class), maintaining technical documentation (SBOM, security architecture, test results), and providing security updates for minimum 5 years. All of these must be documented and demonstrable during market surveillance.
A Software Bill of Materials is a machine-readable inventory of every software component in your product — your own code, open-source libraries, third-party SDKs, and dependencies. Yes, it is a CRA legal requirement. The practical reason it matters: the SBOM is how you track known vulnerability exposure. When a new CVE is published for a library you use (e.g. a CVSS 9.8 vulnerability in an RTOS component), your SBOM tells you instantly whether you're affected — which is exactly the information ENISA needs from you within 24 hours. We generate SBOM files in SPDX or CycloneDX format (both accepted) as part of our compliance deliverables.
It means that from the date your product is last placed on the market, you must be capable of delivering and the product must be capable of receiving security-relevant firmware updates for a minimum of 5 years. In practice, this has three implications:

1. Hardware: The device must have an OTA update mechanism capable of receiving and applying security patches — retrofit of update capability post-launch is very difficult.

2. Organisation: You must maintain the engineering capability (internal or contracted) to identify and release security patches over this period.

3. Disclosure: If you are ending support earlier than 5 years, you must clearly disclose this in product documentation at time of sale. We design OTA update mechanisms into products as a CRA prerequisite, not as an afterthought.
The technical file must include: TARA results (Threat Analysis and Risk Assessment), SBOM (Software Bill of Materials in SPDX or CycloneDX format), security update strategy (how patches will be delivered over 5+ years), conformity assessment details (test results, certificates), vulnerability disclosure procedures, and evidence of compliance with EN 18031 series standards. This documentation must be maintained for 10 years after the last product is placed on the market.
It varies by risk category. Default and Important Class I products can use self-assessment (Module A internal control) where the manufacturer prepares the technical file and Declaration of Conformity without third-party involvement. Important Class II and Critical products require a Notified Body to review the technical documentation and issue an EU-type examination certificate. Choosing harmonised standards (EN 18031) simplifies the process and provides presumption of conformity.
Partially — they help demonstrate security posture, but don't automatically fulfill all CRA obligations. EUCC (EU Common Criteria) and SESIP (Security Evaluation Standard for IoT Platforms) focus on product-level security evaluation, which overlaps with CRA requirements. However, the CRA also requires process compliance (secure development lifecycle, vulnerability management, ongoing support obligations) that these certifications don't cover. You can leverage existing certificates as evidence but must still address CRA-specific gaps.
A Notified Body is an independent third-party organization designated by an EU Member State to evaluate Important Class II and Critical products. They review your technical documentation, assess conformity to essential requirements, and issue an EU-type examination certificate if compliant. Notified Bodies must be accredited and listed in the NANDO (New Approach Notified and Designated Organizations) database. Manufacturers of lower-risk products (Default or Important Class I) don't need a Notified Body unless they opt for third-party assessment voluntarily.
Non-compliance carries serious consequences: financial penalties (up to €15 million or 2.5% of global annual turnover, whichever is higher), product bans (market surveillance authorities can order withdrawal or recall), reputational damage (public non-compliance notices), and inability to apply CE marking (which blocks EU market access entirely). Additionally, companies may face civil liability if a security incident occurs due to non-compliance.
CRA compliance is required for CE marking of digital products placed on the EU market. After October 2027, you cannot affix the CE mark to a product with digital elements unless it meets CRA essential requirements. The CE marking indicates conformity to all applicable EU legislation — the CRA becomes part of that legislative framework. Without a valid Declaration of Conformity covering CRA obligations, the CE mark is legally invalid.
Yes. If you're a non-EU manufacturer selling into the European market, you must appoint an authorized representative established in the EU and fully meet CRA requirements before placing products on the market. The authorized representative acts as your legal point of contact for EU authorities and shares certain compliance responsibilities. This applies whether you sell directly, through distributors, or via online marketplaces.
We handle the complete engineering side of the CRA compliance journey — gap assessment, threat modelling, secure architecture design, compliant firmware development, security testing, SBOM generation, and full technical file preparation including the Declaration of Conformity. For Class I products using harmonised standards (EN 18031), this entire path can be completed without a notified body. For Class II products where a third-party conformity assessment is mandatory, we prepare the complete technical submission package and coordinate with the notified body on your behalf. We do not provide legal advice but will flag any product liability or regulatory interpretation questions to be confirmed with your legal counsel.

CRA Compliance Starts With a Gap Assessment

Most connected embedded products have significant CRA gaps — especially around SBOM, OTA update security, and vulnerability disclosure processes. A gap assessment tells you exactly where you stand and what it takes to get compliant before the October 2027 enforcement date.

September 2026: Reporting obligations become active — 15 months away Your vulnerability disclosure process and ENISA reporting capability need to be in place before September 2026. Starting your compliance programme now ensures you hit this milestone without a crunch.
CRA Gap Assessment
EN 18031 Series Implementation
Threat Modelling & Pen Testing
SBOM Generation
Full Technical File
Declaration of Conformity