CRA compliance for IoT startups: a practical guide

If you build connected hardware — sensors, trackers, gateways, smart devices of any kind — the EU Cyber Resilience Act applies to you. Not "probably", not "if you're big enough": any product with digital elements sold commercially in the EU is in scope, and IoT devices are the regulation's central use case. The question for a startup is not whether, but how to comply without a compliance department.

This guide is the realistic version for a team of two to twenty people.

Want your product's exact classification and deadlines first? Run the free 3-minute scope check.

The good news first: you're almost certainly default class

The CRA sorts products into risk classes, and the class determines how expensive compliance gets. The heavier classes (Important I/II, Critical) are for products whose core function is security: VPNs, firewalls, smart locks, security cameras, hardware security modules. A typical IoT product — environmental sensor, asset tracker, agricultural monitor, smart meter reader, industrial gateway without security functions — lands in the default class.

Default class means self-assessment: no notified body, no external certification, no waiting lists. You do the work, document it, sign the EU Declaration of Conformity yourself, and affix the CE marking. For a startup this is the difference between a manageable internal project and a five-figure external one.

Two caveats: smart home devices with security claims (locks, cameras, alarm-adjacent products) and anything doing network monitoring tip into Class I — and your cloud backend counts as part of the product if the device depends on it (the CRA calls this remote data processing). Check your specific case rather than assuming.

Your two deadlines

• 11 September 2026 — the reporting obligation: actively exploited vulnerabilities and severe incidents must be notified to ENISA within 24 hours (early warning) and 72 hours (full notification). This applies to devices already in the field, not just new launches.
• 11 December 2027 — full compliance for products placed on the market from that date: security by design, SBOM, technical documentation, CE marking. If you're launching or substantially updating in 2028, this is your bar; if you're shipping today, September is.

The 24-hour window is the one that catches startups. It's not a form you fill in when something happens — it's a capability you need in advance: knowing what's in your firmware, monitoring it, and having decided who files what. Our deadlines guide breaks down the exact sequence.

The firmware SBOM problem (and the honest solution)

The CRA requires a Software Bill of Materials covering your product's top-level dependencies. For a cloud service this is trivial — export the lockfile. For firmware it's genuinely annoying: components are vendored, copied, patched, and nothing declares them.

The realistic approach for a small team:

1. If you build on Zephyr or Yocto: use their native SPDX/manifest support — you're mostly done.
2. If you build on bare metal, an RTOS, or vendor SDKs: make a manual inventory. Every third-party piece — RTOS, TCP/IP stack, TLS library, bootloader, chip-vendor SDK, any Arduino/community library — with its version. This is an afternoon of honest archaeology, and it is acceptable: the regulation asks for top-level dependencies, not a binary-level forensic scan.
3. Patched libraries: list your patched version as the component and reference the upstream original it's based on — you need to know when a CVE against the original applies to you.
4. Convert the list to CycloneDX (the standard machine-readable format) and regenerate it every release.

The SBOM is not paperwork for its own sake — it's the input for the next step. Full walkthrough in our SBOM guide.

Monitoring: the part that runs forever

Once you know your components, you match them against public vulnerability databases (OSV, NVD) on a schedule. A new CVE in your TLS library should surface as an alert, not as a customer email six months later. This is also what makes the 24-hour reporting duty survivable: when a vulnerability is reported as actively exploited, you can answer "does this affect us?" in minutes instead of days.

For a startup the practical setup is: SBOM per firmware release, automated daily matching, and a triage habit — assess, fix or accept, record the decision. An hour a week once it runs.

The five-person compliance plan

1. Week 1: determine scope and class (three minutes with the checker, or read the regulation's Annex III), assign one owner for CRA — not a committee, a name.
2. Week 2: build the SBOM (inventory + CycloneDX), start automated vulnerability matching.
3. Week 3: write the one-page reporting playbook — who assesses, who decides, who files with ENISA and your national CSIRT, within which hours — and publish a security contact (security@ address + a short disclosure policy page).
4. Week 4: run the security risk assessment: list interfaces (radio, network, physical ports, cloud API), threats per interface, mitigations or accepted risks. Document it.
5. Ongoing: regenerate the SBOM every release, triage findings weekly, keep the documentation current. Before December 2027 (or your next launch): assemble the Annex VII technical file and Declaration of Conformity from what you've already built.

None of this requires hiring. It requires doing it before the deadline forces you to do it badly.

What it costs if you don't

Market surveillance authorities can demand documentation, force product recalls, and fine up to €15 million or 2.5% of worldwide turnover. But for a startup the sharper risk is commercial: distributors and enterprise customers are already asking for SBOMs and CE conformity as purchasing conditions. After December 2027, no CE marking under the CRA means no legal EU sales — and your compliant competitor takes the deal.

Start with the three-minute version: check your product's class and deadlines — no signup, based on the regulation text.