Fleet operations

Once devices are in the field, the operational surface explodes: who can SSH into a device, who can push firmware, who can pull customer data, who can revoke access when a technician quits. Most teams build this in three uncoordinated places, DevOps, customer support, product engineering, and discover the gap during an incident.

We build it as one layer, designed from the identity model out.

What this covers

• Remote access for fielded devices, short-lived credentials, time-bounded sessions, full audit trail, no shared keys, no permanent SSH.
• OTA updates with policy, signed images, staged rollout, anti-rollback, fleet-side and device-side verification, rollback safety.
• Telemetry and data pull, authorization tied to who-is-asking and what-they're-asking-for, per-tenant and per-device, with privacy controls customers can verify.
• Operator and technician identity, RBAC / ABAC for the humans operating the fleet, with break-glass procedures that don't bypass the audit log.
• Incident response runbooks, what to do when a device is suspected compromised, what to do when a key leaks, what to do when a technician's laptop disappears.
• Customer-facing fleet APIs, third-party developer access to your devices, scoped, revocable, and survivable.

When teams call us

• You're scaling past the size where ad-hoc operations work, typically somewhere between 5k and 50k fielded units, depending on industry.
• You're integrating with a customer's existing IT (enterprise customers often demand SCIM, SSO, audit exports) and the design isn't there yet.
• You're recovering from an operational incident that exposed a weak fleet access story.
• You're adding remote service capabilities to a product line that was originally fire-and-forget.

Related work

Most fleet-operations engagements need Connected identity underneath. The fleet layer is the operational consequence of identity decisions; we can run them as separate scopes or one integrated engagement.