Every crewed mission begins with a roster. Before anyone talks about trajectories or burn windows, somebody has to settle who is on the flight, who is on the ground team, and who is allowed to touch which console. Organisations that run cloud systems face the same question every day, and a young discipline called IdentityOps tries to answer the first half of it. This piece compares the two worlds side by side, using spaceflight vocabulary to make the identity vocabulary easier to hold in your head.
The comparison is deliberately analytical. Where a claim comes from the Ops Atlas, it is flagged as the Atlas position. Where it is a space-operations parallel, it is an illustration, not an engineering statement about any real agency.
What IdentityOps actually covers
The Atlas describes the term as emerging, with no formal definition and with vendors drawing the boundary in different places. If you want the full catalogue, the Ops Atlas entry on IdentityOps is a long read that lays out scope and caveats. The short version is an editorial split into three questions. IdentityOps asks who exists and how they prove it. IAMOps asks what those identities may do. AccessOps asks how access is requested, elevated and reviewed.
In mission terms, the first question is the crew manifest and badge office. The second is the console assignment sheet. The third is the change-approval board that signs off on unusual commands. A programme that merges all three into one spreadsheet usually discovers, during its first anomaly, that nobody owns the manifest itself.
Comparison one: the manifest versus the directory
A flight manifest has a property that most corporate directories lack: it is closed at a known moment and reconciled against reality. The count of bodies in the vehicle must match the count on paper, or the countdown does not proceed. A directory is the opposite by default. It grows by accretion, and nobody counts anyone out.
The Atlas places joiner, mover and leaver handling inside the IdentityOps scope, with the HR system as the origin of truth about who belongs. A leaver flow, as the Atlas sketches it, starts at the HR termination, disables the account at the identity provider, revokes live sessions and tokens, pushes a deactivation to connected apps, and writes down the timestamps. The manifest analogy holds: the departure is not complete until every downstream list agrees.
Where the parallel breaks down is useful. A launch manifest is checked by people standing in the same building. A directory is checked by automation talking to dozens of applications, and some of those applications interpret a deactivation message differently from others. The Atlas points out that the standard for provisioning leaves the meaning of an inactive flag to each application, so two apps can respond to the same message in two different ways.
Comparison two: the crew badge versus the live session
Imagine a technician whose badge is cancelled at noon but who is already inside the clean room. Cancelling the badge does nothing about the person who is already past the door. Identity systems have exactly this gap. The Atlas stresses that sessions outlive accounts: an access token issued before the account was disabled can keep working until it expires, and the default lifetime for one major cloud identity provider is on the order of an hour or more, stretching much longer when continuous evaluation is in use.
The flight-operations habit that answers this is the sweep. After a hatch closes, someone physically walks the area and confirms nobody remains. The identity equivalent is an explicit revocation of sessions, followed by a check that the revocation took effect, since the Atlas notes a delay of a few minutes in at least one vendor flow and that revoking at the identity provider does not always clear sessions inside downstream apps.
Comparison three: the mission-control roster versus machine accounts
Ground teams are mostly human and mostly visible, yet a modern mission also relies on pieces of software that act on their own: telemetry collectors, scheduling jobs, data relays. These are non-human identities, and the Atlas gives them a separate lifecycle: inventory them first, register an owner, a purpose, an expiry and a review cadence, favour short-lived credentials, rotate on schedule, and retire them with evidence by disabling, waiting, then deleting.
The space-operations analogue is the payload that nobody remembers commissioning. Satellites left in orbit with no operator are an old problem, and the entire idea of end-of-life disposal exists because abandoned objects do not announce themselves. A service account with no owner is the digital version of that drifting object. It still holds authority, and no human is accountable for it.
How recovery works when a credential is lost
Suppose a flight controller loses the device that holds a second factor. The recovery path is where many organisations quietly fail. The Atlas recommends layering by risk: a self-service route that needs a second authenticator first, an assisted route that releases a one-time pass only after the manager is confirmed on live video or in person, and a privileged route that requires supervised proofing plus a second administrator. A telephone call-back is flagged as unreliable because attackers have shown they can hijack phone numbers.
If you have ever watched a mission rehearsal, the shape is familiar. Routine problems are handled by the operator. Unusual problems need a supervisor to show up. Truly critical problems need two people, in the room, agreeing. The rehearsal is also where weaknesses are found before they matter.
Reading outside the identity bubble
Because this site is about orbits and mission design, a few existing pages here pair naturally with the ideas above. The walkthrough on how a mission timeline unfolds from countdown to operations shows why sequencing and hand-offs matter, which is the same reason the order of steps in a leaver flow matters. And the explainer on the distinct phases a spacecraft passes through is a good model for thinking about identity states: active, suspended, retired, each with its own rules.
Where the comparison teaches something real
The first lesson is that measurement beats assumption. The Atlas works through a leaver example with forty departures, thirty-six disabled within the target window, and three of those still holding an account in a lower-tier application. Counting only the identity provider yields ninety percent; counting through to the applications gives eighty-two and a half. The gap is the same kind of gap as the difference between a manifest that says everyone is out and a sweep that actually finds the straggler.
The second lesson is that strong factors are chosen deliberately. The Atlas notes that only hardware-backed security keys and smart cards count as phishing resistant under the strict reading, and that a rollout should begin with the people who can change the most: administrators of the identity platform first, then those with email, remote and finance reach, then everyone else. This resembles the way a programme certifies the most critical console operators before the wider team.
The third lesson is about the shape of the failures. The Atlas reviews several public incidents and concludes that each one defeated a process, not the maths of the cryptography. A test tenant without a second factor, a service credential left in a personal storage folder, a help desk that reset a login for a convincing caller: none of these required breaking an algorithm. In space operations too, most serious mishaps trace back to procedure and communication, not to physics failing.
Where the analogy stops
The comparison has edges, and they deserve a mention. A spacecraft is a bounded object with a finite number of operators, and a company is a shifting crowd of employees, contractors, partners and automated agents. The pace of change is also different: a mission roster might change monthly, while a large organisation churns identities daily. That is exactly why the Atlas proposes a cadence: daily reconciliation, weekly sampling of recovery events, a monthly report on credentials about to expire, and a quarterly drill.
Another limit is scope. The Atlas is explicit that permission design, access approvals and privileged-session management live next door, not inside, and that the HR process and customer-facing login belong elsewhere. A team that tries to own everything usually ends up owning nothing well. Choose the manifest first.
A starter plan, translated into mission phases
If you wanted to apply the Atlas guidance in a staged way, one reasonable reading looks like this.
- First month, pre-launch checks: name an owner for the identity platform, list every application that holds its own accounts, issue security keys to administrators, and write the recovery script down.
- Second month, ascent: connect the HR feed for one population, automate provisioning for the ten most important applications, and build the first inventory of machine accounts.
- Third month, orbit insertion: add session revocation to the leaver flow, run the first end-to-end drill, and alert on password resets and federation changes.
The expensive ingredient here is patience, not budget: somebody has to count. The Atlas also cautions that a small team may not need a separate practice at all, and that buying a governance suite before the HR data is clean tends to automate the mess.
Closing the comparison
Put simply, crews and credentials share a rule: nobody is trusted merely because they were trusted yesterday. Rosters get reconciled, badges get recovered, and every entry has an owner. IdentityOps is the name some teams are giving to the habit of doing that for software estates. Whether the label sticks matters less than the habit, and spaceflight has been teaching the habit for decades.