EU Cyber Resilience Act for IoT: Why Resilient Connectivity Matters

Introduction

For IoT manufacturers, the conversation is no longer just about security features at the point of sale. It is about staying able to support, monitor and update those products for the full period they are expected to remain in use in the field, and that is where connectivity resilience becomes part of the CRA risk conversation.

For many IoT OEMs, the CRA risk is not only whether the device was built securely. It is whether the manufacturer can still reach that device in the field when a vulnerability needs investigating, a security update needs delivering, or an incident-reporting clock has started.

In brief: The CRA does not make connectivity a standalone compliance category, but it does require manufacturers to think about lifecycle security, vulnerability handling, updates, availability and attack surface. If a deployed IoT device cannot be reached, or is exposed on the public internet by default, those obligations become harder to evidence and execute.

What the CRA actually asks of IoT manufacturers

Adopted as Regulation (EU) 2024/2847 on 23 October 2024 and published in the Official Journal on 20 November 2024, the CRA sets horizontal cybersecurity requirements for “products with digital elements”. That definition can capture much of the IoT estate: sensors, gateways, telematics units, telecare devices, EV chargers, payment terminals, smart meters and, where in scope, the software or remote data processing solutions that support them.

Note: Products regulated under sector-specific regimes, including medical devices, in-vitro diagnostics, certain vehicle frameworks, aviation-certified products and marine equipment, may sit outside the CRA’s scope and should be assessed under those regimes separately.

The CRA’s application and implementation timeline is as follows:

CRA Timeline

For long-life IoT estates, that is a much shorter window than it sounds.

For individual products placed on the EU market before 11 December 2027, the position is nuanced: the main CRA obligations apply from that date only if those products subsequently undergo a substantial modification.

Products newly placed on the market after full application must follow the applicable CRA route. Article 14 reporting obligations, however, apply to all in-scope products already made available on the Union market before 11 December 2027.

For those pre-11 December 2027 products, Article 14 does not by itself bring the product into the full CRA vulnerability-handling and conformity regime, unless the product is substantially modified after that date.

For manufacturers, the obligations come down to three things:

Secure by design. Products must meet the Annex I essential cybersecurity requirements, with implementation informed by a documented cybersecurity risk assessment, including secure default configurations, protection of confidentiality and integrity, and minimised attack surfaces.
Vulnerability handling for the full support period:
- Identify, document and remediate vulnerabilities throughout the time the product is expected to be in use.
- Provide security updates without separate charge, with automatic updates as the default where applicable, supported by clear user information, opt-out mechanisms and temporary postponement options where relevant, disclose the support period to buyers up front, and maintain component documentation including a software bill of materials (SBOM).
- In most cases, that support period must be at least five years, unless the product is expected to be used for a shorter time, and may need to be longer where the product is reasonably expected to be used for extended periods. Once declared, it forms part of the product’s accompanying information and is a market commitment for the full duration.
Conformity assessment and CE marking. For newly placed in-scope products after the relevant CRA application date, the applicable conformity route and CE marking become central to lawful EU market access. The route depends on the product tier:
- Default products (outside the important and critical categories): generally self-assessment.
- Important Class I products, for example internet-connecting routers and modems, smart door locks and home security cameras: self-assessment where harmonised standards, common specifications or a relevant European cybersecurity certification scheme are applied; otherwise a third-party route is required.
- Important Class II products, such as firewalls and intrusion detection and prevention systems: third-party assessment or applicable certification.
- Critical products, such as smart meter gateways and secure elements: currently require third-party assessment or, where available and applicable, a European cybersecurity certification scheme. A Delegated Act establishing the presumption of conformity for the European Cybersecurity Certification scheme on Common Criteria (EUCC) is expected in Q4 2026.

