The Robot Needs an Immune System

Executive abstract

Humanoid robots intended for continuous work cannot be protected by a firewall, an emergency stop and a maintenance calendar alone. Their risk emerges from the interaction of software, electromechanics, energy, communications, artificial intelligence and human surroundings. A cyberattack may become a motion hazard; a drifting sensor may resemble a malicious signal; a thermal excursion may degrade perception before it trips a conventional limit; and an over-the-air update may repair one vulnerability while changing timing behavior elsewhere. The central thesis of this chapter is that future Physical AI systems require a distributed cyber-physical immune system: an architecture that continuously establishes identity, observes health, detects abnormality, contains propagation, selects a bounded response, verifies recovery and learns across the fleet.

This is not a claim that robots can literally reproduce biology. The immune-system metaphor is useful because it changes the design question from “How do we prevent every failure?” to “How does the system distinguish acceptable variation from harmful change, respond proportionally and regain a trustworthy state?” The answer combines functional safety, cybersecurity, reliability engineering, predictive maintenance and runtime assurance. Semiconductor capabilities—secure identity, protected key storage, safety microcontrollers, diagnostic sensors, deterministic communications, memory protection, power monitoring and local inference—form the evidence-producing substrate on which that resilience depends.

From protection to resilience

Traditional robot assurance is often divided into departments. Cybersecurity protects data and access. Functional safety controls hazards caused by malfunction. Reliability engineering reduces random failure. Maintenance restores worn systems. AI governance addresses model behavior. That separation is administratively understandable but technically incomplete. A humanoid robot is one physical system, and its incidents do not respect organizational boundaries.

NIST Cybersecurity Framework 2.0 organizes cybersecurity risk around Govern, Identify, Protect, Detect, Respond and Recover, emphasizing that protection is only one function in a broader lifecycle NIST CSF 2.0. NIST guidance for operational technology similarly stresses that cyber controls must account for performance, reliability and safety because operational systems directly affect the physical world NIST SP 800-82 Rev. 3. These principles become more demanding in a mobile robot. The asset is not enclosed in a cabinet; it changes location, manipulates objects, shares space with people and may depend on cloud or fleet services whose availability is not guaranteed.

A resilient robot therefore needs more than perimeter protection. It needs a continuous internal argument for why its present behavior should still be trusted. That argument must be based on evidence: cryptographic identity, measured software state, sensor plausibility, timing integrity, current and temperature signatures, actuator response, battery condition, communication quality, mechanical wear indicators and mission context. No single signal is decisive. The system must fuse them into a bounded operational judgement.

What an immune system means in engineering terms

The proposed cyber-physical immune system is a distributed control and assurance architecture, not a single security processor or AI model. It performs six linked functions.

The biological analogy has limits. Engineering systems should not autonomously “learn” new response rules in safety-critical paths without governance and validation. An immune response that is too weak allows propagation; one that is too aggressive can disable a healthy robot or create a hazard. The core design problem is therefore proportionality: responding strongly enough to control risk, but no more strongly than the evidence justifies.

Identity: defining the robot’s trusted self

A robot cannot detect unauthorized change unless it has a protected reference for authorized state. The foundation is a root of trust that supports immutable or strongly protected identity, authenticated boot, key protection and measured state. Secure boot answers a narrow but essential question: are the software components being launched signed by an accepted authority and allowed by policy? Measured boot and attestation extend the question by recording what actually loaded.

NIST SP 800-193 describes a protect-detect-recover model for platform firmware, including mechanisms intended to resist unauthorized change, detect it and restore a trustworthy platform NIST SP 800-193. In a humanoid, this logic should not stop at the central computer. Joint controllers, battery-management systems, safety controllers, sensor modules, communication gateways and service tools all participate in the robot’s state. Each needs an identity and lifecycle model appropriate to its risk and resource constraints.

