Stale access, orphan accounts, and what reviews never see

A finished access review is not a finished estate. The campaign closed on the rows it was given, the reviewers clicked, and the percentage went up. The verb that would succeed this morning may never have been a row. It may be a membership left behind by someone who left, an account with nobody to call, or a permission sitting on a principal the campaign was configured not to load. The owner can be diligent and still brief the percentage, and the percentage will not mention what it excluded.

What the campaign is actually looking at

Open the scope, not the completion chart. A governance platform reviews identities it has aggregated, entitlements it has modelled, inside a population someone marked in scope. That sentence is the whole horizon. Anything outside it cannot be approved and cannot be revoked by the campaign, because there is nothing to click. Programmes read silence as health because the dashboard has no red cell for an application that was never connected.

The usual scope is narrower than "everyone we know". Active employees. Sometimes contractors with a current end date in the HR feed. Sometimes guests. Almost always, the configuration excludes disabled accounts, because reviewing disabled accounts feels pointless and because the reviewers complain. Service accounts are included only when a connector brought them in and a person mapped them to a cube. Application permissions are included only when someone built that entitlement. Local accounts on a system the platform has never seen are not a population the scope screen can express. You cannot exclude what you cannot name, and you also cannot include it. The scope screen's confidence is the confidence of a form.

Write the scope down in words a deputy can check. Who is in. Who is out. Which applications in the neighbourhood have a connector. Which entitlements were mapped, and when the mapping was last compared to the object column rather than to last quarter's catalogue. A review of a model that has drifted is a review of a story. Reviewers can be careful and still certify the story. Care is not sight.

Lay the last campaign next to the Monday table and mark every verb the campaign could not have failed. Not "should have failed", as a wish about reviewer quality. Could not have failed, because the row was absent, excluded, or pointed at an object that no longer matches the verb. Those marks are the review gap. They belong to the owner of the fourth statement. Training helps a person decide on a row they can see. It does not create the row.

Stale is a grant that outlived its reason

Stale access is not an account that looks old. It is a verb that still succeeds for a reason that has expired. The person moved team and kept the group. The project ended and the access package did not remove the membership. The contractor's end date passed and a direct role assignment remained, because the leaver workflow disables the account it knows and does not walk nested groups, synced groups, or app role assignments. An activation window can end while the group membership remains. Stale is a time word. The test is still the morning test. If it succeeds, and the reason you would give for it is a reason from last year, the grant is stale and alive. Alive is the part reviews forget, because "stale" sounds like dust.

Joiner-mover-leaver is built for a human record with a manager and an end. It works to the extent the estate is that shape. The failures are structural. A mover's old access is a pile of groups nobody wants to break, so the mover process adds and does not remove. A leaver's account is disabled in the dir ectory the HR feed knows, and a second account, the privileged one, the local one, the break-glass one excluded from that feed, stays enabled. Here the same exclusion is a review failure. The campaign often excludes the account too, for the same fear. Two processes agree not to look. Agreement between processes is not evidence the verb died.

Synchronised membership is staleness with a sync engine. A reviewer who removes a cloud group member, and whose removal does not survive the next sync, has completed a task in the campaign and left the grant. The owner of the fourth statement checks the next cycle. The campaign will not check for them. Campaigns close. Sync cycles. If your chain column says synced, a review that only writes to the cloud copy is a review of the copy that loses.

Direct role assignments go stale more quietly than groups, because the leaver's group membership is what the pretty report shows. Look at roles stuck to the account. Look at eligibility that remains after the person has changed job, waiting for an activation the new job does not justify. A role nobody has activated is not can this morning, and it is still a grant the review can certify by accident if the screen only asks whether anyone is "using it". A review that certifies eligibility because "they are not using it" has certified the form.

Application permissions do not go stale when the human who consented leaves. Admin consent outlives the meeting. The principal remains. The secret may be rotated by a careful pipeline team, and the permission list is untouched. If the campaign reviews a user's group memberships, the app role never becomes stale there. It is simply absent, and absence is not freshness. Get-MgServicePrincipalAppRoleAssignment will show the permission the campaign did not ask anyone to judge. Run it for the principals in the neighbourhood before you congratulate a mover-leaver rollout that only speaks human.

Orphan is an empty who-cell with a living verb

An orphan account is an account that can still act, or that still exists to act, and has nobody you could call. Your job is the local count. Rows on the Monday table whose who-cell is empty or weak, split by whether the verb is wide.

Orphans are made, not found. A leaver process disables the human and leaves the service account that was correlated to them, or was requested by them and never correlated properly. The workload's verbs hang off a disabled identity the campaign skips. That is an orphan created by a successful leaver process. A shared user-assigned managed identity loses its owner because each team thinks another team has it, and the identity does not die when one resource dies. A system-assigned identity is less prone to that particular orphanhood, because it dies with the resource, and more prone to a different one: the resource is still there, the person who understood it is not, and the role assignment remains standing. A pipeline variable outlives the contractor who pasted it. An agent created with a permission set and an empty exit is a grant with nobody to end it.

