When the Safety Function Believed the Input: Robot Perception Attacks Through an IEC TS 63074, ISO 13849-1 and EU Machinery Regulation Lens

There is no casualty here and no recall. What there is, is a cluster of results showing that a robot can execute every safety rule in its specification, correctly, on schedule, with no fault flagged, and still do the wrong thing, because the information the rule was evaluated on was false. Functional safety is built to catch a component that stops telling the truth. It is much less prepared for a component that keeps telling a perfectly consistent lie.

Treat this post as a reading of the research, not an incident report. I am reading the public record forwards into the work product it implies, which is the only time that reading is cheap.

The public record

On October 1, 2026, The Robot Report published a piece titled "Your Robot's Safety Functions Already Work. What If the Input Lies?" It describes three experiments run by VicOne's research lab. In the first, a robot dog driven by a Gemma 4 E4B model read text on a poster as an instruction and changed its movement. In the second, a hospital service-robot simulation using Nemotron on an NVIDIA Jetson AGX Orin changed behavior in response to inaudible, crafted audio. In the third, at a robotics bug bounty event, ROS 2 / DDS message injection caused an immobilized robot to move.

The article's framing is the useful part: a robot can follow its safety rules and still act on manipulated information, and a single attack that corrupts multiple verification channels at once defeats redundancy that was sized for independent random faults. Its sharpest line, which I will quote because I cannot improve it: "Cyber threats add intent to the safety equation, so risk assessments based on accidental faults must be revisited to account for attacks that can be timed and repeated."

A disclosure on provenance. The IEEE Spectrum piece "Rethinking Robot Safety in the Age of AI" (September 16, 2026), which covers the same ground, is sponsored content authored by VicOne. I use it only for the academic results it summarizes. The sponsor is selling testing tools, so weigh the framing accordingly. The experiments themselves are plausible, and none of them is exotic.

The surrounding literature is not new, which is rather the point. The FreezeVLA paper (arXiv 2509.19870) reports adversarial images that make a vision-language-action model ignore later instructions, with an average attack success rate of 76.2% across three VLA models and four robotic benchmarks, and strong transfer across different prompts. The IEEE Spectrum piece cites GoBA, which used an ordinary object as a backdoor trigger and reported a 97 percent attack success rate without degrading clean-input performance. And the physical-layer precedent is older than the whole VLA wave: at USENIX Security 2015, a KAIST team showed that 7 of 15 tested MEMS gyroscope models had exploitable resonant frequencies, with resonant output dozens of times larger than normal output, using a consumer speaker below 30 kHz. Sound, in other words, has been a sensor input for a long time.

On the regulatory side, EU Regulation 2023/1230 applies from January 20, 2027. Its Essential Health and Safety Requirements include 1.1.9, protection against corruption, and 1.2.1, safety and reliability of control systems. The harmonized standard being written for them, prEN 50742, uses a three-stage approach (identify critical assets, analyze threats, determine a security level from SRSL0 to SRSL3), and per the Pilz/IBF summary was scheduled for final vote in September 2026 and publication in November 2026.

The standards lens

Four layers should have caught this, and each one has a specific gap.

ISO 12100 §5 (risk assessment) and §6 (risk reduction). The hazard identification in ISO 12100 is organized around hazards of the machine and their foreseeable misuse. A reasonably foreseeable adversary is a hard sell under classic "misuse" language, which is why 2023/1230 §1.1.9 exists: it makes corruption a design input rather than an interpretation.

ISO 13849-1 §6 (categories) and Annex F (common cause failure). The Performance Level machinery quantifies random hardware failures, with common cause failure scored in Annex F. Common cause there means a shared physical or environmental stressor. It does not model a single crafted stimulus that is wrong in the same way on the camera, the lidar and the language model at once, and it assigns no credit or penalty to an attacker. A Category 3 two-channel architecture can score beautifully and still share one poisoned input.

IEC TS 63074. This is the technical specification written to cover security aspects of safety-related control systems, and the Robot Report article cites it as the relevant bridge. It is the correct place to ask, per safety function, what the security-relevant assets are and what security level the function needs. It is a TS, not a harmonized standard, which matters for conformity claims.

ISO 10218-1:2025 folded cybersecurity into the safety planning process for industrial robots. That is a real step, but it is written around a manipulator with a defined sensing and safeguarding interface. A perception stack with a learned model upstream of the safeguarding decision is exactly the part nobody can currently rate with a PFH figure.

IEC 62443-3-3 and 62443-4-2 supply the security level (SL-T) and component requirement vocabulary that prEN 50742 maps into SRSL0 to SRSL3. They are where the numbers come from once someone decides which interfaces count as critical.

The common failure of all four is the same sentence missing from the safety requirements specification: what is this function allowed to assume about its inputs, and who enforces that assumption?

