They left in March. Their access did not.

Disabling someone's identity provider account revokes a login. It does not revoke the authority that person created while they worked there. Those are different things, and almost every offboarding programme confuses them.

It is a Thursday in October and a platform engineer is doing something unglamorous: rotating credentials in a continuous integration pipeline that has needed attention for a year. She opens the secrets manager and starts working through entries, and about forty items in she finds a personal access token with a comment field that says deploy key, temp, will clean up.

She checks who owns it. The name belongs to someone who left the company in March. Not this March. The March before.

So she does what any competent engineer does and pulls the thread. The token still authenticates. It has write access to four repositories, two of which are production services. Its last successful use was eleven days ago, from an address in a cloud region the company does not operate in, which turns out to be a build runner that has been quietly using it since before the person resigned. That is a relief, sort of. It is also not the point, because for nineteen months a live credential with production write access belonged to nobody, and the only reason anyone found it was that an unrelated piece of maintenance happened to walk past it.

She keeps pulling. By the end of the afternoon she has a list: an OAuth grant to a document conversion service that the former employee authorised against the company workspace, a webhook pointing at a personal domain, a shared login to a vendor portal that was never federated because the vendor charges extra for single sign on, and a service account in the cloud project whose only tag is the initials of the person who created it.

The identity provider account was disabled within four minutes of the termination ticket. HR did their job. IT did their job. The offboarding checklist was completed and signed. And none of it touched any of the things she found, because none of those things were ever connected to the account that was disabled.

Why do former employees still have access?

Because the organisation revoked a login, not an authority, and it has no way to enumerate the difference.

Here is the distinction that the whole problem turns on, and it is worth reading twice. There is authority that was granted to a person, and there is authority that flowed through a person. They look identical on the day they are created and they behave completely differently on the day that person leaves.

Authority granted to a person is what identity governance was built for. Someone is added to a group, the group has an entitlement, the entitlement grants access to an application, and the whole path is recorded in a system that knows the person's name. When employment ends, that path is walked backwards and the access disappears. Provisioning tools do this well. SCIM, the standard for pushing user lifecycle changes to applications, exists precisely to make this reliable. When a company says it has automated offboarding, this is what it has automated, and it genuinely works.

Authority that flowed through a person is different in kind. The person authenticated once, used that moment of authenticated authority to mint a new credential, and that new credential is a first class object in some other system with its own lifecycle. A personal access token in a code host. An access key in a cloud account. An OAuth grant to a third party application. A webhook secret. A service account. An SSH key appended to a file on thirty machines by a configuration run in 2023.

Once created, that object does not name the person in any way the identity provider can act on. It may carry their name as a label, which is helpful for a human reading a list and useless to an automated process. The credential's authority does not derive from the person's continuing employment. It derives from itself. It works because it exists.

The library card that became a key

Think about a member of staff who is issued a building pass. When they leave, the pass is deactivated at the door controller and that is genuinely the end of it, because the pass has no power of its own. It is a claim that the door controller checks against a list.

Now imagine that during their employment, that person used their pass to enter the workshop and cut themselves a physical key to the storeroom, and gave copies to two contractors and left one in a drawer. Deactivating the pass does nothing to the keys. The keys are not claims to be checked. They are the authority itself, and the only way to deal with them is to find every copy or change the lock.

Most modern credentials are keys, not passes. They carry their own authority. This is a design decision that was made for good reasons, because keys work when the issuing system is unreachable, they are fast, and they do not require a network call on every use. Those are the same properties that make them impossible to recall.

How much access do ex-employees actually keep?

Honestly, nobody knows, and the way the available numbers are produced is worth understanding before you quote any of them.

Several vendors have published survey figures in this area. Entro Security's 2025 work on non-human identities and secrets reported that a very large majority of former employee tokens remain active after offboarding, with a figure in the low nineties as a percentage. Security Magazine reported in 2025 on survey work finding that close to ninety percent of former employees retained some access to corporate systems after departure. Both figures are widely repeated.

Treat them as directional, not as measurements. These are vendor and survey figures, and the methodology matters enormously. Surveys of this kind are self selecting, because the organisations that respond to a survey about orphaned access are disproportionately the ones who suspect they have a problem. The definition of "access" varies: a dormant account on a marketing tool that holds no data is counted the same as a live production credential. And a vendor whose product discovers orphaned credentials has an obvious interest in the answer being large.

What the figures do establish, taken together and read charitably, is that this is not a rare failure at badly run companies. It is the normal condition, and every practitioner who has ever gone looking has found something. The specific percentage is much less interesting than the structural fact underneath it.

