If you make a connected device and sell it in the EU, the Cyber Resilience Act (CRA) applies to you. Full stop. It does not matter where you manufacture, where your company is registered, or whether you have a European office.
The regulation entered into force on 10 December 2024. Most teams have 2027 circled as the deadline and have not moved yet. The problem is that 2027 is the final enforcement date, not the only one. The first hard deadline is 11 September 2026, when mandatory vulnerability reporting kicks in. You cannot build the processes that reporting requires in a sprint. You need them running months before the deadline so you have the operational evidence to show authorities when they ask.
This guide covers what you actually need to do, in the order you need to do it.
Is your product in scope?
The CRA applies to any hardware or software that connects, directly or indirectly, to a device or network, placed on the EU market in a commercial context.
Your smart sensor, industrial gateway, firmware updater, and the embedded OS on your thermostat are all covered. The test is simple: if it ships to the EU and it connects to anything, it is in scope.
What is excluded:
- Medical devices and motor vehicles (covered by their own sector regulations)
- Non-monetized open source software
- Pure SaaS and PaaS that is not integral to an in-scope device’s function
- Websites that do not support remote processing for an in-scope device
If you are an importer or distributor rather than the original manufacturer, you still have obligations. You may need to verify CE marking, retain documentation, and in some cases take on full manufacturer responsibilities if you substantially modify the product before placing it on the market.
One more thing many teams miss: the Radio Equipment Directive (RED) cybersecurity requirements already applied from 1 August 2025 for internet-connected radio equipment. If your device uses Wi-Fi or Bluetooth and the August 2025 deadline has passed without a RED assessment, address that before anything else. The RED list is shorter than CRA but it is already past due.
Step 1: Classify your product
The CRA sorts products into four risk categories. Your category determines how you prove compliance.
Default (about 90% of all products) Standard connected devices, most consumer IoT, lower-risk industrial sensors. Self-assessment is allowed. You evaluate your own product against the essential requirements and sign a Declaration of Conformity.
Important: Class I Higher-risk products including browsers, password managers, VPNs, and network management software. Self-certification against a harmonized standard is allowed, or you can use a notified body.
Important: Class II Products with significant security risk: industrial firewalls, intrusion detection systems, microprocessors, routers, modems, smart meter gateways. Third-party assessment by a notified body is required in most cases.
Critical Products that critical infrastructure depends on. Requires a European cybersecurity certification scheme. The implementing regulation adopted in November 2025 clarified which products land here.
Check Annex III and Annex IV of Regulation (EU) 2024/2847 for the definitive lists.
One practical problem with Class II and Critical: notified body capacity in the EU is limited. Teams that wait until late 2026 or 2027 to start will face queues. The European Commission’s target is to have notified bodies in place by 11 December 2026, but availability may not match demand. Start early.
Step 2: Build your Software Bill of Materials now
The SBOM requirement is in Annex I, Part II of the CRA. Manufacturers must identify and document all components in their products, including a software bill of materials in a commonly used, machine-readable format covering at minimum top-level dependencies.
The reason to do this before September 2026 is operational, not bureaucratic. When an actively exploited vulnerability is disclosed publicly, you have 24 hours to report to ENISA and your national CSIRT. To meet that deadline, you need to know within minutes whether your product uses the affected component. Without an SBOM and automated vulnerability tracking, you will spend those 24 hours digging through firmware images manually.
What your SBOM needs to cover:
- Every software component from OS to firmware modules
- Both proprietary and open-source components
- Version numbers and licensing information
- Known vulnerabilities mapped to each component
- Top-level dependencies at minimum; full transitive dependency tracking where practical
The CRA does not yet mandate a specific format, but requires “commonly used, machine-readable.” Both SPDX and CycloneDX satisfy this. The European Commission is expected to specify formats via implementing acts in 2026. Pick one now and build it into your CI/CD pipeline.
You do not need to publish your SBOM. Market surveillance authorities can request it, and you must be able to provide it promptly. Keep it in your technical documentation file.
For devices that receive OTA updates, the SBOM process needs to stay current. Every firmware release that adds or updates a component requires an updated SBOM before it ships.
Step 3: Build security in from the start
Most IoT teams have the most ground to cover here. The CRA requires security by design, not security bolted on before a CE marking audit.
At design time:
- No default passwords. Devices must ship either requiring the user to set a unique credential or using hardware-unique credentials generated per device.
- Minimize attack surface. Limit exposed interfaces, services, and ports to what the product actually needs to function.
- Threat modeling before hardware bring-up, not after.
- Secure boot to verify firmware integrity from power-on.
- Encrypt data in transit and at rest where the product’s threat model warrants it.
During development:
- Secure Software Development Lifecycle (SSDL) with security gates at code review, static analysis, and dependency scanning integrated into CI/CD.
- No known critical or high-severity vulnerabilities in components at time of release. The CRA requires products to be placed on the market “without known exploitable vulnerabilities.”
- Test against your own threat model before you ship.
Post-market:
- Security updates must be available to users for at least 5 years from product placement on the market, or the expected usage period if longer.
- Once a security update is released, it must remain available for at least 10 years from that release date, or the remaining support period.
- Automatic update mechanisms, or clear notification to users when updates are available.
- A published end-of-support date so users know when patches will stop.
Step 4: Set up vulnerability handling and incident reporting
This is the September 2026 deadline. From 11 September 2026, manufacturers must report to ENISA and the relevant national CSIRT within 24 hours of discovering an actively exploited vulnerability in any product currently on the EU market.
The reporting timeline:
| Trigger | Deadline | What to submit |
|---|---|---|
| Actively exploited vulnerability discovered | 24 hours | Early warning to ENISA and national CSIRT |
| Severe cybersecurity incident affecting product security | 24 hours | Early warning notification |
| Following the early warning | 72 hours | Vulnerability notification with initial impact assessment |
| Once mitigation is available | 14 days | Full report: description, affected versions, mitigation steps |
This covers legacy products. If you shipped an IoT gateway in 2019 and it is still on the EU market on 11 September 2026, you are responsible for reporting vulnerabilities in it under these timelines.
Reports go to ENISA’s European vulnerability database and the national CSIRT of the member state(s) where the product is sold. They are typically forwarded to CSIRTs in every member state where the product is marketed.
What you need in place before September 2026:
- A coordinated vulnerability disclosure (CVD) policy, published and findable
- A monitored security contact and a security.txt file
- Internal triage workflows with clear ownership and escalation paths
- SBOM and dependency tracking so you can answer “are we affected?” in hours, not days
- A working relationship with your national CSIRT before you need to call them
Step 5: Prepare your technical documentation
Every manufacturer must maintain a technical documentation file. Market surveillance authorities can request it at any time. The content requirements are in Annex VII of the CRA.
Your technical file must include:
- Product description: name, version, type, serial range
- Risk assessment: your cybersecurity threat model and how your design choices address it
- Security architecture: how the product satisfies the essential requirements
- SBOM
- Secure development process description: coding standards, review process, testing methodology
- Vulnerability handling procedure
- Testing and verification results
- Declaration of Conformity reference
Retain the documentation for 10 years after the product leaves the market. Update it when you issue security updates.
Step 6: Get CE marking right
CE marking under the CRA is not the same as CE marking under older directives. You cannot self-declare compliance and apply a CE mark on a Class II product.
For default category products: self-assessment is allowed. Complete the conformity assessment, produce a Declaration of Conformity, apply the CE mark.
For Class I important products: self-certify against a harmonized standard, or use a notified body.
For Class II important and critical products: notified body assessment is required in most cases.
Your Declaration of Conformity must include:
- Product identification (name, type, batch, serial number)
- Manufacturer name and address
- Statement of conformity with Regulation (EU) 2024/2847
- Notified body name and number, if applicable
- Authorized signatory details
The CE mark must appear on the product, its packaging, or the accompanying documentation if the product is too small to carry it.
What trips up most teams
Treating it as a one-time checkbox. The CRA requires ongoing processes. Vulnerability monitoring, SBOM updates, and incident reporting run continuously for as long as your product is on the market.
Ignoring products already shipped. If it is still on sale in the EU on 11 September 2026, it is in scope for vulnerability reporting. That includes products from 2019.
Underestimating SBOM scope. A typical firmware image contains dozens or hundreds of components. Manual inventory does not scale. Automate SBOM generation into your build pipeline from the start.
Missing supply chain obligations. Third-party components carry risk that flows to you as the manufacturer. Your supplier contracts need SBOM obligations and vulnerability disclosure terms. A vulnerability in a library your chip vendor ships is still your reporting responsibility.
Assuming harmonized standards will arrive in time. CEN/CENELEC standardization for CRA is in progress. For products requiring third-party assessment, standards may still be incomplete when you need to certify. Engage a notified body early to agree on what evidence they will accept in the interim.
A note on your IoT platform
One question that comes up often: does the cloud platform your device connects to affect your CRA compliance?
If you use a general-purpose IoT platform that is not developed by you or on your behalf, it does not fall under CRA directly. Pure SaaS and PaaS are excluded from the regulation. What matters for your CRA technical file is that you document the platform as part of your supply chain, understand the security controls it applies, and have evidence you can present to market surveillance authorities.
When evaluating platforms, look for documented encryption at rest and in transit, access controls, audit logging, published vulnerability disclosure processes, and third-party security validation. ISO/IEC 27001 certification, independent security scores, and a published security portal with available documentation are the things to ask for. Platforms that cannot produce this evidence quickly will slow down your CRA documentation process.
TagoIO maintains ISO/IEC 27001 certification, GDPR compliance, and a public Security Portal at security.tago.io with audit reports, security self-assessments, and full documentation available on request. If you use TagoIO as part of your device’s data pipeline, the security documentation you need for your supply chain assessment is there.
Timeline
| Date | Milestone |
|---|---|
| 10 December 2024 | CRA entered into force |
| 1 August 2025 | RED cybersecurity requirements apply to internet-connected radio equipment |
| 11 June 2026 | Conformity assessment body notifications must be in place |
| 11 September 2026 | Vulnerability and incident reporting obligations begin |
| 11 December 2027 | All CRA requirements fully enforceable |
Resources
- Regulation (EU) 2024/2847: the CRA text. Start with Annex I (security requirements), Annex III/IV (product categories), Annex VII (technical documentation).
- ENISA CRA guidance: enisa.europa.eu
- IoT Security Foundation: compliance resources and ENISA standards mapping at iotsecurityfoundation.org
- ETSI EN 303 645: the existing consumer IoT security standard, heavily aligned with CRA Annex I requirements
- European Commission CRA guidance: published for feedback in March 2026, covers scope interpretation and SME support
This article reflects the state of the CRA as of April 2026. Implementing acts and harmonized standards are still being finalized. Check the European Commission’s digital strategy pages for updates. Regulation (EU) 2024/2847 is the authoritative source.
