The EU Cyber Resilience Act (Regulation EU 2024/2847) requires all manufacturers of connected hardware and software products sold in the European Union to implement mandatory cybersecurity measures and maintain technical documentation by December 11, 2027. Products that do not comply cannot be legally placed on the EU market. Fines reach up to €15 million or 2.5% of global annual turnover — whichever is higher — and authorities can order product recalls and market bans.
If you make IoT devices, smart hardware, or any product with a digital component and plan to sell in the EU, this law applies to you directly.
Why CRA exists — and why it matters more than most manufacturers realise
For years, the IoT market had a dirty secret: security was optional. A smart lock, an industrial sensor, a connected appliance — all could ship with hardcoded passwords, no firmware verification, and zero update mechanism. Manufacturers got away with it because there was no law that said otherwise.
The result was predictable. The Mirai botnet in 2016 turned hundreds of thousands of compromised IoT devices into a weapon that knocked major internet infrastructure offline. Similar attacks happened again in 2017, 2019, 2021. The devices involved were not exotic or niche — they were consumer cameras, routers, and home appliances from mainstream manufacturers.
The European Union watched this pattern and decided someone had to be responsible. CRA shifts that responsibility clearly and permanently to the manufacturer.
The logic is straightforward: the person who designs and sells the product is the only one in a position to build security in from the start. Users cannot patch firmware they cannot access. Enterprises cannot secure devices they did not build. Only manufacturers can make this decision — so CRA makes it a legal obligation.
Who CRA applies to
CRA applies to any manufacturer, importer, or distributor that places a "product with digital elements" on the EU market — regardless of where the company is based.
A Ukrainian startup, a Polish SME, a Taiwanese hardware company, a US software vendor — if the product is sold in the EU and has a digital component, CRA applies.
What counts as a "product with digital elements":
- Any hardware device with embedded software (IoT devices, smart appliances, industrial equipment, medical devices outside MDR scope)
- Standalone software products
- Mobile applications that are integral to a hardware product's operation
- Any product that connects directly or indirectly to a network or another device
The scope is intentionally broad. If your product has a microcontroller, a wireless radio, or an app — you are in scope.
What is explicitly excluded:
- Medical devices (regulated under MDR and IVDR)
- Aviation equipment (EASA regulations apply)
- Automotive products (UN ECE Regulations R155/R156)
- Marine equipment
- Open source software distributed freely for non-commercial purposes
- Products developed exclusively for national defence or security
If your product falls under one of these exclusions, check the specific sectoral regulation — it likely has its own security requirements.
Product categories: how CRA classifies risk
CRA divides all in-scope products into three categories based on cybersecurity risk. This classification determines what kind of compliance process you need to follow.
Default Products (~90% of the market)
Most consumer and business IoT devices fall here. Products that are not explicitly listed as Important or Critical are Default by definition.
Compliance process: Self-assessment. You evaluate your own product against CRA requirements, prepare the technical documentation, sign the Declaration of Conformity, and apply CE marking. No third-party auditor required.
Examples: smart home appliances, consumer electronics, most BLE-connected devices, basic industrial sensors.
Important Products — Class I
Products with functions that carry elevated cybersecurity risk. Class I products require either self-assessment against harmonised standards or third-party assessment if harmonised standards are not applied.
Examples: identity management and access control systems, smart locks and security cameras, wearable health monitors (non-medical), connected toys.
Important Products — Class II
Higher criticality. Third-party conformity assessment by a Notified Body is mandatory regardless of whether you follow harmonised standards.
Examples: firewalls, intrusion detection systems, hypervisors, tamper-resistant microprocessors.
Critical Products
The highest risk tier. Requires a European cybersecurity certification scheme (such as EUCC).
Examples: hardware security modules (HSM), root CA software, smart card readers for PKI infrastructure.
For most IoT and hardware manufacturers in the SME space, the relevant question is whether you are Default or Important Class I. Getting this classification right early matters — it determines your entire compliance path.
The key deadlines — and why September 2026 is the one most manufacturers miss
There are three dates that matter:
June 11, 2026 — EU member states must designate and notify conformity assessment bodies (Notified Bodies). This is the infrastructure going live. The compliance machinery is now operational.
September 11, 2026 — Mandatory vulnerability and incident reporting obligations enter into force. From this date, if an actively exploited vulnerability is discovered in your product, you must report it to ENISA and your national CSIRT within 24 hours, with a full notification within 72 hours and a final report within 14 days of the fix being available.
This obligation applies to products already on the market — not just new releases.
December 11, 2027 — Full CRA application. From this date, no new products may be placed on the EU market without CE marking demonstrating CRA compliance. Products already in circulation have a transition period, but new production batches must comply fully.
Most manufacturers are focused on December 2027 and not thinking about September 2026. That is a mistake. If you already sell in the EU, the reporting obligation is fifteen months away. Building the internal process to detect, assess, and report vulnerabilities within 24 hours takes time — it is not something you can set up in a week.
What CRA actually requires: Annex I simplified
Annex I is the technical core of CRA. It has two parts. You can read the full requirements in the official regulation text.
Part 1 — What your product must do
No known exploitable vulnerabilities at release. Before your product ships, you are required to conduct a vulnerability assessment of all components, including open source libraries. Products cannot go to market with known, unpatched vulnerabilities.
Secure by default. Shared factory passwords (admin/admin, 1234, or blank) are prohibited. Every device must ship with secure default settings and must allow a full factory reset to a secure state.
Access control. Products must prevent unauthorised access through appropriate authentication and identity management. For connected devices, this means unique device credentials — not shared keys across a production batch.
Data protection. Encryption of data at rest and in transit. No plain-text transmission of credentials or sensitive data. TLS/DTLS for network communication is the baseline expectation.
Firmware and software integrity. Secure boot — verification that the firmware running on a device is authentic and unmodified — is the primary mechanism here. Without it, there is no guarantee the device is running what you shipped.
Minimal attack surface. Disable unused ports, services, and interfaces. Close debug interfaces (JTAG, UART) in production builds. Apply least privilege throughout the system.
Resilience. Basic device functions must remain available even after a cyberattack. Devices should fail safely rather than becoming attack vectors.
Security logging. Products must be able to record relevant security events — access attempts, configuration changes, anomalies. Users must have an opt-out option.
Secure data deletion. Users must be able to permanently and completely erase personal data and settings from the device.
Part 2 — What your organisation must do
Know your components. You must identify and document all software components in your product, including open source dependencies. This is the foundation of your SBOM.
Vulnerability management process. A published point of contact for vulnerability reports (e.g. security@yourdomain.com), an internal process for assessment, patching, and disclosure. This is Coordinated Vulnerability Disclosure (CVD).
Free security updates. Security patches must be distributed without delay and at no cost to the user. Monetising security updates is not permitted under CRA.
Signed and verified updates. Your update delivery mechanism must be secure end-to-end: signed firmware, integrity verification before installation, protection against rollback to vulnerable versions.
Post-release monitoring. After shipping, you are responsible for actively monitoring for new CVEs in your product's components and responding to them. This does not end when the product ships.
Declare a support period. You must publish how long your product will receive security updates before it goes to market. The support period must match the expected useful life of the device.
The documentation CRA requires
Most hardware manufacturers underestimate the documentation burden. CRA requires the following:
SBOM (Software Bill of Materials): A machine-readable inventory of every software component in your product — your own code, open source libraries, third-party modules — with version numbers and licences. Required formats are SPDX or CycloneDX. You do not need to publish it publicly, but you must provide it to market surveillance authorities on request.
Cybersecurity risk assessment: A formal threat model documenting potential attack vectors, assessed risks, and the security measures implemented to mitigate them. This must be kept current throughout the product lifecycle.
Technical documentation: Architecture documentation, security design decisions, test results, vulnerability management procedures. Stored for a minimum of 10 years after the product is placed on the market.
Declaration of Conformity (DoC): A signed document in which you take legal responsibility for the product's compliance with CRA. This is what enables CE marking.
For Default Products, all of this is prepared and signed internally. No Notified Body involvement is required.
What the penalties look like in practice
The penalty structure has three tiers:
| Violation | Maximum penalty |
|---|---|
| Non-compliance with core security requirements (Annex I) | €15 million or 2.5% of global annual turnover |
| Violations of other obligations — documentation, marking, reporting | €10 million or 2% of turnover |
| Providing false information to authorities | €5 million or 1% of turnover |
Beyond financial penalties, market surveillance authorities can order product withdrawals (stopping new sales) and product recalls (retrieving products already sold to customers). For a company with a large installed base, the cost of a recall significantly exceeds any fine.
Fines are calculated individually considering the severity of the violation, duration, intent, cooperation with authorities, and prior history.
Where most manufacturers actually stand today
In our work with IoT and hardware manufacturers, we see the same gaps repeatedly:
Device identity does not exist. All units in a production batch are identical internally — same firmware, same keys. There is no mechanism to distinguish one device from another.
OTA updates are unsigned. The device accepts any firmware file delivered through the update channel without verifying authenticity or integrity.
Provisioning happens at firmware flash time only. Security-relevant parameters are the same for every unit because they are baked into the firmware image.
Debug interfaces are open in production. JTAG or UART access that is acceptable in development remains accessible in shipped hardware.
There is no vulnerability disclosure process. No public contact, no internal workflow, no defined response time.
None of these problems are unsolvable. But they all require architectural decisions — and most of them cannot be reliably added to an existing product after the fact. Security architecture is not a feature you bolt on. It is a structural property of the system.
The manufacturers who will be ready by December 2027 are the ones starting that architectural work now.
Where to start
If you have not yet assessed your product against CRA requirements, the practical starting point is:
- Classify your product. Default, Important Class I, or Class II. This determines your compliance path and the urgency of getting a Notified Body involved.
- Run a gap analysis. Compare your current architecture against Annex I requirements point by point. Be specific — not "we have some encryption" but "we have TLS 1.3 for all backend communication, firmware is signed with ECDSA-P256, and device identity is hardware-bound per unit."
- Address the provisioning problem first. Unique device identity requires changes to your manufacturing process. This takes the most time to design and validate — start here.
- Start building your SBOM. You cannot manage vulnerabilities you cannot see. A complete, accurate SBOM is the foundation of everything that follows.
- Publish a security contact. A security@yourdomain.com address and a basic vulnerability disclosure policy takes an hour to set up. There is no reason to delay this.
FAQ
Does CRA apply to my company if we are not based in the EU? Yes. CRA applies to any product placed on the EU market, regardless of where the manufacturer is based. If your product is sold in EU countries, you must comply.
When does CRA fully apply? December 11, 2027 for product requirements. September 11, 2026 for vulnerability and incident reporting obligations.
Does my mobile app need to comply with CRA? If the app is integral to the operation of a connected hardware product, it is considered part of that product and subject to CRA. A standalone app without hardware dependency may fall under CRA's software scope depending on its function.
Do I need a third-party auditor? For Default Products (the majority), no. Self-assessment is sufficient. For Important Class II products, a Notified Body assessment is mandatory.
What is the minimum support period for firmware updates? CRA does not specify a minimum number of years. The support period must match the "expected useful life" of the product. For most consumer IoT devices, regulators and courts will likely interpret this as 5–10 years.
What happens if a vulnerability is found in my product after it ships? From September 2026, you must report actively exploited vulnerabilities to ENISA and your national CSIRT within 24 hours of discovery. You must also deliver a security update as quickly as possible, free of charge.
What does SBOM actually need to contain? At minimum, all top-level software dependencies with their version numbers, licences, and component identifiers. Machine-readable format (SPDX or CycloneDX). It does not need to be public but must be available to authorities on request.
Platanor Technologies designs and implements embedded security architecture for IoT and hardware manufacturers preparing for CRA compliance. If you are assessing where your product stands, we offer a technical consultation to review your current architecture and identify the gaps that matter most.