Key points of this blog:
Cyber resilience is now a product responsibility. The EU Cyber Resilience Act (CRA) requires manufacturers to build, document, and maintain cybersecurity across the product lifecycle.
The compliance window is narrower than most manufacturers realize. Reporting obligations begin in September 2026, while the main CRA compliance requirements apply from December 2027.
CRA readiness depends on operational visibility. Manufacturers need to connect product components, vulnerabilities, supplier risks, reporting processes, and compliance evidence into a repeatable workflow.
In September 2025, researchers disclosed UniPwn, an exploit affecting several Unitree quadruped and humanoid robots. The vulnerability targeted the robots’ Bluetooth Low Energy (BLE) provisioning and Wi-Fi configuration pathways, reportedly enabling root-level takeover on affected systems and making the exploit “wormable,” with the potential to spread across nearby Unitree robots.
UniPwn shows how an ordinary setup pathway can become a security flaw with physical consequences. When the affected product is a machine that can move, sense, collect data, and interact with its surroundings, the risk can extend beyond system compromise and into the physical environment.
That is why the EU Cyber Resilience Act (CRA) matters, especially for manufacturers of connected machines and AI-enabled products. The regulation does not just add a compliance checkbox. It makes cybersecurity an ongoing product responsibility, from design through the full commercial lifecycle.
What Is the EU Cyber Resilience Act?
The EU Cyber Resilience Act (CRA) is a regulation that sets mandatory cybersecurity requirements for products with digital elements made available on the EU market. It covers a wide range of hardware and software categories, including AI robotics, IoT devices, industrial equipment, electric vehicle (EV) chargers, agricultural machinery, and off-highway systems.
The CRA entered into force on December 10, 2024. Reporting obligations begin on September 11, 2026, while the main compliance requirements apply from December 11, 2027.
The CRA applies across the product lifecycle. Manufacturers are required to address cybersecurity at the design stage, maintain it through commercial availability, and support it with documentation, vulnerability management, and incident reporting after release.
CRA timeline at a glance
December 10, 2024: CRA entered into force
September 11, 2026: Reporting obligations begin. Manufacturers must notify relevant national authorities and the European Union Agency for Cybersecurity (ENISA) of actively exploited vulnerabilities and severe security incidents through the CRA Single Reporting Platform
December 11, 2027: Main compliance requirements apply, including SBOM documentation, continuous vulnerability management, security update distribution, and lifecycle evidence.
For manufacturers new to EU regulatory requirements, the timeline is tighter than it may appear. Reporting workflows need to be operational before September 2026, which means the underlying visibility infrastructure — product component tracking, vulnerability monitoring, affected-product analysis, and post-release evidence management— needs to be in place well before that date. For connected and AI-enabled products, these obligations are not just legal requirements. They are operational responsibilities.
Why CRA Matters More for Connected Machines and Physical AI
Most cybersecurity regulations are designed with data protection in mind. The CRA is different. It was written for a world where software vulnerabilities do not just leak information; they can affect how machines behave.
For manufacturers of connected machines, that distinction changes the stakes considerably. A vulnerability in a connected EV charger, an industrial controller, or an AI-enabled robotic system is not just a data risk. It is a potential operational risk, a safety consideration, and a market access question.
When AI models mediate physical action, the attack surface extends beyond the network perimeter into the decision logic of the machine itself. CRA does not address AI-specific risks in isolation, but its lifecycle obligations — continuous vulnerability tracking, update distribution, incident reporting — are exactly the disciplines manufacturers need to manage those risks responsibly.
Three reasons CRA compliance is harder for connected machines:
Software supply chain depth: Connected products often rely on open-source components, supplier-provided firmware, and third-party services that introduce vulnerabilities outside the manufacturer's direct control
Post-release exposure: Unlike traditional products, connected machines can acquire new vulnerabilities after they leave the factory, requiring ongoing monitoring rather than point-in-time assessment
Operational continuity pressure: Manufacturers face tension between deploying security updates quickly and validating that updates do not introduce new operational issues
What Manufacturers Need to Prepare for CRA Readiness
To prepare for CRA readiness, manufacturers need to move from fragmented compliance activity to structured cyber resilience workflows. This means building the ability to identify, assess, prioritize, document, and respond to cybersecurity risks over time.
A practical starting point includes:
Build and maintain SBOMs. A software bill of materials is the foundation of CRA compliance. Without knowing exactly what components exist inside each product, including open-source libraries, third-party modules, and firmware dependencies, manufacturers cannot identify which products are affected when a new vulnerability is disclosed.
Track dependencies across the supply chain. CRA readiness depends on visibility into supplier-provided components, open-source packages, and connected services that could introduce vulnerabilities into the product.
Prioritize vulnerabilities by real product risk. Manufacturers need to identify which vulnerabilities are exploitable n their specific product configurations, which products are affected, and which risks require immediate remediation versus scheduled updates.
Prepare reporting workflows. Teams need processes that connect threat detection, affected-product analysis, mitigation planning, and disclosure readiness.
Plan security updates and support policies. Products need clear update mechanisms, support periods, remediation processes, and customer communication plans. These need to be in place at product launch, not retrofitted after a vulnerability is discovered.
Maintain audit-ready compliance evidence. Compliance depends on documentation that proves cybersecurity has been built and maintained over time.
Why CRA Is Operationally Difficult
Knowing what needs to be done is only the first step. The harder part is operationalizing CRA compliance across multiple products, suppliers, teams, and systems.
Figure 1. CRA compliance requires more than knowing the requirements. Manufacturers need the workflows, visibility, and evidence to operationalize cyber resilience across the product lifecycle.
CRA readiness touches several interconnected areas: secure-by-design practices, supply chain security, risk management, incident reporting, and continuous monitoring. Each of these depends on accurate product data, product visibility, current vulnerability intelligence, and coordinated workflows across engineering, compliance, supply chain, and security teams.
This is where many OEMs may struggle. CRA compliance cannot depend on spreadsheets, disconnected tools, or one-time documentation. It requires a repeatable operating model for identifying affected products, prioritizing risks, preparing updates, maintaining evidence, and responding quickly when vulnerabilities or incidents emerge, including newly discovered attack paths, such as the UniPwn exploit cited earlier.
From CRA Readiness to Operational Compliance
The EU Cyber Resilience Act makes one thing clear: cybersecurity is now a product responsibility.
CRA compliance requires more than awareness of the requirements. Manufacturers need continuous visibility into product components, vulnerabilities, supplier risks, incident response workflows, and the evidence needed to show that cyber resilience is being maintained across the product lifecycle.
This is the kind of operational gap that VicOne CRA Studio is built to address. It brings CRA compliance automation, SBOM management, vulnerability intelligence, threat intelligence, and supply chain risk management into one platform, helping OEMs move from fragmented compliance tasks to a continuous cyber resilience workflow.
Figure 2. VicOne CRA Studio brings CRA compliance workflows into one platform.
What that looks like in practice:
Maintaining current SBOMs across a product portfolio, not just at the point of release
Mapping disclosed vulnerabilities to affected products automatically, reducing the time between disclosure and remediation decision
Generating audit-ready compliance evidence as a byproduct of normal operations, not a separate documentation effort
Supporting the reporting workflows that the CRA Single Reporting Platform will require from September 2026
As physical AI and connected machines turn software decisions into real-world actions, cyber resilience becomes more than a compliance requirement. It becomes part of product trust, safety, and market access.
To learn more about how VicOne CRA Studio helps enterprises operationalize CRA compliance, contact VicOne.
For a deeper look at the cybersecurity risks and defense strategies shaping autonomous robotics, download VicOne LAB R7’s whitepaper “Securing the Rise of AI Robots: Cyber Risks, Real-World Threats, and Defense Strategies.”