For compliance teams. The Commission has since adopted Implementing Regulation (EU) 2025/2392, which provides the technical descriptions used to determine whether a product’s core functionality falls within the CRA’s important or critical product categories. Harmonised CRA standards are being developed by ETSI, CEN and CENELEC under the Commission’s standardisation request, with first deliverables expected from Q3 2026. Until harmonised standards are published, the Important Class I self-assessment route will depend on common specifications or applicable certification where available; otherwise, a third-party route may be required.

Layered on top is the reporting clock for actively exploited vulnerabilities and severe security-impact incidents, applicable from 11 September 2026. Manufacturers must submit an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report either no later than 14 days after a corrective or mitigating measure is available for an actively exploited vulnerability, or within one month of the 72-hour submission for a severe incident.

Commission Delegated Regulation (EU) 2026/881, adopted in December 2025 and published in April 2026, sets the cybersecurity-related grounds on which a CSIRT initially receiving a notification may delay dissemination to other CSIRTs; manufacturers’ own 24-hour, 72-hour and final-report obligations are unaffected. Maximum penalties for non-compliance with Annex I and Articles 13 and 14 run up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Availability is not just an SLA, it is an essential requirement

As the CRA is a security regulation, it is easy to miss that availability is woven into Annex I. Products are expected to be designed to ensure availability of essential and basic functions, including after an incident, and to minimise their own impact on the availability of services provided by other devices or networks.

This should not be read as an uptime guarantee imposed by the CRA; rather, availability is part of the product-security properties manufacturers must consider and evidence through their risk assessment, design choices and support processes.

That matters for cellular IoT in a very practical way. If a manufacturer cannot reach a deployed device, it may be unable to:

deliver security updates, including automatic updates where applicable;
collect the telemetry needed to detect a vulnerability being exploited;
protect the essential function the product was placed on the market to deliver in the first place.

The legal clock for reporting begins when a manufacturer becomes aware of an exploited vulnerability or severe incident, but extended loss of contact with deployed devices can make it harder to gather evidence, investigate confidently and meet reporting obligations.

Connectivity loss is therefore not just a service-quality problem. Under the CRA it extends into security obligations and essential-function availability. Connectivity resilience does not by itself prove CRA availability compliance, but it can form part of the manufacturer’s technical and operational evidence for how essential functions, updates and incident response are maintained in deployed conditions.

The single-network vulnerability

Many cellular IoT estates still depend on a single home operator, core-network path or commercial roaming architecture, even where the SIM is described as “multi-network” or roaming. Where traffic and authentication remain dependent on that primary core, a core-network outage can take the estate offline even if partner radio coverage is still available.

That works well most of the time. It does not work well when:

the home operator’s core suffers an outage in the country or region where the estate is deployed;
a single operator has a localised radio fault that roaming partners do not cover;
a roaming agreement changes; or
2G and 3G sunsets remove fallback paths that older estates quietly relied on.

Picture the moment that matters: A vulnerability is being actively exploited. Once the manufacturer becomes aware, the 24-hour early-warning clock starts, but a portion of the deployed estate is unreachable because the primary mobile core is degraded. The issue is no longer just connectivity performance; it affects investigation, evidence gathering and the manufacturer’s ability to act confidently.

For an OEM, a single-network architecture concentrates a surprising amount of risk in one supplier relationship. The device may be perfectly secure by design, fully patched, and supported by a well-maintained SBOM, and still be unreachable during a network outage or service degradation. From a CRA perspective, that is an availability question, an updateability question, and potentially a reporting question all at once.

Connectivity is not compliance, but it may become part of the evidence

The CRA does not prescribe a particular connectivity architecture. For example, it does not say that cellular IoT products must use multi-network SIMs, but it does require manufacturers to maintain security throughout the expected product lifetime, handle vulnerabilities, provide updates and protect essential functions. For connected products deployed in the field, those duties are far easier to perform and evidence when the manufacturer can reach the device when it matters.

That is the lens through which connectivity resilience earns its place in CRA readiness conversations. Not as a regulatory obligation in its own right, but as part of the operational evidence base that lets a manufacturer demonstrate it is meeting the obligations the Regulation does impose.