The consequence shows up in breach data. Verizon's annual Data Breach Investigations Report has for years placed the use of valid, stolen credentials among the leading ways attackers gain initial access, ahead of exploitation of vulnerabilities in many years. That is the demand side of this market. Credentials that outlive their owner are part of the supply.

There is also a documented case shape here worth noting carefully. Public breach notification filings in 2025 concerning FinWise Bank described unauthorised access by a former employee affecting a population reported at close to seven hundred thousand people. Reporting of the specifics varies and the details in filings are limited, so the useful lesson is the shape rather than the number: retained access by a departed insider is not a theoretical risk category, it produces notifiable breaches.

What actually survives when you disable the account?

This is the table that makes the problem concrete. Work through it against your own environment and the discovery problem stops being abstract.

Notice the pattern in the third column. One yes at the top, and then a column of no. Notice also that the fourth column describes ten different operations in ten different systems, most of them manual, none of them verifiable from a central point, and several of them requiring someone to already know the artifact exists.

That is why offboarding programmes never finish. Not because the people running them are careless, but because the task as specified is a search problem over an unknown space. You cannot complete a search when you cannot enumerate what you are searching for.

Why does deprovisioning keep failing?

Three structural reasons, and it is worth separating them because they have different fixes.

Provisioning only reaches what is integrated

SCIM works. It is a good standard and it does what it says. But it only reaches applications that support it, that your organisation has connected, and that were connected before the credential in question was created. Every application that a team adopted with a corporate card and a work email address is outside it. Every internal tool built before the integration existed is outside it. The coverage gap is not a bug in the standard, it is a consequence of the standard operating at the application boundary while credential creation happens everywhere.

Access reviews sample, they do not enumerate

Quarterly access reviews are a compliance control and a useful one. They ask a manager to confirm that a list of entitlements is still appropriate. The list is generated from the systems that report entitlements. A personal access token in a code host does not appear on that list, because it is not an entitlement, it is a credential. The review is answering a different question than the one that matters here, and answering it correctly.

Discovery is a race you re-run forever

The non-human identity tooling category exists to solve exactly this, by scanning systems and finding credentials nobody has claimed. This is genuinely valuable and worth buying if the alternative is nothing. But note what it is: a periodic scan looking for objects that were created without any record of their creation. It is archaeology. Every scan finds some of what exists, the environment changes between scans, and the tool's coverage is bounded by the systems it has connectors for, which brings you back to the first problem.

All three failures share a root, and this is the structural claim of the piece: the authority was never issued in a form that could be revoked as a group. Each credential was minted independently, with its own lifecycle, in its own system, with no cryptographic relationship to the human who created it. There is nothing to pull. The only recovery is to go and find each one.

We call this failure Revocation Non-Propagation, and it is one of the fourteen structural failures in the Identity Failure Map. Its sibling is Identity Discontinuity, which is the failure to maintain a thread between the same human across the events of an employment relationship, covered in detail in the post on identity continuity from interview to offboarding.

Why are AI agents making this dramatically worse?

Because agents mint credentials, and because the authority an agent holds names the agent.

Consider the sequence. An engineer configures an agent to handle a recurring task. To do the work, the agent needs access, so the engineer creates an API key, or authorises an OAuth grant, or provisions a service account, and gives it to the agent. The agent runs on a schedule. It does useful work for months. The engineer moves to a different team, and later leaves the company.

Now ask the offboarding question. Whose authority is the agent operating under? In the systems it touches, the answer is: the service account's. That account has no relationship to the engineer beyond a label. The agent will keep running, keep working, and keep holding production access indefinitely, and the only signal that anything is wrong is that eventually somebody wonders what it does.

Multiply that by the fan out ratio. One person operating a handful of agents, each of which needed its own credentials, produces a spray of authority that names no human at all. We wrote about this pattern at length in the post on identity fan out, and about how authority becomes unenumerable in the authority graph. Offboarding is where the two problems meet and become expensive.

There is a supply chain dimension too. The self replicating worm activity that hit the npm ecosystem beginning in September 2025, reported on by Elastic Security Labs, Kaspersky's Securelist and others, worked by harvesting exactly this class of artifact: developer credentials, cloud tokens, and continuous integration secrets, then using them to propagate. Long lived credentials that nobody is watching are not merely an audit finding. They are fuel.

What would it take to make offboarding one operation?

Issue authority as a chain anchored to the human, so that revoking the anchor invalidates everything beneath it.

The idea is not complicated, and it is not new in spirit. Certificate authorities have worked this way for decades: a certificate is signed by an issuer, the issuer by another, and a verifier walks the chain to a root it trusts. Revoke the intermediate and everything under it stops validating. The novelty here is applying that structure to the everyday operational credentials that people create during their work, and anchoring the root at a human rather than an organisation.

