What it takes to be CRA compliant?
You're no longer shipping a product. You're committing to maintaining it for the next 5-10 years.The CRA turns cybersecurity from a feature into a legal liability. Here's what that means for your product, your organisation and your business model.
The CRA in one paragraph
The Cyber Resilience Act (Regulation 2024/2847) makes cybersecurity a legal requirement for every product with a digital element sold in the EU. Hardware, software, IoT - if it has a data connection and you sell it in Europe, the CRA applies. Full compliance by December 2027. Vulnerability reporting by September 2026. Fines up to EUR 15 million or 2.5% of global turnover.
That's the stick. The rest of this article is the roadmap.
What the CRA actually changes
Before the CRA, cybersecurity was a competitive advantage. After it, cybersecurity is a market access requirement. That difference reshapes three things:
Product lifecycle cost
Every connected product now carries a minimum 5-year security maintenance tail. For IoT, this means OTA update infrastructure, vulnerability monitoring, patch testing, and deployment not as a nice-to-have, but as a legal obligation. If you sell a EUR 50 sensor and need to maintain its security for 5 years, that changes your unit economics fundamentally. The product you ship on day one is the beginning of a cost obligation, not the end.
Time to market
Security requirements, threat modelling, and documentation move from "before launch" to "before design." Your first sprint now includes security architecture, not your last. For IoT teams used to shipping fast and patching later that's a culture shift. Conformity assessment (self or third-party) adds time before you can CE-mark and sell. For Class II products, third-party assessment means weeks to months of lead time with a notified body.
Barrier to entry
Small teams shipping a connected device on a shoestring? The CRA raises the floor. You need a vulnerability handling process, a published disclosure policy, an SBOM, update infrastructure, and a technical file before your first customer. This isn't impossible for SMEs (EN 303 645 was designed to be achievable), but it's no longer optional. The garage-to-market path now has a compliance checkpoint.
Three pillars of CRA compliance
Most teams focus on the product. That's pillar one. But the CRA demands three things working together:
- Product secure by design, tested, documented
- Organisation capable of handling vulnerabilities, managing suppliers, maintaining security
- Processes continuous, not one-off. The hard part isn't getting compliant. It's staying compliant.
Miss any one and you're not compliant.
Pillar 1 - product
The non-negotiables
Every connected product must meet all of these. No partial compliance.
Secure defaults - No default passwords. Unused interfaces disabled. Minimal attack surface out of the box. For IoT, this means every device in a fleet of thousands ships with a unique credential. Provisioning at scale becomes a security requirement, not just a manufacturing convenience.
Encryption - Data encrypted at rest and in transit. For IoT, this includes telemetry from sensors, commands to actuators, and firmware update payloads. "It's just temperature data" is not an excuse — if the channel can be hijacked to push malicious firmware, the data doesn't matter.
Access control - Authentication on every interface. For IoT, this means device-to-cloud, device-to-device, and local debug ports. A forgotten UART console with root access fails this requirement.
Software integrity - Secure boot. Firmware verified before execution. For IoT devices with constrained hardware, this needs to be designed into the silicon choice, not bolted on later.
Resilience and minimisation - Withstand DoS attacks. Minimise impact on neighbouring devices if compromised. Collect only data relevant to product purpose. For IoT fleets, one compromised device must not become a pivot point to the rest of the network.
Which standard proves it?
Your assesment path
Pillar 2 - organisation
The CRA asks: "Is this manufacturer capable of keeping the product secure over its lifetime?"
Vulnerability handling
You need a defined security owner. Not "the dev team will handle it." A person or team who owns the process end-to-end:
- Published vulnerability disclosure policy with a public contact point and safe harbour for reporters
- Intake, triage, and severity classification workflow
- Ability to produce and distribute patches
For IoT, this means patching at fleet scale. When a vulnerability hits, can you push an update to 10,000 devices in the field? 100,000? Do you know which devices are running which firmware version? Device fleet management becomes critical - not for features, but for security compliance.
Reporting to authorities (from September 2026)
Actively exploited vulnerability discovered:
- 24 hours to notify CSIRT (Computer Security Incident Response Team each contry has separate)
- 72 hours detailed notification
- 14 days final report with root cause.
For IoT, "actively exploited" could mean a botnet leveraging your devices. The clock starts when you become aware. You need monitoring to detect it, templates to report it, and contacts to reach.
SBOM and dependency tracking
Complete inventory of every component: open-source libraries, third-party modules, internal code. Machine-readable (SPDX or CycloneDX). Ready on request.
For IoT, this goes deeper than typical software. Your SBOM includes the RTOS, the network stack, the crypto library, the bootloader, the radio firmware. A vulnerability in a TLS library embedded in your Zigbee module's firmware is your problem. You need to know it's there, track it, and be ready to update it.
You're responsible for every component, including open-source. Vet dependencies. Monitor upstream vulnerabilities. Report bugs you find back to maintainers.
Technical documentation
Your compliance file:
- Product description and user instructions
- System architecture - how components integrate
- Vulnerability handling processes, SBOM, disclosure policy, update mechanism
- Cybersecurity risk assessment (threat modelling - not optional)
- Support period justification
- Standards applied and how they map to Annex I
- Test reports
- EU Declaration of Conformity
Maintained for 10 years. For IoT products with 5-year support periods, that means documentation lives for 15 years from first sale.
Organisation standards
The CRA doesn't mandate ISO 27001. But customers will.
NIS2-covered buyers (energy, health, transport, manufacturing) must verify supply chain security. ISO/IEC 27001 certification or documented alignment is the shortcut to that conversation. Not legally required by CRA, but increasingly a contractual gate.
Pillar 3 - processes (the hard part)
Getting compliant is a project. Staying compliant is an operation. This is where the CRA hits hardest especially for IoT.
The update lifecycle
Minimum 5 years of vulnerability handling from date of market placement. Security updates available for at least 10 years Free. Separate from feature updates where feasible. Automatic updates preferred, enabled by default.
For IoT, 5 years of security updates means:
- Update infrastructure that outlives your product team. The engineers who built v1.0 may have moved on by year 3. Your update pipeline, test automation, and deployment tooling need to work without tribal knowledge. For constrained IoT devices, OTA updates need to handle unreliable connectivity, partial downloads, rollback on failure, and signature verification all designed in from day one.
- Version management across a fragmented fleet. Devices in the field won't all be on the same firmware. Some will miss updates. Some will be offline for months. You need to know which versions are deployed, which are vulnerable, and which devices haven't phoned home. For IoT, this isn't a nice dashboard it's a compliance requirement.
- Testing at scale. Every security patch needs testing before deployment not just on the bench, but against the diversity of your fleet. Different hardware revisions, different configurations, different field conditions. A patch that bricks 1% of devices is worse than the vulnerability it fixes.
- Budget reality. If you sell 50,000 sensors at EUR 30 each, and maintaining security costs EUR 2/device/year, that's EUR 500,000 over 5 years. Did your pricing account for that? The CRA means your cost model must include post-sale security operations. Every product in your portfolio. Every year of the support period.
Post-market monitoring
Active, continuous monitoring for vulnerabilities in your code, in your dependencies, and in the components you integrated. This isn't a quarterly review. For IoT, new CVEs in embedded libraries (mbedTLS, lwIP, FreeRTOS components) can drop any day.
If you discover a vulnerability that means your product no longer meets Annex I, you must take corrective action or withdraw the product from the market. For IoT fleets, "corrective action" means pushing an update to every affected device. If you can't reach them, you have a compliance problem that grows with every unreachable unit.
Dependency tracking as a continuous process
Your product's security depends on its weakest component. That Zigbee stack you integrated two years ago? The MQTT library pinned to a version from 2024? The bootloader binary from your silicon vendor?
For IoT, dependency tracking is harder than for cloud software. Components are often binary blobs from third parties. Update cycles are slower. Hardware constraints limit what you can patch. You need:
- Automated SBOM generation on every build
- Continuous vulnerability scanning against known CVE databases
- Alerts when upstream dependencies disclose vulnerabilities
- A process for evaluating, patching, testing, and deploying not once, but for every CVE, for every product, for the entire support period
CE marking is a continuous claim
The Declaration of Conformity is a legal statement: "this product meets all CRA requirements." If that stops being true a critical vulnerability, an expired crypto algorithm, a component end-of-life you must act. CE marking isn't a one-time stamp. It's a promise you're making every day the product is on the market.
For IoT manufacturers, this means your compliance posture is only as good as your last update. A fleet of devices with a known unpatched vulnerability is a fleet of non-compliant products. Legally.
The timeline
The real cost
The CRA isn't expensive if you build it in. It's extremely expensive if you bolt it on.
Building it in:
- Security requirements in sprint one
- SBOM generated automatically in CI/CD
- OTA update infrastructure designed alongside the product
- Fleet management that tracks versions, connectivity, and patch status
- Support period budgeted in unit economics from day zero
- Vulnerability monitoring running before the first device ships
Patching it :
- Scrambling to document architecture nobody wrote down
- Generating an SBOM for a product with binary blobs and untracked dependencies
- Retrofitting OTA updates onto devices that were designed for flash-once-and-forget
- Discovering your EUR 30 sensor needs a 5-year maintenance operation you never budgeted for
- Building fleet management to track 50,000 devices you've never needed to reach before
The CRA doesn't change what good IoT engineering looks like. It makes it non-negotiable. The teams already doing it right will barely notice the deadline. The rest will feel every month of it.
Further reading
CRA full text (Regulation 2024/2847)
NIS2 full text (Regulation 2022/2555)
As a Chief Information Officer with over a decade of experience as a C# developer, I approach my work with a passion for technology and a belief that the best solutions come from understanding diverse perspectives. This mindset shapes how I lead—whether in my career, family, or personal life—balancing innovation with practicality. My wife and two kids inspire everything I do, guiding me to create harmony and meaningful outcomes by blending different ideas with empathy and insight.
Rapidly adapt our competences into your IoT solution
Contact us and share your challenges
