The engineer left; the integration did not

Research in 2026 put residual application access among departing employees in the high eighties as a percentage, and formal processes for revoking machine credentials at offboarding in the low twenties. Those two numbers describe the same gap from opposite ends.

Part of Machine and signing identity

Two numbers that describe one gap

2026 research on residual access reported that a large majority of departing employees — figures around 89% in one study — retained access to at least some corporate applications after departure. A separate 2026 analysis reported that only around a fifth of organisations have a formal process for offboarding and revoking API keys, with the great majority of secrets remaining valid days after exposure.

Read those together and the mechanism is obvious. Offboarding is thorough about the things it knows about — directory accounts, email, laptops, badge access — and structurally blind to the things it does not.

Note the sampling caveat before quoting either figure: these come from vendor studies with their own populations, and the percentages vary considerably between them. The direction is consistent; the precision is not.

What a departing engineer actually leaves behind

Walk through a realistic four-year tenure. A platform engineer creates, in the ordinary course of work:

• Personal access tokens on the source control platform, for local tooling and scripts.
• Service accounts in cloud environments, created to make something work on a Tuesday.
• Webhooks connecting systems, authenticated by shared secrets in configuration.
• API keys for third-party services the team evaluated and adopted.
• CI/CD credentials for pipelines they built.
• Database users created during a migration and never removed.
• OAuth grants to tools they authorised on behalf of the workspace.

None of those appears in an offboarding checklist, because no system knows they exist as a set belonging to a person.

Why the link does not exist

The fourth row is worth dwelling on because it is the fastest-growing path. Infrastructure as code means credentials are created by automation running under a pipeline identity, so the audit log names the pipeline. The human who wrote the code is two systems away.

The measurement

Before proposing anything, produce the number: machine credentials created per engineer per year.

1. Pick one platform — the source control system is usually easiest — and export credential creation events with the creating principal for twelve months.
2. Divide by engineering headcount.
3. Repeat for the cloud environment and one significant SaaS platform.
4. Sum. Report it as a range across platforms rather than a single figure.

The number is typically in the tens per engineer per year. Multiplied by tenure and headcount, it is the size of the population offboarding does not touch.

Creator binding

The fix is to make credential creation an act with a signature, so the link exists by construction rather than by log correlation.

{
  "type": "manav-stmt/1",
  "action": "machine_credential_created",
  "credential": "[identifier, platform]",
  "purpose": "[why it exists]",
  "scope": "[permissions]",
  "notAfter": "[expiry]",
  "creator": "[named individual, credential assertion]",
  "transferable_to": "[team or role, on departure]"
}

The last field matters operationally. Offboarding should not be a deletion sweep — most of these credentials are load-bearing. It should be a transfer decision, and the transfer target should have been named when the credential was created, by the person who knew what it was for.

What offboarding becomes

A query rather than an archaeology project. Retrieve every credential the departing engineer signed for, present the list to their manager with the stated purpose and transfer target, and require a decision on each: transfer, or revoke.

That is a ten-minute conversation instead of a quarterly discovery sweep, and it happens at the moment when the person who knows the answers is still reachable.

The uncomfortable first sweep

Creator binding only works for credentials created after adoption. Everything that already exists has no creator record, and finding the owners is the archaeology this design exists to prevent.

There is no clever answer. Run discovery, assign what you can, expire what nobody claims after a notice period, and accept that some of the estate will be orphaned permanently. The value of the design is that the problem stops growing.

What survives an offboarding

Objections and honest limits

“We review access on departure.” You review their account's access. The things they created are not in their account's access list, which is exactly why they survive.

“This is a discovery problem.” It is a creation-time problem. Recording who created an identity costs nothing at creation and is impossible to reconstruct afterwards, which is the whole argument.

Binding creation to the creator

1. Record the creating human on every identity. At creation, as a signed fact.
2. Make departure trigger a review of what they created. Not only what they could access.
3. Expire creator-bound identities on departure by default. Unless explicitly reassigned.
4. Reassign as a signed act. So the new owner accepts it knowingly.

Terms used here

Personal access token

A credential created by a user for programmatic access, which typically outlives their account.

Creator binding

Recording which human created an identity or credential, at the moment of creation.

Reassignment

Transferring accountability for an identity to a new owner — which should be an explicit act.

Frequently asked questions

Should offboarding revoke everything the person created? No. Many of those credentials run production. The decision is transfer or revoke, made by someone who knows what the credential does — which is why the purpose and transfer target are recorded at creation.

What about credentials created by automation? They inherit the chain from the human who authorised the automation's scope. The accountable person is the one who signed that delegation.

How reliable are the 89% and 20% figures? They come from vendor studies with their own populations and vary between sources. Use them for direction, and measure your own estate for a number you can defend.

Where should we start? The platform where engineers create the most credentials, which is usually source control. One platform instrumented beats five planned.

Why doesn't access review catch these? Because they are not in the departing user's access list. They were created by that user and are owned by nothing.

Can this be fixed retrospectively? Poorly. Creator binding costs nothing at creation and cannot be reconstructed reliably afterwards.

What should happen on departure? Identities they created expire by default unless explicitly reassigned as a signed act.

Sources and further reading

• 2026 research on residual application access among departing employees.
• Federal Reserve — Fedwire Funds Service
• FCC — protecting consumers from SIM swap and port-out fraud
• Published insider incident analyses involving credentials created by former employees.
• OWASP — Non-Human Identities Top 10
• NIST SP 800-57 Part 1 Rev. 5 — key management