Concretely: when someone joins, they enrol a key on a device they hold. That enrolment produces a signed employment root. From then on, when a credential is minted for them or by them, it is issued under that root as a delegation, carrying a scope, an expiry, a depth limit and a revocation identifier.

# At issuance. Every credential is minted under the human's signed root.
authority.issue(
  under:         "root:emp:4471",              # the signed employment root
  kind:          "github_pat",
  delegateKey:   "ed25519:9c1f...",
  scope:         { actions: ["repo:read", "repo:write:manav-sdk"] },
  constraints:   { ip_cidr: "10.0.0.0/8" },
  notBefore:     "2026-01-08T00:00:00Z",
  notAfter:      "2026-04-08T00:00:00Z",
  maxChainDepth: 1,
  revocationId:  "rev:emp:4471:pat:github:1"
)

# At termination. One operation, not a scavenger hunt.
authority.revoke_root("root:emp:4471",
  reason: "employment_ended",
  at:     "2026-03-14T17:02:00Z"
)

The verifier side is what makes this different from a database flag. A system holding one of these credentials does not have to call your identity provider to find out whether it is still good. It walks the chain and checks signatures against a published key.

def verify(chain, published_key, status):
    # Walk from the leaf credential up to the human root.
    for i, link in enumerate(chain):
        if not ed25519_verify(published_key(link.issuer), link.bytes, link.sig):
            return False                      # forged or tampered link
        if i > 0 and not subset(link.scope, chain[i-1].scope):
            return False                      # scope widened. never allowed
        if now() < link.notBefore or now() > link.notAfter:
            return False                      # outside its validity window
        if status.revoked(link.revocationId):
            return False                      # this link, or its root, is dead
    return chain[-1].issuer == "root:emp:4471"

Read the loop carefully, because each check earns its place. The signature check stops forgery. The subset check enforces that a delegation can only ever narrow authority, never widen it, so a credential cannot grant itself more than its parent had. The time window bounds the damage from any credential that escapes. And the revocation check is the one that matters for offboarding: because the root's revocation identifier is checked on every link, revoking the root at 17:02 on the fourteenth of March causes every credential beneath it to fail verification at 17:02 on the fourteenth of March, in every system that verifies, without any of those systems being told individually.

That is the whole trick. Offboarding stops being a search over an unknown space and becomes a single signed statement. The same mechanism is what makes an emergency stop possible mid incident, which we covered in building the kill switch and in the post on revocation that propagates, and you can see the mechanism running in the last mile kill switch demo.

What the receipt gives the auditor

There is a second benefit that security teams underrate until an audit. Under this model the organisation can produce, for any departed employee, a list of every authority ever issued under their root and its current status, generated from issuance records rather than from a discovery scan.

The difference between those two things is the difference between "here is what we issued and here is proof we revoked it" and "here is what our scanner found this quarter". Auditors testing controls such as SOC 2 CC6.3 or ISO 27001 A.5.18 are asking whether access is removed on termination. One of those answers is evidence. The other is a best effort. The audit trail design post goes further into what makes this class of record hold up.

What this does not fix

Now the honest part, because a version of this argument that claims to solve offboarding would be worth ignoring.

Chains only govern authority that flowed through a chain. This is the big one. A credential minted directly in a cloud console, by someone who never touched the issuance path, is outside the model completely. It has no chain, no root, and no revocation identifier, and revoking the human's root does nothing to it. Every organisation adopting this will have years of pre existing credentials in exactly that state.

So the scavenger hunt does not end, it shrinks. The realistic posture is not "offboarding is now deterministic" but "the share of our authority that is deterministically revocable goes up every quarter, and the archaeology backlog goes down". That is a genuinely valuable trajectory and it is not a solved problem. Anyone selling it as a solved problem is selling you something.

Verifiers must actually verify. A revoked root only stops a credential in systems that check the chain. A system that accepts the bearer token and never looks further will keep accepting it. Coverage is a function of integration work, and integration work is slow.

Developers will route around friction. If issuing a credential under a chain takes ninety seconds and clicking "generate token" takes four, you will get tokens. The issuance path has to be the fast path or the model is theatre. This is a product problem more than a security one and it decides whether the whole approach works.

Short lived credentials solve a lot of this without any chain at all. This objection deserves to be stated at full strength, because it is the strongest one. If every token expired in an hour and had to be reissued through a live authorisation path, orphaned authority would largely evaporate on its own. Where you can do that, do that first. Chains matter for the authority that cannot be short lived: standing grants, third party integrations, service accounts and agent delegations that need to survive between sessions.

Manav has not shipped an enterprise offboarding console. The delegation chain model with scopes, expiry, depth limits and revocation identifiers is real and running, and you can read the mechanics in how delegation tokens work and the developer documentation. A packaged product that inventories a departing employee's authority across a large enterprise is not something we ship today.

