The Identity Control Map: What Each Control Covers, and Where It Doesn't
Controls aren't on/off. Each one covers a slice of the problem and leaves a residual that someone has to own. A map of the major identity controls, what they actually cover, and the exact gap where the last mile lives.
An architecture diagram draws controls as present or absent: there's an MFA box, a provisioning box, a PAM box, and if the boxes are there, the surface is "covered." Real controls don't behave like boxes. Each one covers a specific slice of its problem and leaves a residual — the part of the job that the control was never built to do — and whether anyone owns that residual is what actually decides outcomes. Every incident I've written up lived in a residual, not in a missing box.
So here is a different diagram. For each major identity control: what it genuinely covers, where it silently fails, and who is supposed to own the leftover. Read the third column as the real map of your attack surface.
| Control | What it actually covers | Where it silently fails (the residual) | Who owns the residual |
|---|---|---|---|
| MFA | Proving a live human holds a second factor at login | Legacy protocols that can't speak it; SMS fallback; accounts where it's optional | Whoever audits coverage, not whoever enabled it |
| SSO / federation | One front door, one strong policy, fewer passwords | Everything that authenticates beside the portal — direct app logins, API keys, legacy binds | Whoever inventories non-SSO surfaces |
| Provisioning (joiner) | Creating accounts with the right access on day one | Access that accretes after day one; entitlements no policy granted | Access review / recertification — usually nobody, continuously |
| Deprovisioning (leaver) | Disabling the human's primary account on exit | Tokens, OAuth grants, service accounts, and shared creds the person touched | Whoever maps identities to their non-human residue |
| Help-desk recovery | Getting a locked-out real user back in | Telling an impersonator apart from a user — especially for privileged accounts | The reset procedure owner, not the agent on the call |
| OAuth / app consent | Letting users connect tools they need | Standing, over-scoped grants that outlive their reason and become the way in | Whoever reviews connected apps as identities |
| Session management | Authenticating the start of a session | A valid session stolen and replayed from new device or geography | Whoever binds sessions to posture and watches replay |
| Privileged access (PAM) | Vaulting and brokering privileged credentials | Privileged secrets sitting outside the vault — in scripts, configs, shares | Whoever hunts hardcoded credentials, like Uber's |
| Access logging | Recording what happened, if enabled | Detection — logs nobody reads, or logs gated behind a paid tier | Whoever operates continuous detection on identity events |
| Non-human identity | (Usually nothing — there's rarely a control here) | The entire lifecycle: issue, scope, own, rotate, revoke machine creds | Almost always no one — the cleanest example of the gap |
| Conditional access | Gating logins on device, location, risk signals | Surfaces the policy doesn't reach; exemptions that quietly accumulate | Whoever audits the exceptions, not the rule |
How to read the map
The first column is what you bought. The third column is what you operate. Vendors sell the second column — the slice each control covers — and they're not wrong about it. MFA really does prove a second factor; PAM really does vault credentials. The trouble is that buying the control is often mistaken for closing the problem, when the control only ever closed a slice of it. The residual is not a defect in the product. It's the part that was always going to be operational labor.
Controls don't fail loudly; they leave gaps. Notice there's no row where the control "broke." MFA worked, SSO worked, PAM worked. What failed was the unaddressed residual beside each one — the protocol MFA can't cover, the credential PAM never held, the session SSO authenticated and then stopped watching. This is why posture reviews that check for the presence of controls pass right up until the breach: presence was never the question.
The fourth column is where the last mile actually is. Run your eye down it. Most entries are a function, not a team — "whoever audits coverage," "whoever hunts hardcoded credentials," "whoever operates continuous detection." In a lot of organizations those functions have no name attached, which is the same as saying the residual is unowned. The non-human-identity row is the limiting case: no control, no owner, growing fastest. Map your own version of this table and the empty cells in the last column are your real risk register — far more honest than a count of which boxes are present.
A control map isn't a maturity model and it isn't a scorecard. It's a way to stop asking "do we have X" and start asking "who owns what X doesn't cover" — which is the only version of the question an attacker cares about.
At Aurelion, the residual column is the whole product thesis — making the unowned slice of each control into something a team can actually see and operate. If this map matches your week, I'd like to compare notes.