Remote attestation allows a component or robot to present evidence about its state to a verifier. The IETF RATS architecture separates the attester, evidence, verifier, appraisal policy, attestation result and relying party IETF RFC 9334. This distinction matters. Attestation does not prove that a robot is safe; it provides evidence that a relying party can use in a contextual decision. A correctly signed but unsafe configuration may attest perfectly. Conversely, a component that cannot reach a remote verifier may still be physically healthy. Availability and safety policy must therefore define what happens when attestation evidence is stale, incomplete or contradictory.

Distributed health sensing: the robot must feel itself

Physical resilience begins with observability. A humanoid may contain dozens of actuators and far more sensing and compute nodes. The immune architecture needs evidence close to where degradation originates, because central logs often arrive too late or omit the physical signature of the event.

Actuation and mechanics

Motor current, phase balance, inverter temperature, encoder consistency, commanded torque, estimated torque, joint acceleration and mechanical vibration can reveal distinct failure modes. A rising current requirement at unchanged load may indicate friction, misalignment or lubrication loss. A position sensor that remains numerically plausible but diverges from motor back-electromotive-force estimates or inertial motion can be identified through analytical redundancy. The objective is not simply fault detection; it is localization and confidence.

Energy and thermal condition

Battery voltage and state estimates, cell imbalance, insulation monitoring, converter temperature and power-rail integrity reveal whether the robot can safely execute a mission or recovery maneuver. Energy-aware monitoring is essential because assurance itself consumes energy. Continuous high-rate logging and inference can reduce runtime and increase heat. Local hardware filters, event-triggered sampling and hierarchical aggregation allow the robot to spend monitoring energy where risk is changing fastest.

Compute, memory and timing

Error-correcting code memory can detect and correct defined classes of memory error; lockstep or diverse cores can expose computational divergence; clock and voltage monitors can identify abnormal operating conditions; and a watchdog can detect missing execution progress. Yet each mechanism has a diagnostic boundary. A watchdog proves that a task reported progress, not that its result was correct. ECC protects against specified bit-error patterns, not maliciously valid data. Resilience comes from combining mechanisms with different failure sensitivities.

Anomaly detection without surrendering safety to a model

Anomaly detection is attractive because not every fault or attack can be enumerated. However, an anomaly score is not a diagnosis. Robot behavior changes with payload, floor friction, battery state, tool configuration, task phase, software version and human interaction. A model trained on narrow laboratory data may treat legitimate field variation as hostile or overlook a dangerous condition that resembles normal operation.

A robust architecture combines three classes of detector. First, deterministic checks enforce physical and logical invariants: current cannot exceed a hardware limit; two redundant position channels must agree within a defined tolerance; authenticated sequence numbers must progress according to protocol. Second, model-based residuals compare expected and observed dynamics. Third, statistical or learned detectors search for multivariate patterns that are difficult to specify manually. The learned layer can prioritize investigation, but safety-critical actions should remain constrained by verified policy and independent limits.

The system also needs provenance. A detection result should carry the software version, model version, calibration state, input quality, timestamp confidence and component identity that produced it. Without provenance, fleet learning can spread false conclusions. A corrupted robot could otherwise poison the maintenance model or cause healthy units to be unnecessarily derated.

Containment: stop propagation before stopping everything

Cybersecurity often uses network segmentation; functional safety uses independence and fault containment; reliability engineering uses redundancy and isolation. The immune architecture unifies these ideas as a fault containment region. A region may be a joint drive, an arm, a sensor cluster, a communication domain, a power zone or a software partition. Its boundaries should limit electrical, computational, communication and authority propagation.

Containment requires mechanisms at several levels. A network gateway may block a compromised node. A memory protection unit may prevent one task from corrupting another. A power switch may disconnect a failed actuator. A safety microcontroller may override a high-performance processor. Credential revocation may remove fleet access while retaining local safe operation. The architecture must anticipate common-cause failures: two redundant channels built from the same software, clock and power source may fail together.

IEC 62443-4-1 treats security as a product lifecycle discipline that includes requirements, secure design, verification, defect management, patch management and end-of-life IEC 62443-4-1. The newer IEC PAS 62443-1-6 explains application of the series to IIoT contexts IEC PAS 62443-1-6. For robot design, the durable lesson is that containment cannot be bolted on after integration. Zones, conduits, update authority and failure responses must be architectural decisions.

