Open deployment resource
Humanoid Robot Deployment Security Checklist
Use this checklist to turn a release or deployment claim into inspectable evidence across firmware, ROS 2, cloud, autonomy, actuation, detection, stop, and recovery.
scope first • evidence levels stay separate • unknowns remain visible
Start with the decision
A checklist is useful only when it is tied to a named robot, release, environment, operating mode, owner, and decision. Record those first. Then mark each item with evidence, missing evidence, or not applicable—with the reason.
Deployment checklist
1. Deployment decision and scope
- Name the robot, software release, environment, operating mode, and deployment owner.
- State the decisions this evidence must support and the date by which they are needed.
- List excluded subsystems, untested environments, and assumptions that could change the conclusion.
- Define outcomes that must not occur, including unsafe motion, unauthorized command, loss of control, and unrecoverable state.
2. Authority and identity
- Inventory human, service, device, workload, and vendor-support identities.
- Map who can issue, relay, approve, cancel, or override each safety-relevant command.
- Verify credential lifecycle, fleet enrollment, rotation, revocation, and lost-device response.
- Test whether stale, lower-privilege, cross-tenant, or confused-deputy contexts can reach control paths.
3. Firmware, boot, and update trust
- Record boot-chain, firmware provenance, update verification, rollback, and recovery evidence.
- Inventory local debug, maintenance, storage, and hardware interfaces and their production state.
- Verify update authorization and safe failure behavior during interrupted or rejected updates.
- Track third-party components and the exact versions present in the release under review.
4. ROS 2, DDS, and middleware
- Inventory nodes, topics, services, actions, discovery domains, namespaces, bridges, and gateways.
- Map middleware identities and policies to actual operator and device authority.
- Test discovery, impersonation, replay, unauthorized subscription/publication, and command acceptance boundaries.
- Capture evidence that security policy is enabled in the deployed configuration, not only in documentation.
5. Cloud, fleet, and teleoperation
- Map cloud APIs, operator consoles, mobile clients, support paths, queues, and offline behavior.
- Verify tenant, fleet, robot, session, and role boundaries across read and command flows.
- Test revocation, session expiry, replay, delayed command, reconnect, and partial-connectivity behavior.
- Confirm audit data can reconstruct who requested, authorized, relayed, and executed a command.
6. Perception, models, and autonomy
- Identify which sensor, model, retrieval, policy, or planning outputs can influence control.
- Document confidence gates, operator approvals, constraints, fallback modes, and safe degradation.
- Test malformed, stale, adversarial, and conflicting inputs without equating simulation with physical proof.
- Record model, policy, prompt, configuration, and data versions used for every material observation.
7. Actuation and physical consequence
- Trace each safety-relevant command from origin to actuator and identify every enforcement point.
- Verify rate, range, state, workspace, payload, human-proximity, and mode constraints where applicable.
- Separate command reachability, acceptance, execution, and independent physical consequence as distinct proof levels.
- Authorize physical tests explicitly with stop conditions, observers, exclusion zones, and recovery procedures.
8. Detection, stop, recovery, and retest
- Define the telemetry and alerts that should reveal each tested failure path.
- Verify independent stop, degraded mode, isolation, rollback, and restoration procedures.
- Capture time-to-detect, time-to-stop, and recovery evidence where the scope supports it.
- Tie every remediation to the affected invariant and an explicit retest condition.
Deployment evidence packet
Keep one record per material claim or scenario. The packet should be reviewable by someone who did not run the test.
- Decision, owner, target version, environment, date, and scope
- System map, actors, authority, trust boundaries, and control flows
- Invariant or claim being evaluated
- Baseline, test variation, expected observation, and actual observation
- Proof level: design, configuration, simulation, runtime, physical consequence, recovery
- Source artifacts, commands, logs, screenshots, hashes, timestamps, and tool versions
- Finding, implication, missing evidence, remediation, and retest status
- Final supported, unsupported, unknown, or blocked decision statement
From checklist to a CFSE evidence trail
CFSE connects the target model, security invariant, scenario, exploration, observation, finding, and remediation so the reason for a deployment decision remains inspectable.
The Physical Authority Surface provides a separate way to record the authority reachable through each path, its scale, supported consequence, and evidence strength.
The public methodology and examples live at CFSE.ai. Attify applies the method in consulting and private team training.
FAQ
No. The checklist helps a team organize scope, claims, evidence, gaps, and retest work. The strength of a conclusion depends on the evidence collected under the named conditions.
Yes. Architecture, source, configuration, simulation, and isolated runtime work can reduce uncertainty early. Mark physical consequence and recovery evidence as missing until it is actually collected.
CFSE provides a structured way to model the system, state security invariants, derive scenarios, run explorations, and connect findings to evidence. This checklist is a deployment-oriented application of that evidence discipline.