Cybersecurity–Safety Integration: L2 ADAS · L3/4 ADS · Mobile Physical AI

Abstract: L2 driver assistance, L3/L4 autonomous driving, and humanoid and passenger-carrying quadruped robots share one cybersecurity methodology yet differ in who is responsible, how they are regulated, and how deeply cybersecurity couples with safety. This post systematically maps the requirements, differences, standards/regulations, and best practices across the three families, with a focus on how deeply cybersecurity integrates with functional safety (FuSa), SOTIF, and whole-machine safety.

Key takeaways

1. All three families have entered the “cybersecurity is an entry gate” stage, but with a clear gradient: L2 is enforced, L3/L4 has the highest bar, and mobile physical AI is weakest yet fastest-moving.
2. The essence: L2 treats the network as an information asset, L3/L4 as a safety system, and physical AI as a physical safety device.
3. Integration: L2 is coordinated, L3/L4 is integrated/converging, and mobile physical AI is mechanistically unified but method-empty.
4. The adversarial AI surface (data poisoning, evasion, model theft) is the common new gap in 2026, under-covered by 21434/62443.
5. Best practices are highly shared (TARA, defense in depth, SBOM, secure OTA, monitoring, pentest, PIA) and transferable across bodies.

1. Framework: three threads + two axes

Three threads decide requirements: whether a human bails out, what physical environment the system operates in, and what the regulator can grab. L2 has a human fallback, L3/L4 has none, and mobile physical AI controls the physical body and balance — deciding whether cybersecurity is an “information asset problem,” a “safety system problem,” or a “physical safety device problem.”

Two axes decide coupling: coupling necessity (driven by fallback and physical consequence) and methodological maturity (driven by whether standards are in place and whether a joint argument method exists). The two axes are inversely correlated across the three products.

2. Shared engineering base

• Risk-driven: TARA as the starting point, STRIDE threat identification, attack feasibility (ISO/SAE 21434 attack potential, CAL 1-4).
• Defense in depth: secure boot, HSM/trusted execution environment, code signing, encrypted communication, network zoning, runtime IDPS.
• Full lifecycle: concept—development—production—operation—decommissioning.
• Supply chain & SBOM: CycloneDX/SPDX, CVE monitoring, supplier constraints and joint risk assessment.
• Secure update & OTA: signature verification, rollback protection (UN R156 / ISO 24089 / GB 44496).
• Verification & red team: static analysis, fuzzing, penetration testing, fault injection.
• Privacy & data compliance: minimization, PIA, encrypted storage/transfer (GDPR / China DSL & PIPL).
• AI-specific additions: adversarial robustness, sensor redundancy, model/data poisoning defense, runtime model monitoring — the common new dimension.

3. L2 ADAS: mandatory, “don’t interfere, don’t leak”

Requirements & regulation

• China: GB 44495-2024 (whole-vehicle information security) was set for 2026-01-01; Amendment No. 1 (2026-01-28) delayed it ~6 months, narrowed scope to M/N (trailers no longer mandatory), and adjusted filing/review.
• EU: UN R155 (cybersecurity + CSMS, new types 2022-07, all new vehicles 2024-07) and UN R156 (software updates + SUMS); ISO/SAE 21434 and ISO 24089 as technical basis.
• China complements: GB/T 46194-2025 (identical adoption of 21434, 2025-10-05), GB/T 44899-2024 (2025-09-01), GB/T 40861-2021, GB 44496-2024.

Threat focus

• Remote attack (T-Box/IVI, app), CAN injection/tampering, malicious OTA, OBD, Bluetooth/WiFi.
• Data: location, driving behavior, PII leakage; vehicle “zombified” for DDoS.

Relationship to safety (FuSa & SOTIF)

The driver remains fully responsible; cybersecurity protects “assistance not interfered, data not leaked.” Weak coupling/coordination — the goal is not to be interfered with, not for the system to carry consequences after an attack.

4. L3/L4 ADS: attacks change driving decisions, the bar is highest

Requirements & regulation

• On top of R155/R156: UN R157 (ALKS, the first L3 type-approval regulation), EU GSR 2019/2144.
• ISO/TS 5083:2025 (ADS safety — design, verification, validation) defines cybersecurity as assets sufficient to resist threats to the ADS and its components, explicitly including malicious tampering of the driving environment (perception spoofing, scenario injection).
• ISO/PAS 8800:2024 (road vehicles — safety and AI) extends ISO 26262 and ISO 21448 to AI systems.
• Global: ADS GTR approved 2026-06-25 (jointly led by China, EU, UK, US, Canada, Japan), expected 2027-01; China’s ADS safety mandatory standard published for comment 2026-06-17, targeted 2027-07-01.
• GB 44497-2024 (automated driving data recording, DSR).
• Three-line review: ISO 26262 + ISO 21448 + ISO/SAE 21434.

Threat focus (a whole order higher than L2)

• Perception spoofing: adversarial samples on camera/radar/LiDAR, GNSS spoofing, roadside unit forgery.
• Control & decision: domain controller compromise rewriting planning/control; cloud dispatch and remote monitoring as new surfaces.
• V2X: message forgery, replay, sybil — mitigated by the C-V2X certificate system (ICA/ECA/PCA, pseudonym certs, SM algorithms, YD/T 3957-2021).
• Model & data: training-data poisoning, HD-map tampering.