Graceful degradation: preserving useful capability inside a safe envelope

A binary choice between full operation and emergency stop is insufficient for many deployed humanoids. A robot carrying a load on stairs, supporting a patient or handling hot material may create more risk by stopping abruptly than by completing a bounded stabilization action. The system needs defined degraded modes.

Graceful degradation may reduce walking speed, prohibit stairs, lower payload, disable one arm, switch from autonomous navigation to supervised control, restrict the workspace or return to a service location. These modes require explicit capability contracts. The mission planner must know not merely that “a fault exists,” but which functions remain trustworthy, for how long and under what constraints.

ISO 13849-1:2023 provides methodology for safety-related parts of control systems in high-demand and continuous modes, while explicitly noting that cybersecurity is outside its direct scope even though security issues can affect safety functions ISO 13849-1:2023. That boundary illustrates why the immune architecture is needed: it does not replace functional-safety engineering, but supplies a cross-domain mechanism for recognizing when safety assumptions may no longer hold.

Recovery is a security and safety function

Recovery is often treated as an IT task: reboot, roll back or reinstall. In a robot, recovery changes physical authority and must be governed accordingly. A restart should not energize an actuator until position, load, environment and safety channels are understood. A firmware rollback should not reintroduce a known vulnerability. A repaired node should not rejoin the control network until identity and state are verified.

The recovery path therefore needs its own protected assets: a trusted recovery image, secure update metadata, rollback protection with an emergency exception policy, retained calibration and a minimal controller capable of maintaining or entering a safe state. NIST SP 800-193’s protect-detect-recover pattern is particularly relevant to this foundation NIST SP 800-193. Recovery should be tested under power interruption, partial connectivity and corrupted storage rather than assumed from nominal update tests.

Runtime assurance can provide an independent path that monitors a complex autonomy controller and transfers authority to a simpler verified controller when defined conditions are violated. This does not make the advanced controller intrinsically safe; it limits the consequence of its departure from an approved envelope. The safety path needs sufficient independent sensing, compute, communication and energy to remain effective during the failures it is intended to control.

Fleet-wide learning without fleet-wide contagion

A fleet offers a powerful advantage: rare events observed by one robot can improve detection and maintenance across many. It also creates systemic risk. A faulty update, compromised signing service, incorrect anomaly rule or poisoned model can propagate faster than a mechanical defect.

Fleet learning should therefore separate observation, hypothesis, validation and deployment. Raw telemetry must be minimized and protected; incident records should be signed and linked to configuration provenance; candidate rules should be tested against representative mission profiles; and deployment should be staged with rollback capability. A new reference value or detector is not trustworthy merely because it came from the fleet.

Predictive maintenance becomes part of resilience when health evidence supports intervention before a failure crosses into unsafe behavior. It should report uncertainty and decision thresholds, not only a remaining-life number. Maintenance models must also account for configuration changes, replaced components and mission severity. A robot performing repetitive lifting on warm factory floors is not directly comparable to one used intermittently in a climate-controlled hospital.

The semiconductor architecture of resilience

The immune system is only credible when its evidence cannot be trivially forged and its responses remain available under fault. This makes semiconductor selection and partitioning strategic architecture choices.

The architecture also changes how value is assigned. A sensor with built-in diagnostics may be more valuable than one with slightly better nominal accuracy. A microcontroller with secure identity, protected update and safety documentation can reduce system assurance effort. A power device paired with accurate current and temperature telemetry becomes part of health estimation, not merely energy conversion. These are causal links from operational resilience to silicon capability, not promotional add-ons.

Lifecycle obligations are converging with resilience engineering

The European Cyber Resilience Act establishes cybersecurity and vulnerability-handling obligations for products with digital elements over their expected use period Regulation (EU) 2024/2847. Regardless of the detailed conformity route applicable to a particular robot, the direction is clear: manufacturers must plan for vulnerabilities, updates, evidence and lifecycle responsibility rather than treating cybersecurity as a release milestone.

