How the EU Cyber Resilience Act rewrites the rules of IoT security compliance — and the exact checklist indie developers need to ship legally into Europe

The EU Cyber Resilience Act is now law. Every connected device sold in the EU faces new security mandates by 2027. Here's what IoT developers must do now to comply.

Introduction

The EU Cyber Resilience Act isn't coming — it's already here. Passed into law in late 2024 and entering full enforcement by late 2027, the CRA is the most consequential piece of connected-device legislation since GDPR. And just like GDPR, most indie developers are going to be caught flat-footed.

If you're building a connected device — a smart sensor, an industrial gateway, a consumer wearable, a BLE peripheral — and you plan to sell it anywhere in the European Union, you are already on the clock. The CRA mandates secure-by-design architecture, mandatory vulnerability disclosure, software bills of materials, and long-term firmware lifecycle commitments that most solo founders and small hardware teams have never had to think about before.

This isn't bureaucratic noise. This is the new cost of market entry. And the developers who understand it now will outcompete the ones who get hit with a market ban in 2027.

Here's everything you need to know — in plain English.

What Is the EU Cyber Resilience Act? (The Non-Lawyer Version)

The EU Cyber Resilience Act (officially Regulation EU 2024/2847) is a horizontal cybersecurity regulation that applies to any product with a digital element — meaning any hardware or software that connects to a network or another device. It was designed to address one painful reality: most connected devices shipped today are chronically insecure, and manufacturers bear almost zero accountability for that.

