The story below is invented from start to finish. The people, the company and the numbers are made up to illustrate how IdentityOps problems tend to surface for a managed support team, and none of it describes a real client. What is real is the reference it leans on: the Ops Atlas entry on the discipline, published by xOps School, which supplies the practices and caveats woven through the narrative.
Monday: a ticket that did not look serious
Priya ran the weekday support desk for a small managed-services crew that looked after a mid-sized logistics firm’s cloud environment. On Monday morning a ticket arrived from the firm’s finance lead: an expense report had been approved from the account of a former colleague who had left six weeks earlier. The finance lead assumed it was a clerical mix-up. Priya checked the directory, found the account marked disabled, and almost closed the ticket.
Something nagged at her. Disabled six weeks ago, yet used last Thursday. She pulled the sign-in history and found a mobile session still renewing itself in the expense tool. The account in the directory had been switched off, but the application kept honouring a session it had already granted. She recalled a line from the Atlas entry she had skimmed the week before, that sessions can outlive the account behind them, and that revoking them is a separate action.
She revoked the session, confirmed the app now refused the login, and wrote down the times. Then she did what a good support engineer does when the cause is bigger than the ticket: she opened a second one titled “How many other doors are still open?”
Tuesday: counting what nobody had counted
Her colleague Marcus, who looked after the cloud side, offered to help. Together they exported the user list from the directory and from each of the firm’s seven main applications. The result was ugly in a very ordinary way. Eleven people who no longer worked there had a live account in at least one application. Two of those were in the shipping-tracker tool, which the leaver process had never been wired to.
They agreed not to panic and not to blame anyone. The Atlas, they noted, is firm that reconciling against what applications actually hold is more trustworthy than reading provisioning logs, because logs show what the system tried to do. The logs said everything had worked. The exports said otherwise.
The two of them drew a simple picture on a whiteboard: HR records a departure, the directory account closes, sessions are cut, each application gets told, and a timestamp is written at every step. Only the second box had ever been automated. The others were a mixture of habit and goodwill.
Wednesday: the number that changed the conversation
Marcus calculated the firm’s leaver performance two ways. Measured at the directory, it looked respectable. Measured across all seven applications, it was noticeably worse. The Atlas has a worked example with the same shape: the directory-only figure flatters, and the end-to-end figure is the one to publish. Priya prepared a one-page note for the firm’s operations director with both numbers side by side and a proposal for two service levels: close the directory account within four hours of an HR record, and clear every application within a day.
The director’s reaction was the part Priya remembered afterwards. She did not ask for a tool. She asked who would own the number each month. That question, more than any chart, told Priya the firm was serious.
Thursday: the quiet accounts
While looking at the shipping tracker, Marcus noticed something stranger: a handful of accounts with names like “route-sync” and “label-print”, none of them tied to a person. They turned out to be machine identities, created years earlier for integrations. One had a password that had never changed. Nobody could say who owned it.
The Atlas describes a life cycle for exactly this: take an inventory, record an owner, purpose and expiry for each, use short-lived credentials where possible, rotate the rest, and retire with evidence, meaning disable, wait to see what breaks, then delete. Marcus started a spreadsheet. By afternoon it listed fourteen non-human accounts, of which six had no owner. They emailed the likely owners with a polite deadline and moved on.
Friday: the help-desk question
On Friday the firm’s own internal help desk asked Priya’s crew for advice. Someone had phoned in as a new starter locked out of the system, and the desk had been about to reset a password after a call-back to the number on the caller’s screen. Priya paused them. The Atlas, she explained, treats phone call-backs as unreliable because of SIM swapping, and it describes a tiered recovery route: people try a second enrolled authenticator first; for an assisted reset, a one-time pass goes out only after the person’s manager confirms who they are, on live video or in person; and for privileged accounts the proofing is supervised and a second administrator signs off. Every recovery should notify the account holder.
The caller, it turned out, was genuine. But the desk now had a script for next time, and a reason to follow it.
The following month: rhythm, not heroics
None of what the team did needed new software. What changed was cadence. Following the schedule the Atlas suggests, they set up a daily comparison of the directory against the HR list, a weekly look at a handful of recoveries, a monthly list of machine credentials nearing expiry, and a quarterly leaver drill. For a firm that size, a separate identity practice would have been excessive, so the routines were assigned to people already on the support rota.
The first quarterly drill was humbling. A test leaver was disabled promptly, but the shipping tracker still showed an active account two days later. That gap was precisely what the drill was for. Marcus fixed the connector and the second drill came back clean.
What they chose not to do
It is worth noticing the restraint. Priya and Marcus did not push for an expensive governance platform in week one, because the Atlas advises against buying such tooling before the underlying HR data is trustworthy, and the firm’s job titles were still free text. They did not demand security keys for everyone on day one either. They proposed starting with the handful of people who administered the cloud account and the identity service, then moving outward to staff with email, remote and finance access. Small steps, each one measurable, each one owned by a named person.
The moral of the week
Three lessons run underneath the week. A disabled account is not an offboarded person. Counting only at the top of the chain hides the real exposure. And machine identities need owners as surely as people do. Teams that offer managed support can add real value by running the unglamorous routine, a point that fits the role mix described in this guide to common DevOps job titles and how their paths differ, since the work crosses support, cloud and security job boundaries.
It also illustrates a theme from the primer on principles behind dependable software delivery: feedback loops beat heroics. A weekly look at recoveries and a quarterly drill are feedback loops for identity.
A few weeks later, the finance lead sent Priya a short message. She had stopped thinking of the original ticket as a mix-up and started thinking of it as the cheapest audit the firm had ever received. Priya framed the message and, only half joking, pinned it above her monitor. The desk now closes any ticket involving a former employee’s name with a small checklist: session cut, applications confirmed, time recorded, owner informed.
Reading more
The Atlas itself is long and candid about gaps. Its entry describing the IdentityOps discipline and its caveats notes that vendors define the term differently, that licence tiers can gate features such as HR-driven provisioning, and that a small organisation may reasonably skip a dedicated practice. Priya’s firm kept it small, and kept it going.
