Security Model
A closer look at the building blocks that keep Rover Nexus secure: identity, transport, access control, and auditing.
Identity and enrollment
Every robot has its own cryptographic identity.
- A robot enrolls using a single-use bootstrap token issued by an administrator.
- During enrollment the robot generates its own key pair on the device and submits a certificate signing request. The private key never leaves the device.
- The cloud returns a device certificate that becomes the robot's lasting identity. Enrollment is one-time per robot.
See Enrollment for the operator workflow.
Transport security (mTLS)
After enrollment, every robot-to-cloud connection uses mutual TLS:
- Both the robot and the cloud present certificates and verify each other before any data is exchanged.
- Traffic is encrypted in transit.
- A robot without a valid device certificate cannot connect.
Authorization and roles
Access uses two-level role-based access control, at the organization and fleet level. Permissions are evaluated per action, so people only get the capabilities their role grants. Cross-organization fleet sharing is bounded by a role cap and an optional expiration. See Roles and Permissions and Fleet Access.
Teleoperation sessions
Live video and remote control use WebRTC with short-lived signaling tokens, so authorization for a remote session expires quickly. See Teleoperation.
Auditing
Sensitive actions are recorded to an append-only audit log — including who performed an action, against which fleet or robot, and when. This supports review and accountability. See Auditing.