Where rSIM fits

CSL’s patented rSIM is a SIM-level answer to the connectivity-resilience side of that problem. It carries two operator profiles, monitors network health autonomously, and switches to the backup profile when the primary path is no longer delivering. When the primary network recovers, rSIM returns to it on its own. The device does not need to do any of that logic itself.

In CRA-readiness terms, the practical effects are reduced downtime windows, a higher update-delivery success across the estate, and a cleaner conformity-assessment story when an assessor asks how essential functions stay available.

For IoT manufacturers thinking about CRA-era product design, four properties matter most:

No hardware re-spin needed. rSIM works with devices that already accept UICC or eUICC SIMs, without requiring dual-SIM hardware, firmware complexity or specialist modules.
Less code to defend, document and update. The resilience behaviour lives in the SIM itself, not in device code. That keeps the OEM’s firmware simpler and reduces device-side code, services and dependencies the manufacturer has to defend and account for in the technical documentation and SBOM context. (SIM and connectivity-management components may still need supply-chain due diligence in their own right).
Proven in critical-IoT estates. rSIM is GSMA-aligned and deployed at scale in mission- and life-critical systems across telecare, EV charging, retail PoS, lone-worker, CCTV and automotive use cases. These are sectors where downtime has a real cost.
The practical effect for an OEM is that resilience can be added through procurement and provisioning rather than through a hardware re-design. That matters when product roadmaps are already being squeezed by 2G and 3G sunsets, eSIM transitions (notably GSMA SGP.32 for IoT remote SIM provisioning), and CRA readiness work running in parallel.

Reducing attack surface: private APNs and VPNs

Annex I asks for more than availability. It asks manufacturers to limit attack surfaces and exposed external interfaces, to protect the confidentiality and integrity of data in transit, and to control access to the device. For cellular IoT, the way a device reaches the internet (or, ideally, does not) is squarely part of that conversation.

A standard public APN gives the device an outbound path to the public internet. That is operationally simple, but depending on the operator setup, IP addressing and firewalling model, it can also increase the extent to which the device relies on its own firmware controls to prevent unauthorised access. For a CRA conformity assessment, that is a lot of weight to put on the device alone.

A private APN takes a different approach. When configured with private routing into the manufacturer’s or customer’s secure environment, device traffic can be carried through a dedicated mobile network gateway without exposing the device directly to the public internet, subject to the operator’s routing and onward-connectivity design. Combined with VPN tunnelling, this gives manufacturers:

A reduced and more defensible attack surface, where devices are not discoverable or directly addressable from the public internet.
Encrypted transport between defined network endpoints, supporting the confidentiality and integrity requirements in Annex I. Where end-to-end protection is needed beyond those endpoints, this can be combined with application- or device-layer encryption.
SIM-level authentication and APN/private-routing access controls, in addition to whatever the device firmware enforces.
Clear traffic segregation, which makes telemetry, logging and incident investigation more straightforward.

For an OEM, this is an architectural choice that can move some security controls from device firmware into the managed connectivity layer, where they can be administered centrally across an entire estate.

That has direct downstream effects on two of the heaviest CRA workloads. Where this architecture allows device-side remote-access services to be removed or disabled, it can also reduce the exposed software surface: fewer device-side services and dependencies to account for in the technical documentation and SBOM context, fewer CVEs (Common Vulnerabilities and Exposures) to triage over the support period, and fewer device-side mitigations to maintain. And the conformity assessment narrative becomes more defensible: when an assessor asks how the device protects confidentiality in transit or limits exposure of external interfaces, a documented private APN architecture is a cleaner answer than a list of firmware-side mitigations alone.

Where the manufacturer's responsibility still sits

Neither rSIM nor a private APN is a CRA compliance product. They do not generate SBOMs, run vulnerability disclosure programmes, perform conformity assessment, or take an incident report off a manufacturer’s desk. Those obligations remain firmly with the manufacturer.

