Leaver access is the control almost every organization believes is working, and one of the few that can be checked in an afternoon. Match the leaver list against the dates accounts were disabled. The gap between them is the finding, and on many tenants the log that would show it was deleted weeks ago.
Somebody asks whether leavers lose access promptly. The answer comes back quickly and with confidence: yes, HR tells IT, and IT disables the account the same day. Nobody is lying. It is what everybody involved believes happens.
Then somebody asks to see it. The procedure exists, so the request is for dates: which people left in the last year, on what day, and on what day each account was disabled. That question usually takes a week to answer, and the answer is rarely "the same day".
This piece describes the test, where each date it needs actually lives, and why it is worth running before anybody else runs it for you.
The output is a list of names with two dates and a number of days beside each. That list is the evidence. A procedure document describing what should happen is not.
Leaver access fails in a specific way. The process is written, the people running it are competent, and it works most of the time. What goes wrong is the handoff: HR records a leave date, and that date reaches IT late, partially, or not at all. Contractors and agency staff often do not appear in the HR system in the first place, so nobody tells IT they have gone.
None of that is visible from the procedure. A document saying accounts are disabled on the last working day describes an intention. The leaver test measures what happened, person by person, and it is the measurement a customer questionnaire, an insurer or an auditor is actually asking for when they ask the question.
In our view it is also the single best early test of a security program, because it crosses the line between two departments. A control that only one team runs can be made to work by that team. A control that needs HR and IT to act on the same fact, on the same day, tests whether the organization works as one.
This is the part that stops most attempts, and it is worth knowing before you start.
In Microsoft Entra ID, the account's enabled state is a yes or no. The account records whether it is enabled. Nothing on it records when it stopped being. The date lives only in the directory's audit log, and Microsoft's published retention for that log is seven days on the free tier and thirty days on P1 or P2. The sign-in log has the same limits.
In on-premises Active Directory, disabling a user generates event 4725 on the domain controller, provided the User Account Management auditing subcategory is enabled. That event names the account disabled and the account that disabled it. It survives as long as the Security log does, which is set by log size rather than by date, and on a busy controller that can be days.
Read the third column first. If the disable dates only exist for thirty days and nobody exports them, a twelve-month test is not possible and the first finding writes itself.
So the honest version of the test often begins with a smaller question: can we establish disable dates at all? If the answer is no, that is not a reason to abandon the test. It is the most useful finding it produces, because it means nobody can currently prove the control operates, including the people who run it.
One attribute to avoid. Active Directory's lastLogonTimestamp looks like it should help, and it is designed for finding inactive accounts rather than for this. With default settings Microsoft documents it as running nine to fourteen days behind. A leaver who signed in the day after leaving will not show it.
Once you have both dates, subtract them. Report the gap per person, in days, sorted worst first. Do not report an average. An average of two days across forty leavers can hide one account that stayed enabled for four months, and that account is the only one anybody will ask about later.
Decide in advance which HR date you are measuring from. Last working day and contractual end date can be weeks apart, especially where garden leave is involved. Either is defensible. Mixing them is not, and the choice should be written beside the results.
A reasonable target is the same day for anybody leaving on bad terms and within one working day for everybody else. That is our position rather than a requirement, and your own policy may say something different. What matters is that the policy states a number and the test measures against it.
A disabled account cannot obtain new tokens. It can still use the ones it already has.
Microsoft's guidance on revoking user access describes the mechanics. Access tokens issued by Entra ID last one hour by default, and an application using one keeps working until it expires. Applications that maintain their own sessions keep them until those sessions end, or until the application is told the user has gone. A device that is offline keeps whatever data it holds locally. The same guidance treats revoking the user's sessions as a separate step from disabling the account: Revoke sessions in the admin center, or Revoke-MgUserSignInSession in PowerShell.
Only the first row ends at the moment of disabling. The others end on their own schedule or after a second action, and the leaver checklist is where those actions have to be written down.
For the test, this means the disable date is necessary and not sufficient. The sign-in log for the period after each leave date is the second check. A sign-in after leaving is a finding regardless of when the account was disabled, and it is the one that becomes an incident.
The test as described only covers people HR knows about. The accounts most likely to survive belong to people who were never in the HR system:
The inverse test catches these. Take every enabled account and confirm it has a current owner. Any account whose owner has left, or whose owner nobody can name, goes on the same list as the leavers.
None of this needs new software. It needs two exports, a spreadsheet, and a decision about which date counts as leaving. Most organizations that run it for the first time learn something about the handoff between HR and IT that the procedure did not tell them.
Our Joiner, Mover and Leaver Standard is free and editable. It sets out the leaver process step by step, including the second actions that disabling an account does not take, and the quarterly reconciliation that produces the evidence described here.
If step two stopped you
Complete our free readiness assessment, send us the result, and we will spend forty-five minutes going through it at no charge. If our view is that you can close this yourself, we will say so and tell you how.