VELLACI
Assess readiness

Who it is for

CRA readiness for connected and IoT product manufacturers.

Consumer and commercial devices, smart-home products, wearables, connected toys, gateways and the firmware and backends that make them work. What the Cyber Resilience Act asks of the people who build them, and how to run it as an operation rather than a document.

Direct answer. A connected device is a product with digital elements: hardware that contains software and connects to a network. If you place such devices on the EU market under your own name in the course of a commercial activity, you are generally the manufacturer under Regulation (EU) 2024/2847. Since 11 September 2026 you must report actively exploited vulnerabilities and severe incidents within 24 and 72 hours of becoming aware of them, and from 11 December 2027 the essential requirements, conformity assessment and CE marking apply to every device you place on the market.

The parts that surprise device teams are rarely the security controls themselves. They are the records: an SBOM tied to each firmware version, a defined support period with end-of-support communication, an awareness rule that starts a 24-hour clock, and technical documentation that has to exist for ten years. Not sure whether your product is in scope at all? Start with the scope explainer, then take the free readiness assessment.

Scope

Which of our devices are in scope?

Almost all of them. The CRA covers products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. For a connected-device manufacturer the more useful questions are where the product ends and which categories it falls into.

The device is more than the hardware

Article 3(2) brings remote data processing into the product: processing at a distance, designed by you, without which the device cannot perform one of its functions. A pairing service, a control API used by the companion app, an update server and the companion app itself are typically assessed with the device. A vulnerability exploited in that backend is therefore a product vulnerability for Article 14 purposes, and the backend's components belong in the product's vulnerability handling.

Class I categories that are common in this segment

Annex III lists several consumer device categories as important products, Class I, where the listed function is the product's core functionality:

Class I changes the conformity route from 11 December 2027 (harmonised standards or third-party assessment). It does not change Annex I or the reporting duties, which apply to default products just the same. See the full list of Annex III and IV categories.

Check sector regimes first. Medical devices under MDR/IVDR, motor vehicles under type approval, civil aviation and marine equipment are excluded from the CRA or handled by their own rules. Where those regimes do not apply to a device, the CRA generally does. Whether a borderline product sits inside or outside a sector regime is a legal question for your advisers; Vellaci records the classification decision, its reasoning and its approver on the product.

Reporting

What must be in place now that Article 14 reporting is in force?

Article 14 has applied to every manufacturer since 11 September 2026, whether or not a device was placed on the market before the rest of the regulation applies. For device manufacturers the operational risk is concentrated in three places.

  1. 01

    An awareness rule for fleet-scale signals

    Devices generate exploitation signals differently from software: customer reports, anomalous telemetry, a CISA KEV entry for a chipset library, a researcher writing about your model number. Decide in advance which of those makes the organisation aware, who confirms it, and how the timestamp is recorded. The 24-hour early warning runs from that moment.

  2. 02

    A representative with platform access

    The early warning and the 72-hour notification go through the ENISA single reporting platform. Someone must hold access, know the product data (models, Member States where the device is made available, affected firmware versions) and be reachable outside office hours. Vellaci’s runbook captures that once and shows it on every reporting case.

  3. 03

    Two final-report triggers, not one

    For an actively exploited vulnerability the final report is due no later than 14 days after a corrective or mitigating measure is available, which for firmware means the day the fixed build is published. For a severe incident, such as a compromised update server, it is due within one month after the 72-hour notification. Treating both as a generic 30-day deadline is wrong in both directions.

Vellaci does not decide what is reportable and does not submit anything to ENISA on your behalf. It surfaces the signals, structures the reviewer's decision, runs the clocks from the confirmed awareness time and records the submission with evidence. See how the CRA Reporting Command Center stages the early warning, notification and final report.

Support period

How long must we support a device?

Article 13(8) requires a support period that reflects the length of time users can reasonably expect to use the product, taking into account the expected lifetime of the device, and that is at least five years unless the product is expected to be in use for a shorter period. For hardware that is a design decision with commercial consequences, so it has to be recorded, justified and communicated.

Decide per product, with rationale

A thermostat, a camera and a toy have different expected lifetimes. Record the support period on each product with the reasoning (component supplier commitments, expected use, comparable products) and who approved it.

Publish it and its end

The support period and its end date must be communicated to users. Plan the end-of-support notice, the last security update and what the device does afterwards; keep the published statements as evidence.

Supplier lifetimes feed yours

Your support period cannot outlast the security support of the chipset SDK, the connectivity module firmware or the Linux base you build on without a plan for replacing them. Track those dependencies in the SBOM and revisit the period when a supplier ends support.

