ISO 10218:2025 and IEC 62443 for Robots: The New Cyber Risk-Assessment Mandate

What changed for cybersecurity in ISO 10218:2025?

The 2025 edition makes cybersecurity a required part of robot safety, where earlier editions largely did not address it. ISO 10218 is the core safety standard for industrial robots and robot systems, split into part 1 (the robot) and part 2 (integration and the robot system). The third edition modernizes it and adds an explicit expectation to consider and assess cybersecurity risks that could affect safety.

The reasoning mirrors the EU Machinery Regulation: a robot whose safety functions can be defeated by a cyberattack is not safe. So cyber risk assessment moves from good practice to a standards expectation you have to satisfy and document.

Why is a robot cyber risk assessment now mandatory?

Because the standard uses requirement language ("shall") for assessing cybersecurity risk, an integrator or manufacturer following ISO 10218:2025 must perform and document one. The assessment identifies threats to the robot and robot system, evaluates how they could lead to hazardous situations, and drives the security measures needed to reduce that risk to acceptable levels.

This is not a paperwork exercise. It sets the security requirements the rest of your controls must meet, and it is the anchor auditors will look for. Doing it well means understanding your robot’s real attack surface, which is where a structured robot penetration test and a clear threat model feed directly into the assessment.

How does ISO 10218 defer to IEC TS 63074 and IEC 62443?

ISO 10218:2025 does not reinvent security requirements; it points to the established industrial security framework. IEC TS 63074 addresses the security aspects that affect functional safety of machinery control systems, bridging the safety world to security. From there, the detailed controls come from the IEC 62443 series, the widely adopted standard for industrial automation and control system security.

This chaining is deliberate and useful: it means robot cybersecurity aligns with the same framework used across industrial control systems, so the evidence and vocabulary are portable to auditors who already know 62443.

What IEC 62443 controls apply to robots?

The most relevant parts are the security levels (SL 1 to 4) and the component requirements in IEC 62443-4-2, plus the secure-development lifecycle in 62443-4-1. Security levels let you target a defensible posture against a defined class of attacker. The component requirements cover foundational areas that map cleanly onto a robot:

• Identification and authentication, which per-robot cryptographic identity satisfies.
• Use control and least privilege, which the authorization gate enforces per action.
• System and data integrity, which firmware attestation and tamper-evident provenance provide.
• Auditability, which verifiable receipts deliver.

How do IEC 62443 security levels map to a robot cell?

IEC 62443 grades protection by the capability of the attacker a zone must withstand, from SL 1 through SL 4, and the useful move is to assign a target level per zone rather than one level to the whole site. A robot cell is rarely a single zone: the fleet management network, the robot controllers, and the actuation path have different consequences when they fail, so they warrant different targets.

The reason this matters for robots specifically is that the published exploit record sits above SL 1 and often above SL 2. Wormable radio-range compromise of a humanoid line, hard-coded credentials shared across a model family, and unauthenticated command execution on a controller are not casual violations, and a zone protected to SL 1 or SL 2 is not scoped for them. See the embodied AI threat landscape for what has actually been demonstrated.

Two foundational requirements do most of the work at SL 3 and above, and both are architectural rather than procedural. Identification and authentication control means each robot is a distinct principal with its own credential, not a member of a model line sharing one key, which is what per-robot attested identity provides. Use control means an authenticated principal is still constrained to permitted actions, which is what a deny-by-default pre-actuation gate provides at the point that matters, in front of the actuator.

Recording the target level per zone, the achieved level, and the gap between them is also the clearest artifact to hand an assessor. It converts a security posture into something reviewable, and it makes the residual risk explicit rather than implied.

How do you document a compliant risk assessment?

Record the assets, threats, and hazards; assign a target security level; specify the controls; and show they operate. A defensible assessment ties each identified threat to a concrete control and to evidence that the control works, not just that it was specified. That last part, showing controls actually operate, is where most robot programs are weak.

Attestation closes that gap. Per-robot identity demonstrates authentication, the gate demonstrates use control, and provenance demonstrates integrity and auditability, all as verifiable artifacts you can attach to the assessment file.

How does attestation provide the required evidence?

Attestation turns each IEC 62443 control area into continuous, checkable evidence rather than a one-time claim. Instead of asserting that a robot authenticates, you can show attested identities; instead of asserting integrity, you can show firmware attestation results and a tamper-evident action log. This maps the abstract requirement to something an auditor can verify.

Honest scope: RankShield helps you meet ISO 10218:2025 and IEC 62443 and produces supporting evidence; it does not certify compliance or replace your assessment. It is a standards-native way to make your controls demonstrable. See how the platform works or request early access.

Frequently asked questions