Read Hybrid directories
Access debt is the gap between the access people hold and the access anyone would knowingly approve. It exists in every organisation over a certain age. In a hybrid estate — Active Directory synchronised to Entra ID — it accumulates faster, and it is harder to see.
That is not because hybrid is badly designed. It is because a hybrid estate has two systems of record for the same objects, and the rules governing which one wins are subtle, situational, and different for each attribute.
Here is what actually drives it.
1. Two directories, one identity, no single owner
In a synchronised estate, most user objects exist twice: once on premises and once in the cloud, joined by an immutable identifier. For those objects, on-premises is authoritative and the cloud is a shadow.
Except for the ones where it is not.
Cloud-only accounts get created constantly, and usually for good reasons: a guest for a supplier, a service principal for an integration, an account made during an outage when the sync was down, a break-glass administrator that deliberately does not depend on on-premises infrastructure. Each of these is legitimate. Collectively they mean the sentence “our identities come from Active Directory” is false, and every process built on that assumption has a gap in it.
The leaver process is usually built on that assumption.
2. Group membership means different things on each side
An on-premises security group is a directory object whose membership is explicit and whose nesting is transitive. An Entra ID group might be a synchronised copy of that object, a cloud-only security group, a Microsoft 365 group with a mailbox attached, or a dynamic group whose membership is the output of a rule evaluated against attributes.
These behave differently in ways that matter. A synchronised group cannot be edited in the cloud. A dynamic group’s membership changes when an attribute changes, which means someone’s department being corrected in HR can silently grant access. Nesting support differs between group types and between the services consuming them.
The practical consequence: a review of “group membership” that treats all of these as the same kind of thing produces a document that is technically accurate and operationally meaningless.
3. Deprovisioning is asymmetric
Disabling an on-premises account and letting the change synchronise blocks sign-in reasonably promptly. It does not:
- remove group memberships, on either side
- revoke existing refresh tokens, which can remain valid for a period
- remove delegated access to shared mailboxes
- remove permissions granted directly to the user object on a site or a share
- affect a cloud-only account belonging to the same human being
Most leaver processes do the first thing and stop, because the first thing is what everyone can see the result of. The rest is invisible, so it is nobody’s task. Eighteen months later, the person’s memberships are still resolving, and the only reason it does not cause an incident is that they cannot sign in — which is a control, but a single one, and not the one the auditor was told about.
4. Nesting hides the grant from the person reviewing it
This is the mechanism that turns ordinary untidiness into genuine debt.
Someone needs access to a finance share. Rather than adding them to the group that grants it, an administrator adds a group they are already in — because it is quicker and it works. Now the finance group contains an operations group. Six months later, someone nests a project group inside the operations group for the same reason.
The person reviewing the finance group sees three members: two users and a group. It looks small and well-controlled. It resolves to four hundred people.
Nothing about the review interface makes this visible. Both directories will show you the members of a group; neither will readily show you, for a given resource, the fully resolved list of humans who reach it and the path each of them took. That is the query the organisation actually needs and it is the one that is hardest to run.
5. The migration left objects behind, and nobody kept the list
Every hybrid estate is hybrid because of a migration, and every migration has exceptions.
There are always accounts that could not be synchronised because of a duplicate attribute, groups recreated in the cloud rather than migrated because that was faster, and objects excluded from sync scope by a filter written years ago for a reason nobody recorded. There is usually a document from the time listing these. It was accurate on the day it was written.
Those excluded and duplicated objects are where the oldest, strangest access debt sits — precisely because they are outside the scope of every tool and process that assumes the estate is uniform.
6. The quarterly review confirms rather than examines
Most organisations of this size run access review as a periodic export. A CSV goes to line managers, who are asked to confirm that their people should have what they have.
The manager receives several hundred rows containing group names like SEC-OPS-SHARED-RW and GG-FIN-Legacy-2019. They do not know what those grant. They have no way to find out other than asking IT, which is a two-week conversation for a task that has a Friday deadline. They approve everything, because approving everything is the only action available to them that completes the task.
The review is then evidenced as complete. The auditor sees a completed review. What has been demonstrated is that the process ran, not that anyone looked — and everyone involved knows it, which is corrosive in a way that is hard to quantify but easy to feel.
Why it compounds
Each of these is survivable alone. They compound because each one makes the others harder to detect.
Nesting hides the grant. The asymmetric leaver process means the account holding it never goes away. The cloud-only object means the account is invisible to the process that would have caught it. The migration exception means the object is outside the scope of the tool that would have flagged it. And the review confirms the whole arrangement in writing, once a quarter, which converts an operational problem into a documented assurance that there is no problem.
By the time anyone looks properly, the question is no longer “what needs fixing” but “what is safe to remove”, and nobody can answer that either, because the estate is the only remaining record of what was intended.
What actually helps
Not a bigger spreadsheet.
Resolve effective access rather than listing membership. For any given resource, the answer you need is the set of humans who reach it and the path each took. Everything else is a proxy for that question and every proxy loses the nesting.
Treat both directories as one estate, including the parts that do not line up. Cloud-only objects, sync exclusions and failed synchronisations are not edge cases to handle later. They are where the interesting findings are.
Baseline roles from evidence, not from a workshop. Take everyone doing the same job and intersect the access they hold. The overlap is a defensible proposal for what the role needs. What sits outside it is an exception list short enough that someone will read it — which is the only property that matters, because a review nobody reads is not a review.
Give every grant a record, and show the ones that have none. The value is not in the approved grants. It is in making unapproved access visible as unapproved, rather than indistinguishable from everything else in a list.
Make removal reversible. The reason nobody deletes the group they cannot explain is fear of breaking something. If removal is a recorded, reversible transaction, the cost of being wrong drops to minutes and the estate starts getting smaller instead of larger.
That last point is the one that changes behaviour. Access debt does not persist because people are careless. It persists because, in a hybrid estate, removing access is irreversible in practice and nobody is willing to be the person who broke payroll on a Tuesday.