IoT security · CRA

Cyber Resilience Act. Built into Infuse-IoT.

Infuse-IoT helps you build, secure, and ship connected devices with a clearer path to CRA readiness. Reporting obligations have applied since 11 September 2026, including for products already on the EU market. Main obligations apply 11 December 2027. Infuse helps you get CRA-ready. It does not make a product legally compliant.

Quick CRA readiness check Start free with Infuse

Reporting live since 11 Sep 2026
Main obligations 11 Dec 2027
All Infuse tiers

What IoT providers need to show

Security that still works on a constrained device.

Many security architectures assume a powerful gateway, always plugged into power. Infuse is built for small, battery-powered, comms-constrained devices.

Secure boot
Verified OTA update frameworks
Cryptographic key management
Continuous vulnerability monitoring
Fully traceable SBOM generation
Audit-ready conformity documentation

Book a conversation

Official CRA: Regulation (EU) 2024/2847 (opens in a new tab) · Commission summary (opens in a new tab) . The US plans to require the Cyber Trust Mark for consumer IoT sold to federal agencies from 4 January 2027.

Quick CRA readiness check

Eleven questions. About two minutes.

Nothing is sent anywhere and no contact details are required. Reporting obligations have applied since 11 September 2026 . Most other obligations apply from 11 December 2027 .

This is a readiness check, not legal advice, and it does not assess conformity. Infuse supports meeting the CRA requirements. Responsibility for conformity assessment, evidence and legal claims stays with the manufacturer.

A. Reporting readiness (live now)

A1 · Art. 14(2), 14(3)

If an actively exploited vulnerability were found in a shipped device today, could you submit an early warning within 24 hours via ENISA's single reporting platform, and a fuller technical report within 72?

Yes, we have run this

We think so, untested

Not sure

A2 · Art. 14

Do you know which national CSIRT coordinates for you, and who internally owns the clock?

Both documented

One of the two

Neither

Not sure

A3 · Art. 14

For a given vulnerability, can you determine which devices in the field are affected, and how many?

Yes, from fleet records

Partially, by manual reconstruction

Not sure

B. Product security

B1 · Annex I I(2)(f), I(2)(k)

Do shipped devices enforce secure boot and run only signed firmware?

Documented and tested

We do this informally

Not yet

Not sure

B2 · Annex I I(2)(a), I(2)(b), I(2)(c)

Do devices ship secure by default, with no default passwords and no known exploitable vulnerabilities at release?

Documented and tested

We do this informally

Not yet

Not sure

C. Vulnerability handling

C1 · Annex I II(1)

Do you maintain an SBOM for shipped firmware covering at least top-level dependencies, in a machine-readable format such as SPDX or CycloneDX?

Documented and tested

We do this informally

Not yet

Not sure

C2 · Art. 14

Do you monitor those components against live vulnerability feeds after the product ships, often enough to meet a 24-hour reporting window?

Documented and tested

We do this informally

Not yet

Not sure

C3 · Annex I II(5), Art. 13(5)

Do you have a coordinated vulnerability disclosure policy and a single actively monitored contact for reports?

Documented and tested

We do this informally

Not yet

Not sure

D. Update and support lifecycle

D1 · Annex I II(7), Art. 13(8), 13(9)

Can you deliver a signed security update over the air to every device in the field and confirm it applied, and have you declared a support period of at least five years?

Documented and tested

We do this informally

Not yet

Not sure

E. Documentation and conformity

E1 · Annex III/IV, Art. 32

Do you know your product's CRA class (Default, Important Class I or II, Critical) and therefore your conformity assessment route?

Documented and tested

We do this informally

Not yet

Not sure

E2 · Art. 28, 31, Annex V, VII

Do you maintain the Annex VII technical file and a signed Declaration of Conformity, with a plan to retain them for ten years?

Documented and tested

We do this informally

Not yet

Not sure

Where you are, what Infuse carries, what stays yours

CRA pillars: where you are, what Infuse carries, what stays yours
Pillar	Where you are	With Infuse	Stays yours
A. Reporting readiness	Unknown	Detection and fleet scoping: which components, which devices, how many.	Deciding severity and filing the ENISA / CSIRT notification on the 24 and 72 hour clocks.
B. Product security	Unknown	Secure boot, signed images, device identity, encrypted transports, attack-surface defaults.	Product-specific risk assessment and the threat model that justifies those controls.
C. Vulnerability handling	Unknown	SBOM generation in a machine-readable format, and component monitoring against live feeds.	Your disclosure policy, the published contact channel, and who monitors it.
D. Update and support lifecycle	Unknown	Verified OTA to every device, including third-party component patches.	Publishing a support period of at least five years, and keeping security updates free.
E. Documentation and conformity	Unknown	Audit-ready evidence the platform can produce (SBOM versions, connection surface, update history).	Classification, conformity assessment, CE marking, and the Declaration of Conformity.

A. Reporting readiness

Where you are:Unknown

With Infuse: Detection and fleet scoping: which components, which devices, how many.

Stays yours: Deciding severity and filing the ENISA / CSIRT notification on the 24 and 72 hour clocks.

B. Product security

