EU Cyber Resilience Act shifts product cybersecurity into operations

At a glance

What this is: VicOne’s analysis says the EU Cyber Resilience Act turns product cybersecurity into a lifecycle obligation for connected and AI-enabled products, with reporting and compliance milestones that require operational visibility well before the deadlines.

Why it matters: For IAM and security teams, the main lesson is that product trust now depends on governed visibility into components, vulnerabilities, suppliers and evidence, which increasingly intersects with device identity, update assurance and lifecycle control.

By the numbers:

• Reporting obligations begin on September 11, 2026, under the EU Cyber Resilience Act.
• The main compliance requirements apply from December 11, 2027, under the EU Cyber Resilience Act.
• The CRA entered into force on December 10, 2024.

Context

The EU Cyber Resilience Act is a lifecycle cybersecurity rule for products with digital elements, not a one-time compliance checklist. It shifts attention from isolated technical fixes to ongoing responsibility for design, vulnerability handling, reporting and evidence across the product lifecycle.

That matters because connected machines and AI-enabled products turn software weaknesses into operational and sometimes physical risk. In practice, manufacturers need product visibility, supply chain traceability and repeatable reporting workflows before the deadlines arrive.

VicOne's UniPwn example is a useful reminder that ordinary provisioning paths can become attack paths when product identity, configuration and update controls are weak.

Key questions

Q: What breaks when manufacturers do not have product-level visibility for CRA compliance?

A: Without product-level visibility, manufacturers cannot reliably identify which builds contain a vulnerable component, which customers are affected, or whether an issue requires remediation, disclosure or both. The result is delayed response, inconsistent reporting and weak evidence. CRA compliance depends on knowing the component, the product instance and the release state before a vulnerability decision can be made.

Q: Why does the EU Cyber Resilience Act create operational risk as well as compliance risk?

A: The CRA turns cybersecurity into an ongoing product responsibility, so failures affect release readiness, reporting obligations and customer trust, not just audit status. If vulnerability monitoring, update distribution and evidence collection are not operationalized, teams may miss the reporting window or ship products that cannot prove resilience. That is an operational failure with regulatory consequences.

Q: What are the signs that a product security programme is not ready for CRA compliance?

A: A programme is not ready when product scope is unclear, third-party components are not verified, and incident reporting paths are undefined. Other warning signs include no regular vulnerability review, no technical documentation for security claims, and no clear owner for conformity assessment. These gaps usually surface late, when evidence is needed for regulators or notified bodies.

Q: Who should own cyber resilience evidence for connected products?

A: Ownership should sit across product security, engineering, compliance and supply chain functions, because CRA evidence spans design, vulnerability handling, update support and reporting. No single team can produce the full record alone. The governance model has to define who maintains component data, who approves remediation decisions and who signs off disclosure readiness.

Technical breakdown

How the CRA turns product lifecycle data into security control

The CRA expects manufacturers to know what is inside each product, where it is used, and how it changes over time. That means the security problem is not just vulnerability discovery, but the ability to connect components, suppliers, firmware, and deployed instances into one governed record. Without that lifecycle view, teams cannot decide whether a disclosed flaw affects a specific product build, an entire product family, or only a subset of customers. The control model therefore depends on inventory quality, dependency mapping, and evidence retention as much as on patching itself.

Practical implication: Build a product-level inventory that links components, versions and deployments before you rely on vulnerability response.

Why SBOMs matter more when products keep changing after release

A software bill of materials is the anchor for post-release governance because products continue to accumulate risk after shipment. Connected products pull in open-source packages, supplier firmware and external services, so the question becomes which exact released build contains the vulnerable component and how quickly that build can be identified. SBOMs do not eliminate risk, but they make affected-product analysis possible and reduce the time between disclosure and decision. In regulated product environments, that speed matters because reporting, remediation and customer communication all depend on accurate component knowledge.

Practical implication: Keep SBOMs current at release and after updates so disclosed vulnerabilities can be mapped to affected products quickly.

How physical AI expands the consequences of insecure provisioning

Physical AI changes the blast radius of security failures because model behaviour can influence movement, sensing and interaction in the real world. In the article's robot examples, vulnerabilities in provisioning and configuration are not only access issues. They can alter device state, expose administrative control, or cause unexpected physical behaviour. That is why product identity, secure onboarding, and update assurance are central even when the primary risk looks like software hygiene. For connected machines, secure provisioning is a trust boundary, not just a setup step. See the Device and IoT Identity Guide.

Practical implication: Treat provisioning and configuration pathways as part of the attack surface and govern them like privileged onboarding flows.

Threat narrative

Attacker objective: The attacker appears to seek privileged device control that can spread across nearby robots and potentially affect physical behaviour.

