Evidence boundary. At the time this Analysis was prepared, USENIX publicly exposed the TAT abstract while stating that the full paper remained under embargo until the conference. The abstract supports the Trajectory Integrity property, the Timed Motion Event Graph design, event and joint measurements, an open-source robotic-arm prototype, a maximum 2.30% memory overhead and 0.14% execution-time overhead, and evaluation against motion-related parameter modifications. The brownfield deployment model and manufacturing scenarios below are engineering interpretations, not claims attributed to the TAT authors.

Execution integrity stops one layer before the physical process

Industrial robotics makes a familiar cybersecurity assumption uncomfortable: a controller can execute trusted software and the physical process can still be wrong. Control-flow and data-flow integrity can tell us useful things about what code executed and how data moved. They do not, by themselves, prove that an arm followed the trajectory the process engineer authorised.

Researchers from Zhejiang University frame that gap as Trajectory Integrity. Their TAT design uses a Timed Motion Event Graph to represent motion semantics and combines event and joint measurements to attest whether actual robot motion conforms to the intended path. On an open-source robotic-arm platform, the authors report at most 2.30% memory overhead and 0.14% execution-time overhead.

Those numbers are encouraging for the prototype. They are not a licence to project the same performance onto a legacy automotive plant, a proprietary controller or a motion task already running close to real-time limits. In OT, average execution overhead is not the only engineering constraint; jitter, worst-case execution time, controller headroom, supportability and safety certification can matter more than a small mean percentage.

What this diagram shows

Software integrity and process integrity are related but distinct. The missing evidence sits between an authorised program and the physical result it was supposed to produce.

From trusted code to trusted motionThe assurance chain is incomplete if the controller is trusted but the authorised physical outcome is not independently evidenced.
Existing assurance evidence Cyber-physical integrity gap
Execution to physical outcome
Authorised logicProgram / recipeExpected task and parameters
→
Execution evidenceTrusted controller codeControl-flow and data-flow can still be valid
→
Integrity gapMotion semanticsDid the arm actually follow the authorised path?
→
Independent evidenceJoint + production measurementsCorroborate the physical operation where consequence justifies it
Decision gate

For this motion, is controller execution evidence sufficient, or does the consequence require independent evidence of the physical outcome?

HIGH CONSEQUENCEAdd independent trajectory or production evidence.
LOW CONSEQUENCEAvoid instrumentation whose assurance value does not justify its operational cost.

The useful question is not whether every robot needs TAT

Consider an illustrative manufacturing scenario: a legitimate application binary remains unchanged while a tool frame, speed value, positioning parameter or process recipe is modified through an authorised engineering path that has been abused. The controller may continue executing expected code. The weld, placement or handling operation can still drift from what production intended.

The first response should not be to build a plant-wide real-time security telemetry platform. Many brownfield sites do not expose robot motion, vision, metrology and process-quality data with the latency, timestamps and semantics required for continuous correlation. Creating that infrastructure purely for cybersecurity can fail both the cost case and the operational ownership model.

A more defensible approach is selective assurance. Start with the motions whose failure can create meaningful safety, quality or continuity consequences. Monitor changes to robot programs, frames, tools, payloads, recipes and motion parameters. Then reuse evidence the factory already produces: vision results, weld quality, torque, metrology, end-of-line measurements or downstream inspection. Cybersecurity does not need to become a second process-control function to ask whether unauthorised change is consistent with a physical deviation.

Independent evidence matters most where authority and consequence meet

IEC 62443 provides a useful basis for system risk assessment, including partitioning industrial systems into zones and conduits and defining security requirements around those boundaries. ISO 10218-1:2025 addresses safety requirements for industrial robots themselves, with application and integration requirements handled by the companion part of the series. These disciplines answer important questions, but neither makes trusted software synonymous with trusted physical motion.

The architecture should also preserve safety independence. A cybersecurity monitor can provide additional evidence about parameter changes or trajectory anomalies, but safety functions should remain in independently validated safety logic. The security layer must not become a new common-mode dependency for emergency stop, protective separation or other safety behavior.

This changes the business case. If high-consequence process integrity can be corroborated with evidence already generated for production quality, the marginal cybersecurity cost is far lower than building a parallel sensor fabric. It also keeps accountability clear: production owns process quality; safety owns validated protective functions; cybersecurity owns evidence of unauthorised change and adversarial paths.

In a cyber-physical system, integrity becomes operationally meaningful only when there is enough evidence to connect authorised computation to authorised physical behaviour.
The decision
Use consequence-based, independent evidence to close the gap between trusted robot execution and trusted physical motion; do not assume software integrity proves process integrity.
Operational checks
  • Identify robot motions where deviation can create material safety, quality, tooling or continuity consequences.
  • Monitor changes to programs, frames, tools, payloads, recipes and motion parameters through the actual engineering paths used in production.
  • Determine which existing vision, torque, metrology or inspection evidence can corroborate the authorised physical outcome.
  • Measure controller headroom, jitter and worst-case timing before introducing any runtime attestation mechanism into legacy equipment.
  • Keep safety functions independently validated rather than making a cybersecurity monitor part of the safety control loop.
Where to go next

Continue this decision.

Recommended next · OT & ICS · Critical InfrastructureSafety Independence Must Survive a Cyber Compromise

If control and safety share the same identities, engineering paths or infrastructure, a cyber incident can turn nominal independence into common-mode failure.

→
Prefer audio? Open the companion episode →
Explore further

More on this topic

OT & ICS · SafetyCyber Independence Matters When Safety Layers Share the Same FailureRead →OT & ICS · IntegrityControl Logic Can Be Trusted by the PLC and Still Be MaliciousRead →OT & ICS · AssuranceRecovery Is Not Complete Until the Process State Is DefensibleRead →
Antonio González, PhD
Written by

Antonio González, PhD

Cybersecurity practitioner focused on product security, OT/ICS and cyber-physical systems. Cybersecurity Under Pressure translates incident evidence into engineering and business decisions.

About →LinkedIn ↗
Source record

Sources & further reading

5 cited sourcesHow we source →
← All analysisCompanion episode →