Security Is the Product Now: What the Cyber Resilience Act Means for Device Makers

If you make anything with a chip and a network connection — a heat-pump controller, a baby monitor, an industrial sensor, a smart doorbell — a deadline is approaching that will change how your product legally gets to exist on the EU market. The Cyber Resilience Act entered into force in late 2024, its main obligations phase in through 2026–2027, and its core message is uncomfortable for anyone who has treated product security as “the firmware team’s problem”: security defects become product defects, with market-withdrawal powers and fines scaled to global turnover.

The good news buried in the regulation: nobody is starting from zero. The consumer-IoT baseline standard EN 303 645 has spent years teaching what “secure by design” concretely means for devices, national secure-development guides have matured, and the CRA largely formalises and generalises that discipline rather than inventing it. This article is the practical map: what the CRA actually requires of a device maker, how EN 303 645 and secure-development practice get you most of the way, what the radio-equipment directive alignment means, and the workflow to become — and stay — CRA-ready without drowning.

What the CRA Requires (Decoded for Makers)

The CRA covers “products with digital elements” — in practice, anything with software or connectivity sold into the EU, with focuses rendered slightly differently by criticality class. The essential requirements reduce to a security lifecycle you must be able to demonstrate:

1. Design from a risk-assessed baseline. Threat model the product (attacker classes: remote network attacker, adjacent network attacker, physical attacker with the device in hand, privileged local attacker), and design out the avoidable classes. “We didn’t think about it” stops being an available answer.
2. Secure-by-default configuration. No universal default passwords (the classic admin/admin), credentials that force change on first use or are per-device unique, minimal exposed services, documentation defaults hardened.
3. Vulnerability handling as a business process. A public disclosure/coordinated-vulnerability-disclosure policy, a channel that receives reports, triage SLAs, and a documented process for producing fixes for vulnerabilities classified as severe — for the whole support period.
4. Update delivery obligation with published timelines. Security updates for the declared support period (“expected duration”), delivered reliably (signed, verifiable, ideally automatic), described in transparent release notes, and free for security fixes.
5. SBOM and dependency discipline. Maintain a software bill of materials so a third-party component crisis (the next Log4Shell-in-a-library) is answerable with a query, not a panic archaeology project.
6. Secure development practice evidence. Documented secure-development process — code review, testing, build integrity — because conformity assessment (self-assessment for most classes, third-party for critical ones) inspects the process, not only the shipped binary.
7. Post-market surveillance. Monitor in-the-field security performance (crash reports, exploit chatter, researcher reports), and report actively-exploited severe vulnerabilities and incidents to the EU’s CSIRT network on regulatory timelines.
8. CE marking and Declaration of Conformity. The visible market gate: product complies with the CRA’s essential requirements, per the conformity-assessment route applicable to its class.

Two dates matter most: reporting duties and the full applicability regime phase in across 2026–2027 (vulnerability-reporting obligations first, then the main requirements apply to products placed on the market). Products already on the market when applicability hits are not grandfathered into forever — the update/vulnerability obligations attach to the support period you declared. If you ship hardware with a 10-year support promise, you bought a 10-year security obligation.

How EN 303 645 maps onto the CRA

The consumer-IoT baseline standard’s headline provisions read like a CRA preview — because they are:

If your product already genuinely conforms to EN 303 645 and you run a real disclosure process, you are — roughly — most of the way to the CRA’s baseline for a non-critical product. The remaining distance is mostly documentation, declaration, and the post-market duties that consumer standards never enforced.

The Secure Development Workflow That Satisfies Both

Phase 1: Design — threat model on paper, signed

For each product family, maintain a living threat model: asset inventory (credentials, user data, control functions), trust boundaries (cloud, radio, local UI, physical debug ports), and the attacker classes at each boundary. Derive requirements from it (secure boot? signed OTA? encrypted transport? debug-port lockout in production?) and record the decisions. The threat model is the artefact an assessor will ask for first, because everything downstream claims to trace from it.

Phase 2: Development — process with receipts

• Coding standards with banned-API lists for the memory-unsafe corners where feasible; static analysis in CI with a triaged (not zero) finding policy.
• Dependency control: pinned, hash-verified, SBOM generated at build (SPDX or CycloneDX); licence compliance checked in the same pass, because an SBOM discovery that kills shipping is a schedule event you want pre-build.
• Build integrity: reproducible-ish builds, signed artifacts, a release pipeline a compliance auditor can walk through without you in the room.
• Secrets hygiene: no keys in firmware images; per-device key provisioning at manufacturing or first boot instead.

Phase 3: Testing — prove the threat model holds

Manual plus automated: fuzz the parsers (radio protocols, config import, cloud API), pen-test the attack surface the threat model declared valuable, verify the update mechanism end-to-end (signature rejection, rollback resistance, power-loss mid-update behaviour — the field will find every corner you didn’t). Third-party testing pays for itself here for anything safety-adjacent (see the heat-pump maker case: connected heating controllers discovered to be internet-exposed with unauthenticated control — precisely the class that made regulators legislate).