1. Entry occurs through the robots' Bluetooth Low Energy provisioning and Wi-Fi configuration pathways, which act as externally reachable setup interfaces.
2. The exploit reportedly enables root-level takeover on affected systems, giving an attacker privileged control over the device.
3. The attack is described as wormable, creating the possibility of spread across nearby Unitree robots and extending the impact beyond a single device.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CRA compliance is fundamentally an identity and lifecycle governance problem for connected products. The article shows that manufacturers must know not only what ships, but what remains active after release, what can be updated, and what evidence proves those decisions. That makes product identity, component identity and update authority part of the control plane, not peripheral documentation. Manufacturers should treat product lifecycle governance as a security discipline, not an after-the-fact reporting task.

Provisioning trust gaps are where physical product risk often begins. When setup channels such as BLE provisioning or Wi-Fi configuration can be abused, the issue is not only a software flaw but a failure to govern onboarding trust. In connected machines, the provisioning path is effectively a privileged access path, and weak trust assumptions there can cascade into root access and unsafe behaviour. Organizations should review setup workflows as privileged entry points, not convenience features.

SBOM discipline is now the difference between vulnerability awareness and actionable compliance. Without accurate component data, teams cannot tell which products are exposed when a vulnerability is disclosed, which in turn delays remediation and reporting. This is why the CRA pushes manufacturers toward repeatable lifecycle evidence, not spreadsheet-driven exception handling. Practitioners should align disclosure, affected-product analysis and evidence retention as a single operating model.

Physical AI makes cybersecurity a safety and market-access issue, not only an IT issue. When software controls a machine that moves, senses or interacts with the world, compromise can affect physical outcomes and customer trust. That widens the governance burden for OEMs and device makers, especially where the device identity model, update path and supply chain all intersect. The practical conclusion is that cyber resilience must be built into product assurance from the start.

Cyber resilience planning now needs to absorb product governance, not sit beside it. The article's timeline and operational requirements point to a world where incident reporting, vulnerability management and update support are continuous functions. For manufacturers, that means resilience planning must cover product portfolios, supplier dependencies and release evidence together. Teams that separate those streams will struggle to prove compliance when the reporting window opens.

What this signals

Operational visibility is the real CRA control gap: manufacturers that cannot continuously map components, vulnerabilities and affected products will struggle to convert regulatory obligations into repeatable action. The problem is not just missing documentation, but missing linkage between product state, release state and response state.

Product trust now depends on governed update and evidence pathways. As connected machines become more capable, the security programme has to prove that remediation, reporting and lifecycle support are working as a single operating model. That is where product assurance, not just patching, becomes the benchmark.

Physical AI raises the stakes for identity and access governance at the device boundary. When setup, provisioning or update channels are weak, product control can turn into real-world impact. Device identity, secure onboarding and update assurance should therefore sit inside the resilience plan, not outside it.

For practitioners

• Build a product-level component inventory Track components, firmware dependencies, supplier modules and deployed product versions so teams can identify exactly which builds are affected when a vulnerability is disclosed.
• Operationalize SBOM maintenance across the portfolio Keep SBOMs current for release builds and post-release updates, then tie them to affected-product analysis so disclosure decisions are based on accurate composition data.
• Prepare CRA reporting workflows before the 2026 deadline Connect threat detection, vulnerability triage, affected-product analysis and disclosure readiness so reporting does not depend on ad hoc manual coordination. See the Global Cybersecurity Regulatory Map.
• Treat provisioning as a privileged trust boundary Review Bluetooth, onboarding and configuration pathways for connected machines as privileged access flows, and validate that setup cannot be used to force unsafe device control.
• Retain audit-ready evidence as part of normal operations Generate and store lifecycle evidence for security updates, remediation decisions and incident handling so compliance proof is available without a separate documentation scramble.

Key takeaways

• The CRA makes cybersecurity an ongoing product obligation, which means manufacturers need lifecycle governance instead of one-time compliance activity.
• Connected and AI-enabled products create broader risk because software flaws can affect physical behaviour, update confidence and market access.
• Teams that lack component visibility, SBOM discipline and reporting workflows will struggle to prove compliance when vulnerabilities or incidents emerge.

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Device and IoT Identity Guide · Cyber Resilience Guide · Global Cybersecurity Regulatory Map

Key terms

• EU Cyber Resilience Act: A European Union law intended to raise the security baseline for hardware and software with digital elements. It requires security considerations across design, development, market placement, and maintenance, so manufacturers, importers, and distributors carry clearer responsibility for product cybersecurity throughout the life cycle.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Provisioning Path: A provisioning path is the mechanism that creates, updates, or removes access for an identity. It may use SCIM, connectors, directory sync, or embedded automation. If the path is hard to maintain or weakly audited, entitlements drift away from policy and access becomes durable by accident.
• Product Lifecycle Evidence: Product lifecycle evidence is the record that shows cybersecurity has been maintained from design through release, update and support. It includes decisions, remediation records, vulnerability handling and reporting artefacts that prove the organisation has governed the product over time rather than relying on point-in-time checks.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to connect identity controls to broader security and resilience programmes.