ENISA’s robotics guidance frames cybersecurity as a robotics-specific concern because compromise can affect sensing, control and physical interaction ENISA Cybersecurity for Robotics. NIST’s AI Risk Management Framework adds governance, mapping, measurement and management of AI risks NIST AI RMF 1.0. Zero-trust architecture further reinforces continuous, resource-centered verification instead of implicit trust based on network location NIST SP 800-207. Together, these sources support a lifecycle model in which trust must be maintained, evidenced and revised.

Functional-safety standards remain indispensable. IEC 61508 provides lifecycle principles for safety-related electrical, electronic and programmable electronic systems IEC 61508 overview. The immune-system concept should be used to connect—not blur—the assurance claims. Security controls, safety mechanisms, reliability predictions and AI monitors have different evidence bases. Their interactions must be analyzed explicitly, especially where one mechanism can disable, delay or invalidate another.

Engineering trade-offs and failure modes of the immune system itself

A cyber-physical immune system can fail. It can miss a slow degradation, overreact to harmless novelty, consume excessive bandwidth, expose sensitive telemetry, create new privileged attack surfaces or depend on a cloud service that is unavailable during an incident. It can also create organizational complacency if a “health score” is treated as proof.

Several design disciplines reduce these risks. Monitoring must be threat- and hazard-informed rather than indiscriminate. Safety-critical limits should be independently enforceable. Confidence and freshness should accompany evidence. Recovery actions should be rehearsed and bounded. Logs should be tamper-evident but privacy-minimized. Update and model-deployment paths should use staged rollout. Most importantly, the system should fail transparently: when it cannot establish trust, it should declare the uncertainty and move to a defined operating mode instead of silently assuming health.

The trust score is therefore a policy instrument, not a universal scalar. Different missions may make different decisions from the same evidence. A warehouse robot may continue at reduced speed with a degraded camera if lidar and mapped lanes remain available; a hospital robot performing patient support may require immediate human takeover. The architecture supplies evidence and bounded mechanisms. Governance defines acceptable risk.

Ten design principles for a robot immune system

1. Define trusted self explicitly. Maintain authenticated identities, software manifests, calibration state and component lineage.
2. Observe across domains. Combine cyber telemetry with electrical, thermal, mechanical, timing and behavioral evidence.
3. Keep independent safety authority. Advanced detection may advise, but verified mechanisms must bound hazardous action.
4. Localize before acting. Use architectural boundaries and dependency models to avoid unnecessary system-wide shutdown.
5. Design degraded modes as products. Specify capabilities, limits, interfaces and human expectations for each health state.
6. Protect the recovery path. Secure recovery images, keys, rollback policy, calibration and minimum-energy safe-state functions.
7. Attach provenance and freshness. Evidence without origin, configuration and timing context is weak evidence.
8. Learn cautiously across fleets. Separate incident collection, hypothesis formation, validation and controlled deployment.
9. Budget assurance resources. Monitoring needs compute, memory, bandwidth, thermal headroom and energy.
10. Validate the immune system itself. Test missed detections, false positives, compromised monitors, partial power and disconnected operation.

Conclusion: intelligence that can remain trustworthy

The defining challenge of deployed humanoid robotics is not only whether a machine can perform a task, but whether it can continue to make bounded, trustworthy decisions as components age, software changes, environments vary and adversaries probe its weaknesses. Perimeter cybersecurity, static safety functions and periodic maintenance remain necessary, but they do not form a complete resilience strategy.

A cyber-physical immune system provides a durable architectural synthesis. It establishes identity, gathers distributed evidence, evaluates health, detects deviation, contains propagation, degrades capability deliberately, recovers through protected paths and converts verified fleet experience into better maintenance and assurance. Its intelligence is not concentrated in one model. It emerges from coordinated trust mechanisms across sensing, control, compute, communications, actuation and energy.

Semiconductors are the substrate of that argument. They anchor identity, produce diagnostic evidence, isolate faults, enforce timing and authority, protect memory and keys, monitor power and enable local inference. The future trustworthy robot will therefore be judged not only by peak capability, but by the quality of its evidence about itself—and by how safely it acts when that evidence says something is wrong.