Physical AI Manufacturers: Meet the Cyber Resilience Act Regulation

Yoav Levy

CEO and Co-founder

September 17, 2026

The Clock Is Running….

Six days ago, on September 11, the clock started running on the EU’s Cyber Resilience Act. For every company that builds a connected product, a new obligation is now live: if you discover an actively exploited vulnerability or a severe security incident, you have 24 hours to file an early warning, 72 hours to deliver a full notification, and a matter of days or weeks to close it out with a final report. There’s no grace period and no ramp-up. The requirement either applies to you today, or it doesn’t.

We’ve spent close to a decade helping automotive OEMs build the infrastructure to meet a regulation that asked the same question in a different market. Physical AI companies are about to go through exactly what automotive went through with UNECE WP.29 R155, on a compressed timeline, with far less runway to prepare.

What the CRA is, and who it actually reaches

The Cyber Resilience Act is the EU’s first horizontal cybersecurity law for products with digital elements, a category broad enough to cover hardware and software alike, as long as the product has, or is reasonably expected to have, a data connection to a device or a network. That definition doesn’t carve out an exception for robots, drones, or autonomous machines. If your product is sold or operated in the EU and it talks to anything, a fleet management system, a cloud backend, another machine, it’s very likely in scope.

The CRA rolls out in phases. The rules that classify products into risk tiers (default, “important,” and “critical,” with the higher tiers facing third-party conformity assessment) have been in force since December 2025. The full set of essential cybersecurity requirements and CE-marking obligations lands on December 11, 2027.

But the reporting duty, the 24/72-hour clock, didn’t wait for either of those milestones. It’s already running, and it applies to manufacturers broadly, not just to the products ultimately classified as important or critical.

For physical AI specifically, that means the companies building industrial robots, AMRs, humanoids, drones, and the fleet software and APIs that orchestrate them need to assume they’re in scope now, not in 2027. The people who should be reading the fine print aren’t just compliance teams, they’re the CISOs and engineering leaders who will be asked, on short notice, to produce evidence of a vulnerability they may not yet have the visibility to detect.

What R155 already taught us

Automotive went through this. UNECE WP.29 R155 required every OEM selling vehicles into UN-regulated markets to stand up a Cybersecurity Management System (CSMS) covering the full vehicle lifecycle, not just design, but production and, critically, everything that happens after the vehicle is on the road. New vehicle types had to comply starting in July 2022; every new vehicle by July 2024. We watched this unfold from inside the industry, and a few lessons came through clearly enough that I’d bet on them repeating in physical AI.

Compliance is not a certificate you earn once. R155 doesn’t ask an OEM to prove its vehicle was secure at launch, it asks for a working capability to detect and respond to threats across a fleet for years afterward. The CRA’s 24-hour reporting clock is the same demand, just less forgiving: you cannot report what you cannot see, and you cannot see it in real time if your only visibility comes from a periodic audit.

Your supply chain is your compliance surface, whether you’ve accounted for it or not. R155 made OEMs accountable for the cybersecurity posture of their Tier-1 and Tier-2 suppliers, not just their own code. Physical AI companies are, if anything, more exposed here. A single robot or AMR is built from sensors, actuators, embedded controllers, and third-party software from a long list of vendors, and under the CRA, a vulnerability anywhere in that stack can become your reporting obligation.

A policy binder is not evidence. R155 requires manufacturers to make a “reasoned argument” that their security processes actually work, backed by documentation and data, not a written policy that’s never been tested. Regulators and CSIRTs under the CRA will expect the same: an audit trail, not an assertion.

And the companies that started early had it easier. The OEMs who built monitoring and detection infrastructure ahead of the July 2022 deadline moved through type approval without much drama. The ones who waited scrambled, and some missed the deadline outright.
Physical AI is standing roughly where automotive stood in early 2021, the deadline is fixed, and how much difficulty you experience between now and then depends almost entirely on how early you start.

How physical AI manufacturers should prepare for compliance, and for what comes after

The starting point isn’t a compliance checklist. It’s visibility. You cannot file a 24-hour early warning on an incident you’d otherwise discover through a customer complaint or a quarterly review, that requires continuous, real-time monitoring of how your devices and fleets are actually behaving, not periodic sampling. That visibility has to extend past the device itself, to the applications, APIs, AI agents, and cloud systems that operate it, and to the components your suppliers provide, since your reporting obligation doesn’t stop at your own bill of materials.

From there, ownership and rehearsal matter more than most teams expect. Build the internal process now: who gets notified, who drafts the report, who submits it and tests it before a real vulnerability forces you to learn it live, on the clock.

The instinct to treat this as a cost center is understandable, and it’s also a missed opportunity. The same real-time visibility that produces a compliant 24-hour report is the visibility that catches a failing actuator before it causes downtime, flags an anomalous command before it becomes a safety incident, and gives your customers confidence that your fleet is being watched. Automotive OEMs who built this infrastructure for R155 didn’t just clear a regulatory bar, they ended up with better fleet health data, faster failure analysis, and a stronger security posture than the regulation strictly required. That’s the model worth aiming for: compliance as a byproduct of actually knowing what your machines are doing, not as a parallel project bolted on top.

We built this infrastructure for automotive because the industry didn’t have a choice, and it’s the same infrastructure, extended to robots, drones, humanoids, and the rest of the physical AI ecosystem, that we believe this next wave of manufacturers will need. The CRA’s clock is already running. The only real question is how much of the last decade’s lessons you get to use before yours does too.

Newsletter Icon

The AI Awakening – 2026 Global Automotive and Smart Mobility Cybersecurity Report

Newsletter Icon

Subscribe
to our newsletter

Stay up-to-date on the latest trends, emerging risks, and updates

Upstream Joins Forces with Cisco Cloud Control to Power Physical AI Intelligence for Agentic Operations

As part of Cisco’s marketplace expansion, the integration lets AI agents in Cisco Cloud Control query Upstream’s Model Context Protocol (MCP) servers to access real-time…

Read more

The FCC’s New Robotics Ban is a Watershed Moment for Cyber-Physical Security

As security leaders operating at the intersection of Physical AI, connected vehicles, and smart mobility, we at Upstream have long warned that when you put…

Read more

Intent Over Identity: Deconstructing the OpenAI Escape

In our recent Rethinking the Perimeter series, we explored how static network boundaries fail when facing modern AI and API ecosystems, as well as the…

Read more

Rethinking the Perimeter: Excessive Data Exposure and the Outbound Blind Spot

As SOC executives transition to managing autonomous MCP servers on top of the existing complex cloud topologies and distributed microservices, we must acknowledge a critical…

Read more