Relationship to safety (FuSa & SOTIF)

Strong coupling/integration: an attack becomes a SOTIF “triggering condition” and a FuSa “hazard source”; the system must provide a minimal-risk condition (MRC/MRM) and safe degradation. Responsibility shifts: L3 system within ODD + driver handover, L4 system owns the DDT with remote oversight.

5. Mobile physical AI: weakest today, fastest evolving

Requirements & regulation

• No UN R155-like cybersecurity type approval; cybersecurity enters via safety-standard clauses.
• ISO 10218-1:2025 (industrial robot safety) adds a cybersecurity chapter and a “transmission category TC” concept, aligned with IEC 62443.
• ISO 13482 (service robots) 2024 revision adds clause 6.15 “cybersecurity & data privacy” as mandatory.
• Mobile/humanoid standards (in development): ISO 26058-1 (ground-mobile, statically stable), ISO 25785-1 (dynamically stable legged/humanoid), ISO/IEC TS 22440 (industrial AI bipeds), ISO 3691-4 (driverless trucks).
• Base functional safety: ISO 13849 / IEC 62061 / IEC 61508 (PL/SIL), ISO/TS 15066 (collaborative).
• EU: Machinery Regulation 2023/1230, AI Act 2024/1689 (autonomous robots as high-risk AI), Cyber Resilience Act 2024/2847 (full application by end-2027).
• China: humanoid & embodied AI standard system (2026, network & data security section); GB/Z 218.1-2026 (embodied AI data quality, part 1: real data, 2026-08-27).

Threat focus (triple)

• Physical harm: motion-control hijacking, zero-distance contact, collision/crush.
• Perception & model: visual/voice adversarial spoofing, deepfake instructions, model/data poisoning; cloud “brain” and LLM interfaces.
• Privacy: biometrics, home environment, behavior data; open ecosystems and supply chain widen the surface.

Passenger-carrying quadruped special case

ISO 13482:2024 removes “passenger transport robots” from its scope — passenger-carrying robots are losing their old standard’s coverage, and a dedicated standard has not arrived. A passenger-carrying quadruped has dual “vehicle” and “robot” attributes; its passenger is the highest-safety subject, so cybersecurity should align with L3/L4 minimal-risk-state logic plus the robot-specific “stability/falling” dimension.

6. Cross-family comparison

7. Cybersecurity × safety (FuSa & SOTIF / whole-machine) integration degree

Four-level ladder

• L0 Separation: FuSa/SOTIF and cybersecurity run independently; an attack is not treated as a hazard source.
• L1 Coordination: shared risk register and interface review, one-way security-informed-safety / safety-informed-security checks, but processes and evidence chains remain separate.
• L2 Integration: an attack is treated as a hazard/triggering condition, folded into joint HARA+TARA analysis, requiring a post-attack safe state (MRM, degradation).
• L3 Unification: network and physical safety are mechanistically inseparable — the control loop is both the safety mechanism and the attack surface; safety standards write cybersecurity clauses in directly, but the unified argument method is still maturing.

Placement

Dual-axis insight

Splitting “coupling necessity” and “methodological maturity” into two axes yields an inverse mismatch: the more a domain needs Safety–Security integration, the less mature the methodology. That is not a coincidence — the automotive industry took twenty years to make 26262/21448/21434 joint review routine, and robotics has just entered this stage. Whoever first turns the four-way joint argument — functional safety + SOTIF + cybersecurity + adversarial AI robustness — into a reusable method for physical AI owns the definition.

Whole-machine safety interface

• Vehicle whole-machine safety = FuSa (ISO 26262) + SOTIF (ISO 21448) + crash/passive safety + ADS safety (ISO/TS 5083, ISO/PAS 8800, UN R157) + data recording (GB 44497). Cybersecurity coupling concentrates on “attack → driving hazard,” i.e., task-level coupling.
• Robot whole-machine safety = risk assessment (ISO 12100) + machinery functional safety (ISO 13849/IEC 62061/IEC 61508) + robot-specific (ISO 10218) + collaborative force/pressure limits (ISO/TS 15066) + stability/falling (ISO 25785, in development) + occupant protection for passenger carriers (no dedicated standard yet). Cybersecurity coupling is broader — contact-force exceedance, balance loss, falling, privacy leakage — i.e., physical-level coupling.

The key difference: vehicle safety anchors on the “dynamic driving task” (task-level), while robot safety anchors on “physical contact and stability” (physical-level). The latter is inherently more “unified” yet lacks a mature joint-argument toolkit.

8. Standards & regulations index

9. How to act

• Migrate automotive experience as “engineering discipline,” not by copying clauses; ODD/scenario/CAL grading must be rebuilt for robot task spaces.
• Run robot projects on a “functional safety + cybersecurity + privacy” three-line review, aligned with IEC 62443 and CRA’s Secure by Design.
• Reserve safety-critical design for passenger-carrying quadrupeds along the L3/L4 path (MRC, degradation/stop, event recording, remote-monitoring security), plus the stability dimension.
• Treat “integration degree” as a deliverable methodology, not a slogan.

For cars, cybersecurity means “don’t let people turn the car into a weapon.” For robots, it means “don’t let people turn the robot into a hand.” The latter is closer to the physical world — defining “who bails out and how it couples” matters more than memorizing standard numbers.