One public case was an elevated account, owner already gone, meeting a help desk that could still reset it. Check for that shape by joining leaver dates to privileged accounts and to accounts excluded from the leaver feed. The service-desk reset is itself a verb. If it is standing, and the targets include orphans, a review of "service desk operators" as a job title has not looked at what the role can reach. The morning test does not care that the right feels like the job.

Elevated has to be a verb or it becomes a label. It means the orphan can do something that changes other people's access, money, production, or secrets. A stale guest who can read one public site is an orphan. An orphan that can grant roles, read mail at tenant scale, or pull production secrets is a different fact. This chapter only stops you treating the empty who-cell on a wide verb as a documentation issue.

Non-human orphans are the case reviews are built not to see. A review started from the governance platform cannot see what the platform never ingested. The Monday method started from manifests and from people who run systems so this population could appear before a connector did. If your orphan count comes from "accounts in SailPoint with no manager", you have counted the catalogue's orphans. The estate's orphans are the ones the catalogue missed, plus the ones it hung on a disabled cube.

The campaign will not do the comparison for you. The owner of the answer, or the deputy, lays the last review against the table in the same monthly brief. Leavers from the window you can name honestly: disabled in Entra is one fact, and group membership that remains, direct roles, principals with credentials still valid, and local accounts in the neighbourhood are the next facts. You will only find the local accounts by asking or by reading the store. Any verb that survives is stale access the campaign is structurally unlikely to show if the disabled user was out of scope. Empty and weak who-cells stay unfilled until you have counted them. Standing plus an empty who-cell is the orphan that matters in the brief. A requested window with nobody accountable will not be closed when it ends. Break-glass with an empty who-cell is the row you hoped not to find. A cleanup that only deletes disabled human accounts moves a different number.

The resource list is the same comparison from the other end. For the handful of resources whose verbs are wide, principals on the resource that were not in the campaign are the review gap made concrete. Inherited grants, local accounts, and service principals with app roles are the usual unmatched names. A campaign of group memberships will not mention a key vault access policy that names a managed identity. The identity has no password, the campaign has no entitlement, and the policy grants the verb every morning. Expected vault silence, plus a missed resource list, is how "we reviewed privileged access" coexists with a standing workload.

Record each miss with the evidence pointer you already use. The reviewer did the task they were given. The scope was the failure.

The screen the reviewer is given

Even inside the rows the campaign does contain, the screen shows an entitlement name, a description if someone typed one, a last-login hint if the connector supplies it, and a button. It does not show the chain. Nested groups arrive as the outer name. Synced membership does not announce that a removal will be overwritten. An application permission, if it appears at all, appears as a string the reviewer has not been taught to read. "Mail.Read" looks like a product capability. It is a grant. The campaign will not translate the string into a verb.

Last login is the cruellest column, because it feels like evidence. An account that has not signed in for a year looks stale. A service principal does not sign in the way a user does, and a secret used by a daemon does not always leave the interactive sign-in log the column was built from. No login can mean unused, or it can mean unused by humans while a job runs every night. The resource pass is the correction. If the principal is on the resource and the job is in the manifest, absence from the sign-in log is not a revoke recommendation. If you let reviewers revoke on empty login columns, you will break a batch job and then stop revoking anything, which is the other failure.

A review that asks "is this role still needed" will get a yes, because some slice of the role is needed. Needed-in-part is how wide grants survive. Ask which verb, and which object, and let the unneeded verb be its own row so a yes does not protect it. The lie a group tells, that the name describes the verb, is the sentence on the screen. Lay the Billing-Readers row on the re viewer's screen and the name is plausible. The screen does not offer the verb, reset credentials on the billing user store. A careful manager approves it. You can predict the approval without accusing anyone of negligence. The campaign could not fail a grant it was not shown. If membership is synced, a cloud removal can also come back with the next cycle, leavers included.

A diagram of zones and crown jewels feels like the resource pass, and it is not. It shows where traffic was supposed to go. The verb shows what an identity can do once it is already inside, or when it never needed the path you drew. Start from identities, resources, and actions. One of the public cases was a permission a diagram would have coloured out of scope. The permission was the scope.

If a security team has already paid for a diagram, use it only as a list of resources you might have forgotten to open. Do not use it as the list of rows. Resources on the diagram that have no access list in your table are gaps in your work. Identities in your table that have no box on the diagram are not mistakes. They are the point of starting from the other end. Architecture can be true at the packet layer and silent at the grant.

"Out of scope, non-human" and "out of scope, legacy" do not move the population to someone else's review. If application teams claim to review access, ask for the last one and join it to the table. Disabled-account exclusion will be offered as common sense. The disabled human drops out, and the grants that do not need that human to be enabled stay in the estate. Walk the leavers, or change the exclusion.

The count that belongs in the monthly brief is how many verbs in this neighbourhood the last campaign could not have failed. That count, beside the campaign's own completion number, is the briefing. If you only have time for one of them, keep the gap.

A miss you refuse to mark until a connector exists is a miss you have agreed to keep. The sheet is the review of what the platform does not hold.

Some of the rows the campaign did see were approved, or excluded from policy, for a reason that was called temporary. The reason is now the way the system works. A review can see an exception and still pass it, because the exception is documented, and documented has been allowed to mean controlled. It is not an orphan problem. Those rows have owners, tickets, and a story.