Phase 4: Disclosure and updates — the marathon obligations

• A real security.txt/disclosure page, a monitored inbox, and coordinated-disclosure SLAs you actually meet (researchers talk; a silent vendor is a reputational fuse already lit).
• PSIRT-lite process: triage severity with CVSS-plus-exploitability, fix and release within the SLA your policy declares, and credit researchers who want it.
• Update engineering as product feature: signed delta OTA, staged rollouts with kill-switch telemetry, version transparency (a public end-of-support calendar per product), and update notes that say what was fixed, not “stability improvements.”
• Post-market listening: monitor for your product names in exploit chatter, breach databases of credentials shipped with devices (default-password lists are a genre), and crash/anomaly telemetry where consented.

Phase 5: The paperwork that becomes the product’s passport

Technical documentation file: threat model, requirements traceability, test reports, SBOM, vulnerability-handling records, risk assessment. EU Declaration of Conformity, CE marking, and — for the classes where third-party assessment applies (critical products list) — notified-body engagement early enough to matter. The file is not a drawer document; market-surveillance authorities can request it, and its absence is non-conformity.

Special Case: The Radio Equipment Directive Alignment

If your device has radiocommunication (Wi-Fi, BLE, LoRa, cellular…), the RED delegated act on cybersecurity (applicable since mid-2025) front-runs parts of the CRA for radio products: the CE route through RED requires assessing cyber-security provisions (EN 18031series harmonised standards) even before the CRA fully applies. Practically: for radio devices, cyber conformity assessment work needed to happen already; the CRA then supersedes/overlaps. Makers who discover this in 2026 discover they are late twice.

Realistic FAQ from Actual Makers

“We’re a 15-person company. Does this really apply to us?”

Yes — SMEs get guidance support and proportionate documentation expectations, but not exemption. The engineering substance (no default passwords, updates, disclosure channel) is reachable for a small firmware team; the real risk is treating it as a certification project instead of product practice. Start with EN 303 645’s 13 provisions as the worklist, then layer the documentation.

“We don’t sell direct to the EU — are we caught?”

Importers and distributors carry obligations too, and the whole supply chain (contract manufacturers, module vendors, chipsets) faces cascading contractual requirements: your EU-facing distributor will demand CRA conformity contractually even if you never ship a box yourself. Component and module vendors should expect conformity questions in every RFP from now on.

“Our product is 8 years into a 10-year support commitment…”

The vulnerability/update obligations attach to the support period you declared — you owe security updates for the remaining two years, and the disclosure process must be live. Products placed on the market before applicability dates carry transitional treatment, but “we stopped making the firmware” was never a defence that survives an actively-exploited vulnerability in the field.

“Can we just self-assess?”

For most non-critical products, yes — internal production control (Module A): you build the technical file, sign the declaration, mark CE. The catch is that self-assessment shifts all the evidential burden onto the file you keep: when market surveillance asks (post-incident, post-report, random), the documentation either exists or you’re non-conformant with everything that implies.

Key Takeaways

1. The CRA turns product security into market law: essential requirements (secure by default, vulnerability handling, update delivery, SBOM) backed by CE conformity, declaration, market-surveillance powers, and turnover-scaled fines — phasing in through 2026–2027, with obligations attaching to your declared support period, not just new sales.
2. EN 303 645 is the working baseline: its provisions (no default passwords, disclosure policy, update transparency, minimised surfaces) map directly onto CRA essential requirements — conforming to it genuinely gets a non-critical product most of the way home.
3. The deliverable is a lifecycle with receipts: threat model → requirements traceability → tested builds with SBOMs → signed updates for the declared period → live disclosure channel → post-market monitoring → documentation file. Assessors inspect the process; incidents inspect its honesty.
4. Radio products are already on the clock via the RED cyber delegated act (EN 18031 harmonised route) — if you have radios and haven’t assessed, you’re late, and the CRA then layers on top.
5. Small makers aren’t exempt, but the path is walkable: 15-person firmware teams meet the substance by treating EN 303 645 as the worklist; the failure mode is certification-theatre — paperwork without the update pipeline and disclosure inbox that make it true.

References

• EU Cyber Resilience Act (Regulation (EU) 2024/2847) — essential requirements, timelines, conformity-assessment modules
• EN 303 645 — “Cyber Security for Consumer Internet of Things: Baseline Requirements” (provision-to-requirement mapping)
• ETSI EN 18031 series — harmonised standards for the Radio Equipment Directive cyber delegated act
• IoT Secure Development Guide (GSMA-class) — device secure-development practice
• Case files: connected heat-pump controllers with internet-exposed unauthenticated control — the incident class that fuelled regulation
• Internal: Don’t Crash the Factory — testing the devices this regime governs