Where you are:Unknown

With Infuse: Secure boot, signed images, device identity, encrypted transports, attack-surface defaults.

Stays yours: Product-specific risk assessment and the threat model that justifies those controls.

C. Vulnerability handling

Where you are:Unknown

With Infuse: SBOM generation in a machine-readable format, and component monitoring against live feeds.

Stays yours: Your disclosure policy, the published contact channel, and who monitors it.

D. Update and support lifecycle

Where you are:Unknown

With Infuse: Verified OTA to every device, including third-party component patches.

Stays yours: Publishing a support period of at least five years, and keeping security updates free.

E. Documentation and conformity

Where you are:Unknown

With Infuse: Audit-ready evidence the platform can produce (SBOM versions, connection surface, update history).

Stays yours: Classification, conformity assessment, CE marking, and the Declaration of Conformity.

Unknown is not a failure. For a fleet already in the field, not knowing is itself the finding.

Working through the full obligation list? The independent checklist at cyberresilienceact.eu (opens in a new tab) covers all 40 manufacturer obligations with article references. This check is a two-minute triage. The matrix below is what Infuse carries.

See how Infuse maps to the 22 requirements Talk through your gaps Start free with Infuse

CRA coverage matrix

How Infuse covers the 22 engineering requirements

The 22 requirements below are Annex I of the CRA: Part I is product design, Part II is vulnerability handling after ship. That is the engineering half. The remaining obligations are classification, conformity, CE marking, the technical file, retention and reporting, which stay with the manufacturer. Infuse produces most of the evidence they need.

Infuse-IoT Support
Infuse-IoT includes this capability in the product (embedded, cloud, or both).
Process Support
Infuse helps with the engineering. The manufacturer still owns the process, such as disclosure, testing cadence, or how updates are scheduled for their product.

Source: Annex I essential cybersecurity requirements (opens in a new tab) , in force 10 December 2024.

Annex I Part I

Product design and engineering controls manufacturers need built into the device and service architecture.

I Pt I	CRA requirement	Infuse-IoT Embedded	Infuse-IoT Cloud
I(1)	Risk based cybersecurity design	Infuse-IoT Support	Infuse-IoT Support
I(2)(a)	Available without vulnerabilities	Infuse-IoT Support	Infuse-IoT Support
I(2)(b)	Secure by default	Infuse-IoT Support	Infuse-IoT Support
I(2)(c)	Over-the-air Upgrades	Infuse-IoT Support	Infuse-IoT Support
I(2)(d)	Prevent unauthorised access	Infuse-IoT Support	Infuse-IoT Support
I(2)(e)	Data Confidentiality	Infuse-IoT Support	Infuse-IoT Support
I(2)(f)	Data Integrity	Infuse-IoT Support	Infuse-IoT Support
I(2)(g)	Process only relevant data	Infuse-IoT Support	Infuse-IoT Support
I(2)(h)	Protect availability of essential functions	Infuse-IoT Support	Infuse-IoT Support
I(2)(i)	Minimise impacts on other devices/networks	Infuse-IoT Support	Infuse-IoT Support
I(2)(j)	Limit attack surfaces	Infuse-IoT Support	Infuse-IoT Support
I(2)(k)	Exploitation mitigation mechanisms	Infuse-IoT Support	Infuse-IoT Support
I(2)(l)	Record and monitor internal activity	Infuse-IoT Support	Infuse-IoT Support
I(2)(m)	Option to permanently remove all data	Infuse-IoT Support	Infuse-IoT Support

Annex I Part II

Vulnerability management, disclosure, testing, and update handling obligations that continue after the product ships.

I Pt II	CRA requirement	Infuse-IoT Embedded	Infuse-IoT Cloud
II(1)	Document components and vulnerabilities	Infuse-IoT Support	Process Support
II(2)	Rapidly remediate vulnerabilities with security updates	Process Support	Process Support
II(3)	Regularly test and review product security	Process Support	Process Support
II(4)	Disclose fixed vulnerabilities and remediation guidance	Process Support	Process Support
II(5)	Maintain coordinated vulnerability disclosure policy	Process Support	Process Support
II(6)	Provide vulnerability reporting contact channel	Process Support	Process Support
II(7)	Securely distribute timely security updates	Process Support	Process Support
II(8)	Provide free, timely security patches	Process Support	Process Support

Infuse-IoT supports meeting the Annex I engineering requirements. Manufacturers remain responsible for product-specific conformity assessment, evidence, and legal claims. Infuse does not make a product legally compliant.

US, Australian, and other manufacturers outside the EU selling into the EU need an EU Authorised Representative (Art. 19). No platform can be that person for you.
The SBOM must be machine-readable (SPDX or CycloneDX). A PDF may be rejected. The technical file, including every SBOM version, must be retained for ten years.
Missing a 24-hour ENISA report is usually not the filing. It is not knowing the vulnerability applies, or which devices in the field are affected. That is a fleet problem Infuse is built to carry. The filing itself stays yours.

Infuse-SDK on GitHub Infuse docs

Start building with Infuse-IoT.

Secure updates, device identity, and software visibility — on every tier.

Start free with Infuse Book a conversation