The support-period guide covers how to derive and document the period; the product registry stores it per product with end-of-support alerts.

Operations

How does this map to Vellaci workflows?

Every CRA obligation for a connected device becomes a record, a workflow or a deadline that can be shown to an auditor afterwards. This is the mapping for a typical device product with firmware and a backend.

ObligationWhat it means for a deviceIn Vellaci
Firmware inventory (Annex I Part II(1))One SBOM per firmware version covering RTOS or Linux base, BSP, connectivity stack, crypto and vendor librariesCycloneDX / SPDX ingestion per product version; components deduplicated; documents kept immutable
Vulnerability monitoringMatch the inventory continuously against advisories, not only at release timeMatching against OSV, GitHub advisories, CISA KEV and EPSS; new findings queued for triage with mandatory reasons
Reportability decision (Article 14)A named person confirms awareness of an actively exploited vulnerability or severe incident, with a timestampReviewer confirms or rejects with rationale; awareness timestamp recorded with its timezone; deadlines computed server-side
Early warning, notification, final report24 h and 72 h from awareness; final report 14 days after a fix is available (vulnerability) or one month after the notification (incident)CRA Reporting Command Center: staged, prefilled forms, alerts, recorded ENISA SRP submission with evidence
Secure updates and end of supportSigned update channel, published support period, end-of-support notice to usersSupport period per product with rationale and end-of-support alerts; evidence vault for update-mechanism documentation
Technical documentation (Annex VII)Risk assessment, design and vulnerability-handling records kept for ten years or the support periodDocumentation workspace linked to products, versions and evidence; hash-chained audit log

Firmware SBOMs that stay attached to the build

Generate a CycloneDX document in the firmware build (Yocto, Buildroot, Zephyr and most vendor SDKs can emit one, or a binary-analysis tool can reconstruct it) and push it to the version it describes with the SBOM ingestion API or CLI from CI. Historical documents are never rewritten when a newer firmware arrives, so a question about a device shipped two years ago is answered from the SBOM of that firmware, not today's.

Secure-by-default and update evidence

Annex I Part I asks for secure default configuration, protection against unauthorised access and security updates that are automatic where appropriate and free of charge. Those are design properties, but the auditor will ask for the proof: the update-signing design, the default-credential policy, the test reports. Vellaci's evidence vault links those files to the product and the requirement, with checksums and review dates, so the technical documentation is assembled as you go instead of reconstructed in 2027.

Last reviewed 13 September 2026 · Operational guidance, not legal advice.

FAQ

Connected-product questions, answered plainly.

Our device only works with our cloud service. Is the cloud part of the product?
Generally yes. Article 3(2) defines remote data processing as processing at a distance, designed by the manufacturer, without which the product could not perform one of its functions. A backend the device depends on for pairing, control or updates is assessed as part of the product with digital elements, so its vulnerabilities and incidents can be reportable under Article 14. A separate cloud service that the device merely can use is a different question; your legal advisers decide the boundary.
We cannot build an SBOM from our firmware toolchain. What is the minimum?
Annex I Part II(1) requires the SBOM to cover at least the top-level dependencies of the product. For firmware that usually means the RTOS or Linux distribution, the board support package, the connectivity and cryptographic libraries and any third-party modules you link or bundle. Start from the build manifest, add a binary-analysis pass for vendor blobs, and attach the resulting CycloneDX document to the exact firmware version it describes.
Does a five-year support period mean five years of feature updates?
No. The support period under Article 13(8) is the time during which you must handle vulnerabilities effectively, including providing security updates. It must reflect the time users can reasonably expect to use the device and be at least five years unless the device is expected to be in use for a shorter period. Feature development is your commercial decision; security updates during the support period are the obligation.
Our smart lock is sold to consumers. Is it an important product?
Smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems, are listed in Annex III as Class I important products where that function is the core functionality. Class I changes the conformity route from 11 December 2027 but does not change the essential requirements or the Article 14 reporting duties, which already apply.
Do medical wearables and connected cars follow the CRA?
Products covered by the medical-device regulations (MDR/IVDR), by vehicle type approval and by certain other sector regimes are excluded from the CRA or treated specially. Personal wearables with a health-monitoring purpose to which MDR/IVDR do not apply are a Class I category in their own right. Check the sector regime first; where it does not apply, the CRA generally does.

Read next

Find out where your device portfolio stands.

Sixteen questions, about eight minutes: a preliminary scope, the gaps by area and the highest-risk missing capability, before any sales conversation.

Get my CRA gap mapBook a CRA readiness review