On a factory floor at two in the morning, nobody is thinking about identity. The conveyors hum, the vehicles glide between racks, and a supervisor drinks cold tea beside a screen. Yet every one of those machines announces itself to some server hundreds of times an hour, and every announcement carries a credential. Whoever manages those credentials is doing IdentityOps, whether or not the job title says so. Here are six myths I hear in robotics and automation teams, each followed by what the Ops Atlas, the xOps School reference, says when you look closely.

A word about the source. The Atlas calls IdentityOps an emerging discipline with no settled definition, so treat what follows as practical lessons borrowed from the field rather than rules from a standards body.

Myth 1: “Identity is for people, and our fleet is just machines”

Walk through a typical plant and count what signs in: pick-and-place arms reporting to a controller, transport vehicles asking a scheduler for routes, camera nodes pushing images to storage, maintenance laptops, vendor remote-support tunnels. Almost none of those are people. The Atlas files them under non-human identities and prescribes a full life cycle. Start with a head count. Next, write beside each entry the person responsible, its job on the line, its lapse date and the interval between reviews. Favour credentials with short lives, swap them on a calendar, and when a device is retired, switch it off, watch for fallout and only afterwards delete.

The sensor-heavy architecture described in this look at how sensors connect into industrial robots makes the point visually. Every sensor that reports upstream is a source of data someone must trust, and trust begins with knowing which device is which. A fleet with no register of its machine credentials is a fleet whose data cannot be fully believed.

Myth 2: “One shared login for the whole fleet keeps things simple”

It does, until something goes wrong. When a dozen vehicles share one service account, a rogue command cannot be traced to any of them, and rotating the credential means touching every unit at once, which usually means never. The Atlas names shared service accounts as a bad habit among people, and hardware obeys the same logic: tracing and revoking both depend on each actor owning a separate identity.

A better pattern gives each vehicle or arm its own credential with a short life, recorded against an owner. When one unit is retired from service, you remove exactly one identity. Facilities that run automated guided vehicles, covered well in this overview of warehouse automation with AGVs, quickly see why: fleets grow and shrink, and the register has to follow.

Myth 3: “When a technician leaves, disabling their account closes the door”

The Atlas is blunt: disabled is not offboarded. A maintenance engineer’s central login may be switched off on the day they depart, but they might still have a remote session open on a laptop, a token cached in a field tool, a personal account in the vendor’s support portal, and a key to a robot cell’s engineering workstation. Per the Atlas, a default access token on a big cloud identity service is good for an hour or so and longer under continuous evaluation, and cancelling a session is not instantaneous either.

The remedy is a sequence rather than a single click. Log the departure from HR, disable the central account, cancel sessions and tokens, instruct each connected system to switch the user off, and note the clock time beside every step. Then measure end to end. In the Atlas worked example, forty leavers produced a ninety percent score at the central directory and a lower score of 82.5 percent when lingering accounts in lesser tools were counted. A plant has plenty of lesser tools.

Myth 4: “Everyone has multi-factor sign-in, so we are covered”

Ask what kind. Text messages and approve-on-your-phone prompts get counted as a second factor on many dashboards, yet the Atlas does not accept them as phishing resistant. Only FIDO2 and WebAuthn security keys and certificate smart cards do. On a shop floor, smart cards and keys are often a natural fit, because workers already wear badges and tap them on readers.

Here is a pair of figures worth keeping. Say 1,190 of 1,400 staff have enrolled a strong method; that reads as 85 percent coverage. But when just 41,000 out of 62,000 logins actually use it, real usage is around two in three, which tells you weaker routes are still allowed. Measure usage as well as enrolment. And begin the rollout where an intruder would do most harm: the administrators of the cloud and identity layers, then whoever handles mail, remote entry or payments, then the remaining staff.

Myth 5: “Our controllers sit on a closed network, so nobody can phish us”

Networks are closed until someone opens a vendor tunnel, plugs in a laptop or approves a remote-support session. The human routes in are the weak ones. A CISA advisory the Atlas leans on describes a criminal group that rang help desks posing as staff, coaxed credential resets out of them, took over phone numbers through SIM swaps, hammered users with approval requests and even stood up a rogue federated provider. Calling back the number on the screen did not help, since that number could be controlled by the attacker.

For a plant, the lesson is to make recovery stricter than login. Let ordinary staff recover through a second enrolled authenticator. For assisted recovery, hand over a one-time pass only after the person’s supervisor has seen them on camera or face to face. For privileged engineering accounts, insist on supervised identity checks and a second administrator’s approval. Tell the account owner every time a recovery happens.

Myth 6: “We can put identity work off until after the next rollout”

Rollouts are exactly when identities multiply. Each new cell adds controllers, service accounts, maintenance logins and integrations. The Atlas ninety-day outline is deliberately small: in month one, assign owners, write an application register, equip administrators with security keys and draft a recovery script. In month two, connect HR data for one group, push automated provisioning to your ten busiest applications and finish a first pass at the machine-identity inventory. In month three, add session cancellation, run a leaver drill and alert on resets and changes to trusted outside providers.

It adds two cautions that suit lean operations teams. Do not buy a governance product before your HR records are clean, and a very small organisation may fold the routines into existing roles instead of creating a new practice. A workable rhythm: compare the directory against HR records every day, read a few recoveries each week, check which machine credentials are about to lapse each month, and rehearse a leaver each quarter.

What the incidents have in common

The Atlas assembles public cases from recent years: a password spray against a legacy test tenant lacking a second factor; a support-system compromise that began with service-account credentials kept in someone’s personal storage; customer intrusions at a data platform where some passwords sat unchanged for as long as four years. Its conclusion is that each one defeated process rather than mathematics. A robotics team can read that as encouraging news. Process is something you can fix with a spreadsheet, a calendar and an owner.

Back to the factory floor

At two in the morning, the machines will keep announcing themselves. The question is whether you can say, for each one, who owns it, what it may reach and when its credential expires. If the answer is yes, the quiet hum is reassuring. If not, a register is where to begin. The wider scope and the caveats live in the Atlas page devoted to IdentityOps, and it rewards a slow read over a cup of tea, ideally not a cold one.