What to do this week

None of this requires adopting anything new. The first four items are free and will tell you more about your exposure than any survey.

1. Pick one departed employee from over a year ago. Not a random audit, one person. Try to enumerate every credential they ever created. Time how long it takes and write down where you gave up. That number is your actual offboarding posture.
2. List the personal access tokens in your code host, sorted by age, and match the owner column against your current staff directory. This takes about ten minutes and it is usually the moment the problem becomes real for a leadership team.
3. Enumerate the third party OAuth grants against your workspace, in your identity provider or productivity suite admin console. Look at who authorised each one and whether they still work there.
4. Find every non federated application that people log into with a work email address. Expense reports are the best source for this, better than any scanning tool, because someone paid for each one.
5. Set a maximum lifetime on tokens where the platform allows it. Most code hosts and cloud providers support an organisation level policy for this now. It is the highest ratio of risk removed to effort spent available to you.
6. Give every service account a human owner and an expiry, and treat an unowned service account as an incident rather than a housekeeping item.
7. Add one question to your termination checklist: what did this person create that does not carry their name? Ask their manager and their closest teammate, not the identity provider.
8. Inventory the agents. For each one, write down which human authorised its access and what happens to that access when they leave. If you cannot answer for a single agent, you have found your starting point.

Frequently asked questions

Why do former employees still have access after offboarding? Because disabling their identity provider account ends federated logins only. Credentials that person created, such as personal access tokens, cloud access keys, OAuth grants, SSH keys and service accounts, live in other systems and carry their own authority. Those systems were never told the employment ended, and nothing links the credential back to the person in a way an automated process can act on.

Does SCIM deprovisioning solve orphaned access? Partly. SCIM reliably removes accounts in applications you have integrated, which is genuinely valuable. It cannot reach credentials created outside those integrations, and it has no visibility into applications adopted by teams without central involvement. SCIM handles authority granted to a person. It does not handle authority that person created.

How do you revoke all of an employee's tokens at once? Today, in most environments, you cannot, and you should be sceptical of anyone claiming otherwise. It becomes possible only if credentials were issued as delegations anchored to that human's signed root, because then revoking the root invalidates everything beneath it for any system that verifies the chain. Credentials issued outside that model still require individual revocation.

What is chain anchored revocation? It is issuing every credential as a signed delegation under a root key held by the accountable human, carrying a scope, an expiry and a revocation identifier. A verifier walks the chain to the root and checks each link. Revoking the root causes every credential beneath it to fail verification immediately, without contacting each holding system.

Are the statistics about ex-employees keeping access reliable? Treat them as directional. Figures in the high eighties and low nineties as percentages come from vendor and survey research that is self selecting, and the definition of access varies widely between a dormant marketing tool account and a live production credential. The structural point stands regardless of the exact number: this is the normal condition rather than an unusual failure.

Do short lived credentials make this unnecessary? Where you can use them, they are the better answer and you should. An hour long token cannot become orphaned authority. Chains matter for what cannot be short lived: standing third party grants, service accounts, integrations and agent delegations that must survive between sessions without a human present to reauthorise.

How do AI agents change offboarding? They multiply it. An agent configured by an employee typically runs under a service account or API key that names the agent, not the person, so it survives their departure invisibly and keeps its production access. If you cannot say which human authorised each agent's access, you cannot offboard anyone who configured one.

Sources

1. Verizon, Data Breach Investigations Report, annual series on initial access vectors including use of valid credentials. verizon.com/business/resources/reports/dbir
2. Entro Security, State of Non-Human Identities and Secrets, 2025, vendor research on token persistence after offboarding. entro.security
3. Security Magazine, 2025 reporting on survey findings that a large share of former employees retain access to corporate systems. securitymagazine.com
4. Kaspersky Securelist, analysis of the self replicating npm supply chain worm and the developer and cloud credentials it harvested, 2025. securelist.com
5. Elastic Security Labs, research on the same npm supply chain campaign and its propagation through continuous integration credentials. elastic.co/security-labs
6. IETF RFC 7644, System for Cross-domain Identity Management: Protocol (SCIM), the provisioning and deprovisioning standard. datatracker.ietf.org/doc/html/rfc7644
7. IETF RFC 7009, OAuth 2.0 Token Revocation. datatracker.ietf.org/doc/html/rfc7009
8. NIST SP 800-53 Rev. 5, control AC-2 Account Management, including account removal on termination. csrc.nist.gov/pubs/sp/800/53/r5

You cannot revoke what was never issued as revocable. Offboarding is not an HR workflow problem, it is an issuance problem that arrives eighteen months late.