A worked snippet

Below is my own illustrative analysis, not VicOne's and not any vendor's. The machine is a generic mobile service robot with a speed-and-separation safeguarding function that uses a learned perception module to classify "person nearby."

Threat scenario row (TARA, ISO/SAE 21434 §15 style, adapted to machinery)

| ID | Asset | Threat scenario | Impact (safety) | Attack feasibility | Treatment | |---|---|---|---|---|---| | TS-01 | Camera frame feeding person classifier | Printed pattern in the scene suppresses the "person" class (false negative) | Severe: robot continues at full speed toward a person | Medium: no network access, printed material, repeatable | Reduce: independent non-learned detection channel | | TS-02 | Microphone / voice command path | Inaudible crafted audio injects a motion command | Major: unintended motion in shared space | Medium: needs proximity and a speaker | Reduce: command authentication, no motion authority from audio | | TS-03 | ROS 2 / DDS topic for velocity command | Unauthenticated publisher injects a velocity setpoint while robot is in protective stop | Severe: motion during a stop state | High: any node on the network segment | Reduce: SROS2 authentication plus safety-controller gate | | TS-04 | IMU gyro input to balance or heading estimate | Resonant acoustic excitation corrupts rate signal | Major: loss of control or false heading | Medium: speaker plus resonance scan | Reduce: sensor selection, mechanical isolation, plausibility check |

Fault-tree view: why redundancy does not help

TOP: Robot moves toward person at unsafe speed, no protective stop
 |
 +-- AND ----------------------------------------------------------+
 |                                                                  |
 +-- Safeguarding function does not trigger                         |
 |     |                                                            |
 |     +-- OR                                                       |
 |          +-- Channel A (camera + model) says "no person"         |
 |          +-- Channel B (lidar + model) says "no person"          |
 |                                                                  |
 +-- Shared-cause event: crafted stimulus corrupts A and B together |
       (modeled as independent: P = P(A) x P(B)                     |
        modeled as one attack: P = P(attack succeeds) )             |

If the analysis multiplies the channel probabilities, the top event looks remote. If the analysis treats the attacker as a single cause, the top event probability is the attack success probability, and the published figures above are not small. That is the whole argument in two lines.

Derived requirements (excerpt)

IDs are mine. Thresholds are illustrative starting values for a safety concept, not figures from any cited source.

| ID | Requirement | Traces to | Verification | |---|---|---|---| | SR-IN-001 | Each safety function shall list its safety-relevant inputs and, for each, a declared integrity assumption (source, authentication, plausibility range, maximum age). A function with an undeclared input shall not be released. | TS-01 to TS-04 | Specification review; trace check on every input | | SR-IN-002 | The person-detection safeguard shall include at least one channel not based on a learned model, with independent power and data path from the learned channel, and shall command a protective stop on loss of agreement for more than 200 ms. | TS-01 | Architecture review; fault injection with adversarial image set; stop-time measurement | | SR-IN-003 | No motion command shall be accepted from the speech or audio path without a separate authenticated confirmation; audio shall have no authority to cancel a protective stop. | TS-02 | Penetration test; negative test with crafted audio | | SR-IN-004 | Velocity commands on the robot network shall be authenticated and filtered by the safety controller; while a protective stop is active, any non-safety velocity setpoint shall be discarded and logged. | TS-03 | Message-injection test on stop state; log review | | SR-IN-005 | Rate-sensor plausibility monitoring shall flag a gyro versus wheel odometry or second-IMU disagreement above a defined threshold within 50 ms and enter a degraded speed limit. | TS-04 | Acoustic sweep test below 30 kHz; fault injection |

SR-IN-002 will draw the most argument. It says the learned perception stack is a performance function and not a safety function, which is the only position I can defend with a straight face today. If a vendor wants to rate the learned channel, the evidence package has to include something stronger than benchmark accuracy.

What the headline really tells us

The headline is that some research lab fooled a robot with a poster. Read as an engineering statement, it is narrower and more demanding: the safety requirements specification contained rules, and no statement of the conditions under which the rules' inputs could be trusted. Each rule was verified. The assumption underneath was never an artifact, so nobody owned it, and nothing in the verification plan could fail it.

The missing artifact is an input-integrity assumption register: per safety function, per input, who produces it, what proves it is authentic, what bounds its plausibility, and which independent channel disagrees with it. That register is also exactly what 2023/1230 §1.1.9 will ask a manufacturer to show from January 20, 2027, and what a security level assignment under prEN 50742 will need as its first input.

If your risk assessment still has a column called "random hardware failure rate" and no column called "attacker," it is a good document about a different machine.

— Jherrod Thomas, The Lion of Functional Safety™