The CRA changes the liability equation fundamentally. Under it:

  • Manufacturers must build security in before shipping, not patch it after breaches
  • Devices must receive security updates for their entire expected lifespan
  • Vulnerabilities must be reported to ENISA (the EU's cybersecurity agency) within 24 hours of discovery
  • A Software Bill of Materials (SBOM) must be maintained and, in many cases, made available
  • CE marking — required to sell in the EU — will now require CRA conformity

This applies to both hardware and the software embedded in it. It applies to commercial off-the-shelf products, custom-built devices, and open-source components when they're bundled into a commercial product. The enforcement window is phased:

RequirementDeadlineVulnerability handling obligationsSeptember 2026Full conformity (all requirements)December 2027Notified Body assessment (critical devices)December 2027

The fines are GDPR-tier: up to €15 million or 2.5% of global annual turnover, whichever is higher, for critical violations.

The 5 Device Categories Most Affected — and What Changes for Each

The CRA separates products into three risk tiers. The higher the risk, the stricter the conformity path.

1. Default Category Products (Most Indie Devices)

This covers the vast majority of connected consumer and commercial devices — smart home sensors, BLE peripherals, USB accessories, IoT edge nodes. These can self-certify via internal conformity assessment, but they still must meet all baseline CRA security requirements. For indie developers, this is both the good news (no mandatory third-party audit) and the trap (you still have to actually comply, you just self-assess).

What changes: You need documented evidence of your security architecture, a process for issuing patches, and an SBOM. Self-certification doesn't mean self-exemption.

2. Important Products — Class I

This includes network firewalls, VPNs, password managers, industrial control interfaces, and browser-based device management tools. These require involvement of a Notified Body or use of a harmonized EU standard during self-assessment.

What changes: Your compliance documentation needs external validation or alignment with EN standards like ETSI EN 303 645 or IEC 62443.

3. Important Products — Class II

Industrial IoT controllers, smart meter gateways, critical infrastructure components. Mandatory third-party assessment. No exceptions.

What changes: Budget for a Notified Body audit. This is not optional.

4. Critical Products

Hardware security modules, smart card chips, HSM-based root-of-trust devices. Subject to the most rigorous EU conformity schemes.

What changes: If you're building here, you likely already know the compliance landscape. If you're stumbling onto it now, pause before your next hardware revision.

5. Open Source Components in Commercial Products

This is the hidden trap. If you're pulling in open-source libraries, middleware, or SDKs into a commercial product, the CRA liability falls on you, the manufacturer — not the upstream maintainer. Free software maintained for non-commercial use is largely exempt, but the moment it's bundled into your commercial firmware image, it's your problem.

What changes: Every dependency in your firmware stack needs to be inventoried, monitored for CVEs, and updated in your maintenance schedule.

Why Default Passwords and Outdated Firmware Are Still the #1 Breach Vector in 2026 — and How to Fix It

You'd think we'd have solved this by now. We haven't. Default credentials remain the single most exploited attack surface across connected devices in 2025 and 2026. Malware families like Mirai and its descendants continue to compromise millions of devices by simply trying admin/admin at scale.

The CRA directly addresses this. Article 13 mandates that products must ship without default passwords that could be exploited if not changed, and where universal default passwords cannot be avoided, there must be a mechanism forcing change on first use.

What to do in your pipeline:

  1. Force unique credentials at provisioning. Generate device-specific credentials during manufacturing or first-boot setup. Never ship with hardcoded admin/password.
  2. Implement a firmware update channel before launch. You need OTA (over-the-air) update capability. If you're on constrained hardware, look at delta updates via Memfault or similar. The CRA's requirement to patch known vulnerabilities during the device's supported lifecycle makes OTA non-negotiable.
  3. Monitor your dependency CVE feed. Set up automated scanning. Tools like Grype, Trivy, or the SBOM-aware scanning in AWS Inspector will flag vulnerable components before your users find them via a breach.
  4. Version-lock and sign your firmware. Cryptographic signing of firmware images prevents supply chain attacks. Use secure boot where your MCU supports it (most ARM Cortex-M series do).
  5. Set and publish a clear support lifespan. The CRA requires you to define the expected product lifetime and commit to security updates for that period. For consumer devices, five years is emerging as the baseline expectation. Document it on your product page and in your technical documentation.

Software Bill of Materials (SBOM): What It Is and How to Generate One Automatically

An SBOM is essentially a manifest of every software component inside your product — third-party libraries, open-source packages, SDKs, firmware modules, and their versions. Think of it as a package.json for your entire device stack, but with legal weight.

Under the CRA, manufacturers must maintain an SBOM and, in many scenarios, make it accessible to market surveillance authorities on request.

Why It Matters Beyond Compliance

SBOMs have a practical security benefit: when a new CVE drops for a popular library (Log4Shell-style), you can instantly query your SBOM to know whether any of your deployed devices are affected. Without one, you're guessing.

How to Generate an SBOM Automatically

For firmware/embedded Linux projects:

  • Yocto-based builds: Use the built-in create-spdx class. It generates SPDX-format SBOMs natively during the build process.
  • Buildroot: Use legal-info target plus community tools like sbom-tool or syft for SPDX/CycloneDX output.
  • bare-metal MCU projects: Use syft pointed at your binary artifacts and dependency lockfiles. It's not perfect, but it covers declared dependencies.

For application-layer software on IoT gateways:

bash

# Install syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh
# Generate SBOM in CycloneDX format (preferred for EU compliance tooling)
syft your-firmware-image.img -o cyclonedx-json > sbom.json

Recommended SBOM format: CycloneDX 1.5 or SPDX 2.3. Both are accepted by EU tooling and enterprise procurement teams. CycloneDX has slightly better toolchain support for IoT.

Store your SBOM in version control alongside your firmware. When you release a new firmware version, generate and commit a new SBOM. This creates an auditable history that satisfies CRA Article 13 documentation requirements.

Firmware Lifecycle Management — The Hidden Cost Founders Ignore

Here's the conversation that kills hardware startups in year three: "We need to patch a critical CVE in the TLS stack. But we discontinued that product. Do we still have to push an update?"

Under the CRA: yes, probably. For the duration of the device's expected lifetime (which you published in your technical documentation), you are obligated to provide security updates.

This is the hidden cost that most indie founders never model in their unit economics. Let's be precise about what it actually involves:

The real costs of firmware lifecycle management:

  • OTA infrastructure: Hosting, bandwidth, and uptime for your update server. Self-hosted solutions (Mender, SWUpdate) have lower variable costs but require operational investment. Managed platforms (Memfault, Thistle Technologies) add per-device monthly fees but handle the complexity.
  • Regression testing per release: Every security patch needs a test cycle. On constrained hardware with no CI/CD for embedded, this is manual time. Budget 4–8 hours per patch release minimum.
  • Dependency monitoring: Automated CVE scanning (free tier options: OSV-Scanner, Dependabot for GitHub-hosted repos) to catch upstream vulnerabilities before they become your problem.
  • End-of-life planning: The CRA requires you to notify users before support ends and give them a migration path or final security update. Ignoring this creates both legal and reputational risk.

The practical solution for indie developers:

Adopt Memfault or a similar observability + OTA platform from day one, not as an afterthought. The per-device cost (typically $0.50–$2/device/year at indie scale) is far cheaper than the engineering time to build and maintain equivalent infrastructure yourself, and it gives you CRA-defensible evidence of your update cadence.

The 3-Step CRA Compliance Checklist for Indie Developers Shipping to EU

This is your minimum viable compliance path if you're a solo founder or small team without dedicated security engineering.

Step 1: Security Architecture Audit (Do This Now)

Work through this before your next hardware revision or firmware release:

  • No hardcoded default credentials; unique provisioning on first boot
  • Secure boot enabled (where hardware supports it)
  • All network communications encrypted (TLS 1.2+ minimum, TLS 1.3 preferred)
  • Attack surface documented (open ports, exposed APIs, physical interfaces)
  • Dependency lockfile exists and is version-controlled
  • SBOM generated and stored in version control

Step 2: Process and Documentation Setup (Do This Before September 2026)

  • Vulnerability disclosure policy published (a simple security.txt file on your domain satisfies baseline requirements)
  • CVE monitoring pipeline in place (OSV-Scanner + GitHub Actions or equivalent)
  • OTA update mechanism tested and operational
  • Expected product lifetime defined and documented in product technical documentation
  • Incident response procedure documented (even a one-page runbook counts for self-certification)

Step 3: Conformity Assessment and CE Marking Update (Complete Before December 2027)

  • Determine your risk class (default, Class I, Class II)
  • Compile your technical documentation file (required by Annex VII of the CRA)
  • Conduct self-assessment (default category) or engage Notified Body (Class I/II)
  • Issue updated EU Declaration of Conformity referencing CRA
  • Affix CE marking with CRA conformity

For standard consumer and commercial IoT devices in the default category, this entire checklist is achievable with 2–4 weeks of focused effort if your baseline security architecture is sound. The dangerous assumption is that "I'll deal with compliance later." September 2026 is the first hard deadline, and it's not far off.

Tools and Resources for CRA Compliance

SBOM Generation:

  • Syft — open source, supports most ecosystems
  • Microsoft SBOM Tool — good for mixed-stack projects
  • Yocto create-spdx class — native for embedded Linux builds

Vulnerability Scanning:

  • Grype — pairs with Syft for SBOM-driven CVE scanning
  • OSV-Scanner — Google's open-source scanner, excellent free option

OTA and Device Observability:

  • Memfault — full lifecycle management, crash reporting, OTA; best-in-class for indie scale (affiliate)
  • Thistle Technologies — security-focused OTA for Linux-based IoT (affiliate)
  • Mender.io — self-hostable open-source OTA; good for budget-constrained teams

Enterprise Device Management (for readers at scale):

Official CRA Documentation:

FAQ — People Also Ask

Does the EU Cyber Resilience Act apply to open-source projects?

Partially. Open-source software developed and distributed for non-commercial purposes is largely exempt from CRA obligations. However, if you take an open-source component and bundle it into a commercial product — a device you sell — you as the manufacturer inherit CRA obligations for that component. The open-source maintainer does not. This means indie developers cannot use open-source licensing as a compliance shield; they must treat every dependency as their responsibility.

What is the penalty for not complying with the EU Cyber Resilience Act?

Non-compliance fines under the CRA follow a tiered structure. The most serious violations — products with critical security deficiencies — can attract fines up to €15 million or 2.5% of global annual turnover, whichever is higher. Administrative non-conformities (documentation failures, CE marking issues) carry fines up to €10 million or 2% of turnover. Authorities also have the power to require product recalls or market withdrawal, which is existentially damaging for hardware businesses.

Do I need a third-party audit to comply with the CRA as an indie developer?

Not necessarily. The majority of IoT products fall into the "default" category, which allows self-certification via internal conformity assessment. You document your security architecture, generate an SBOM, implement the required security processes, and issue a Declaration of Conformity yourself. Only Class I Important Products (requiring harmonized standard alignment) and Class II Important Products (mandatory Notified Body audit) need external assessment. Check the product classification in Annex III of the regulation against your device's function.

When does the EU Cyber Resilience Act take full effect?

The CRA entered into force in December 2024. Vulnerability handling obligations — the requirement to report actively exploited vulnerabilities to ENISA within 24 hours — apply from September 11, 2026. Full conformity requirements, including the CE marking update, apply from December 11, 2027. This phased rollout gives developers runway, but the vulnerability reporting obligation is the earliest hard deadline and requires technical infrastructure to be operational before it hits.

Conclusion

The EU Cyber Resilience Act is not optional, it is not far away, and it is not just for enterprises. If you are shipping a connected device into European markets — even as an indie developer, even as a hardware startup with a three-person team — the CRA applies to you.

The good news: the compliance path for most IoT products is achievable without a legal team or a Fortune 500 security budget. It requires discipline, not resources. Unique credentials at provisioning. OTA update infrastructure. An SBOM generated automatically at build time. A documented support lifespan. A vulnerability disclosure policy. These are not moonshot engineering projects — they are engineering practices that make your product better regardless of regulation.

The developers who build these habits into their pipelines now will ship faster, retain EU market access, and earn the trust of enterprise buyers who are increasingly demanding CRA-aligned supply chains. The developers who wait will face either a scramble in late 2027 or a quiet exit from the EU market.

Start with the three-step checklist above. Pick one item, do it this week, and build from there. The deadline is real — but it's also survivable if you start now.

👇 Are you already building to CRA requirements, or is this the first time you're thinking about it? Drop your biggest compliance question in the comments — I'll answer every one..