What they do is reinforce the connectivity layer that several Annex I requirements depend on. rSIM addresses single-network loss. Private APNs and VPNs reduce the attack surface a device exposes and protect data in transit. A manufacturer can only patch a device, observe its behaviour, and meet its reporting milestones if that device is reachable, and ideally only reachable on terms the manufacturer controls.

CRA Requirements

How CRA Annex I requirements map to connectivity architecture, and where the manufacturer’s responsibility still sits.

What IoT manufacturers should do now

Five practical questions are worth working through this year. Use these as discussion prompts between engineering, product and procurement.

CRA readiness checklist for IoT manufacturers

Which of our products are in scope, and which are “important” or “critical”?
Can we reach every deployed unit on every network we depend on?
Is single-network risk on a register, with procurement and product visibility?
Could private APN or VPN narrow our exposed attack surface?
What can the SIM and connectivity layer absorb to keep firmware scope simple?

For most manufacturers, the answer will be a phased programme. Build CRA expectations into product specifications and supplier contracts. Use the lead time before December 2027 to design out the riskier corners of the estate. And treat connectivity resilience as part of the essential-availability story the CRA asks you to tell, not as an afterthought bolted on once the firmware is finished.

Frequently asked questions

Does the Cyber Resilience Act require multi-network connectivity?

No. The CRA does not prescribe any particular connectivity architecture. It does require manufacturers to maintain availability of essential functions, deliver security updates and meet incident-reporting deadlines throughout the support period, all of which are far easier to perform and evidence when devices can be reached reliably.

Does the CRA require devices to remain reachable at all times?

No. The Regulation does not impose a reachability or uptime target as such. It does require manufacturers to deliver security updates, investigate and remediate actively exploited vulnerabilities and meet incident-reporting deadlines through the support period, all of which are far easier to perform and evidence when devices can be reached reliably. Persistent unreachability undermines those obligations even where no single reachability rule is breached.

Do private APNs make an IoT product CRA compliant?

No. A private APN can reduce a device’s exposed attack surface. When combined with VPN tunnelling or application-layer encryption, it can also support protection of data in transit between defined endpoints. Compliance also requires secure-by-design product properties, a documented vulnerability-handling process, an SBOM, conformity assessment and a credible support commitment. Those obligations sit firmly with the manufacturer.

When do CRA reporting obligations begin?

Reporting obligations begin on 11 September 2026. From that date, manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a fuller notification within 72 hours, and a final report on the timeline set in Article 14.

What should IoT manufacturers review before December 2027?

Product portfolios for scope and tier classification (using the technical descriptions in Implementing Regulation (EU) 2025/2392), vulnerability-handling processes, support-period commitments, conformity-assessment routes, and the connectivity architecture that supports updateability and availability across the estate.

The CRA creates the deadline. Resilient design is the strategy

For IoT manufacturers, that means thinking about cybersecurity, lifecycle management and connectivity as a single product question rather than three separate workstreams.

A device that is secure by design but unreachable in the field, or unnecessarily exposed to the public internet, may weaken the manufacturer’s ability to demonstrate lifecycle security and availability under the Regulation. CSL’s resilient SIM technology reduces a common single-network or single-core failure mode, and managed private APN and VPN connectivity narrows the attack surface a device exposes from day one. In many deployments, both can be introduced without hardware redesign and with minimal device-side change, leaving manufacturers free to focus their CRA effort where it most needs to land: secure development, vulnerability handling and a credible support commitment to the customers who depend on the product.

Planning your CRA roadmap?

CSL has spent more than three decades building resilient connectivity for life, mission and business critical IoT. We support over 3.5 million live critical connections across the UK, Europe and beyond, and operate with cyber credentials including Cyber Essentials Plus, ISO27001 and a vulnerability disclosure policy.

If you are working through CRA implications for cellular IoT products, we can talk through where rSIM, private APN/VPN and managed connectivity fit, practically, and without forcing a hardware redesign.

Discuss CRA-era IoT connectivity with CSL