For identity engineers and directory owners
Disablement in your directory should end access everywhere within a bounded window, a team change should remove the entitlements that came with the old team, and neither should depend on anybody remembering. This page says which of those are automatic here, which still require a person, and how long a live session survives.
Onboarding gets designed. Somebody maps roles to groups, writes the automation, tests it with a pilot cohort and demonstrates it to a steering committee. Offboarding gets a ticket queue. The asymmetry is structural: joining is visible and urgent because a new colleague cannot work, while leaving is invisible and nobody complains when it is late.
The result is the finding that appears in nearly every access review — accounts belonging to people who left, entitlements belonging to a team somebody moved out of two years ago, and a small number of accounts nobody can attribute to a human at all. The people running the review already know they will find these; what they cannot predict is which platform they will find them in.
The mover case is worse than the leaver case and gets a fraction of the attention. Someone transferring from one function to another keeps every entitlement they had, gains the ones the new role needs, and over a decade accumulates a set of permissions no single role would ever have been granted. Nothing triggers a removal because nothing was disabled.
Then there are the accounts outside the directory entirely. The integration account created during implementation, the shared credential in a runbook, the local login a vendor asked for during a support call in a crisis. Each was reasonable at the time, none belongs to a person who can be offboarded, and collectively they are what an attacker finds first.
And there is the session question, which almost never gets asked and almost always matters. Disablement in the directory stops the next sign-in. It does not necessarily stop a session already running, and the gap between those two events is a number most vendors have never measured and cannot state.
Access ends reliably only when the directory is the sole authority and no local account exists beside it — because any account the directory does not govern is an account offboarding cannot reach, and nobody discovers it until an access review or an incident.
The arrangement is that your identity provider is the only way in. Authentication is federated through it, there is no local password to set, and there is no alternative login path preserved for convenience. That last clause is the one that carries the weight — most access failures come not from a missing feature but from a second door somebody kept open because it was useful during implementation.
Provisioning and deprovisioning follow your directory rather than a separate administration screen here. Group membership on your side determines entitlement on this side, so a mover keeps the entitlements their new groups grant and loses the ones their old groups granted, without anybody performing a removal. That is the mover case, and it is the one worth testing during evaluation because it is the one most arrangements get wrong.
On the session window, the honest position is a number rather than an adjective. A disablement in your directory ends the next authentication immediately. An already-running session is revalidated against your directory on a bounded interval rather than trusted for its full lifetime, so the worst case is that interval rather than a token expiry hours away. Ask for the number. A vendor who answers "immediately" without qualification has either engineered something specific and should be able to describe it, or has not measured.
Machine access is treated as the same problem rather than a separate one. An integration credential belongs to a named owner, carries an expiry, and is visible in a list you can review — not created during implementation and remembered by nobody. Where a credential reaches into your estate, it is one you issued, and revoking it on your side ends the connection without a request to us.
What still requires a person is stated rather than glossed: the initial mapping between your directory groups and the roles here is a deliberate configuration performed once with your team, and changing that mapping later is a change you make rather than one that follows automatically from a directory change. The membership is automatic; the meaning of a group is yours to define.
Whether any account exists outside your directory — measured by a written statement that no local password path exists, testable by attempting one.
Time from disablement to refused authentication — measured by disabling a test identity and attempting to sign in immediately afterwards.
Time from disablement to a running session ending — measured by the stated revalidation interval, confirmed by watching a live session after a disablement.
Whether a team change removes old entitlements — measured by moving a test identity between groups and confirming the previous entitlement is gone.
Visibility of every machine credential — measured by a list showing each integration credential, its named owner and its expiry.
Whether an access review needs our cooperation — measured by answering who could reach what, entirely from your directory and your log stream.
no claim that entitlement mapping maintains itself — the correspondence between your groups and the roles here is configured deliberately with your team and changing its meaning is your decision. No claim of an independent attestation of any of this; a SOC 2 Type II attestation is in progress and no report exists yet. No claim to govern accounts in systems we do not operate.
Federation through SAML or OpenID Connect, with your directory as the sole authority. Provisioning and deprovisioning driven by group membership rather than by an administration screen here. Nothing that requires a local password, and no alternative login preserved as a fallback — a fallback path is the mechanism by which every offboarding guarantee eventually fails.
Authentication and entitlement events land in your log stream directly, which is what makes an access review answerable without asking us for a report about ourselves. A vendor-authored access report is the weakest artefact available for a question your auditors will ask in writing.
Where privileged support access is needed, it is a grant you make rather than a standing capability we hold, it carries a time bound, and it is exercised through your directory like any other access. A support arrangement that requires a local account here has reintroduced the exact problem this page is about.
Every property on this page is designed rather than independently attested, and for an access-control subject that distinction deserves to be stated twice. A design intent about deprovisioning is a real position and it is a weaker one than an attested control, and your risk register should say which it is.
What partly compensates is that almost every claim here is testable by you in an afternoon, without our cooperation. Disable an identity and try to sign in. Move an identity between groups and check the entitlement. Ask for the credential list. Those tests are more informative than any assurance report, because they exercise the property rather than describing it.
A SOC 2 Type II independent attestation is in progress and no report exists yet, so nobody can be handed one. It is an attestation with a defined scope and period rather than a certification, and access control would be within the scope of the one under way rather than a separate exercise.
And the honest weak point, named because your review will find it: the correspondence between your directory groups and the roles here is a configuration performed once with your team. Membership changes flow automatically; a decision to change what a group means does not. That is a place where a person can get something wrong, and it belongs in the record rather than in a footnote.
Disable a test identity in your directory and immediately attempt to sign in. This is the test everybody assumes will pass and it is worth thirty seconds to confirm rather than assume.
Sign in as a test identity, leave the session open, disable the identity, and watch. The number you are measuring is how long the running session survives, and it is the number most vendors have never stated. Ask for it in advance and then check it.
Move a test identity from one group to another and confirm the old entitlement is gone rather than merely joined by a new one. This is the mover case and it is the one that produces the accumulated-permission finding in your access reviews.
Ask for the machine credential list. Every entry should have a named human owner and an expiry date. An entry with neither is the account that will still be live in three years, and finding one during evaluation is far cheaper than finding it during an incident.
A trial environment with a federation to your directory and one test identity, used to run the disable, session, mover and credential tests before any wider evaluation.
Those four tests take an afternoon and they settle the section of the review that most often stalls a procurement in its final week. Running them first inverts the usual order, where identity is examined last and discovers something that invalidates the work.
The group-to-role mapping is the artefact to produce next, because it is the piece that requires a decision from your side rather than a configuration from ours, and it is where the eventual disagreements live.
Only then does a wider evaluation make sense. An organisation that likes a product it cannot offboard from has created a problem for a colleague two years from now.
They do, and it is the half that rarely fails. Ask the other four questions instead. Does a local password path still exist as a fallback — because that single convenience is how most offboarding guarantees eventually break. How long does a live session survive a disablement, as a number. Does moving somebody between groups remove the old entitlement or only add the new one. And can you see every machine credential with an owner and an expiry. Those four separate the vendors who engineered identity from the ones who integrated it.
It is revalidated against your directory on a bounded interval rather than trusted until its token expires, so the worst case is that interval rather than hours. Ask for the number before you sign and then measure it yourself: sign in, leave the session open, disable the identity, and watch. A vendor who answers "immediately" without describing a mechanism has either built something specific they can explain or has never measured it, and the difference matters precisely in the incident where you are disabling somebody urgently.
That is the harder case and it gets a fraction of the attention, so it is the one worth testing during evaluation. Because entitlement follows group membership rather than a local record here, leaving a group removes what that group granted without anybody raising a removal ticket. Test it directly: move a test identity out of one group into another and confirm the previous entitlement is gone rather than merely accompanied by a new one. The accumulated-permission finding in your access reviews comes from arrangements that fail exactly that test.
They do, and it is usually the first thing an attacker finds. The rule here is that a machine credential carries a named human owner and an expiry at the moment it is created, and appears in a list you can review. Ask for that list during evaluation rather than during an audit — an entry with no owner or no expiry is the account that will still be live in three years, and finding one now costs a conversation instead of an incident.
It should not, and that is the design intent. Authentication and entitlement events land in your log stream, and entitlement itself derives from your directory groups, so the question of who could reach what is answerable from artefacts you already hold. A review that depends on a vendor producing a report about their own access controls is the weakest form of the exercise, and auditors have started saying so.