What should organisations do when an employee leaves but the automation remains?

What changes when the employee leaves but the automation stays?

The key issue is ownership, not just access. An automation can keep authenticating after a person leaves, so the organisation must decide whether it still has a valid business purpose, who now owns it, and whether its permissions, secrets, and runtime scope are still appropriate. If the answer is unclear, treat the automation as stale and retire it.

What matters operationally is that machine identity does not “end” automatically with the human who created it. If the workflow still needs to run, it should be reassigned and re-established under current governance, rather than left to continue on inherited trust or undocumented dependency.

Why leaving it running by default is a control failure

An unattended automation can become a standing access path, especially when credentials, tokens, or certificates are long-lived or broadly privileged. That creates a mismatch between the current business state and the technical state, which is how legitimate automation turns into hidden exposure.

This is especially important in environments where service access is tied to scripts, schedulers, CI/CD jobs, or bots. The control question is not “does it still work?” but “should it still exist, and if so, under whose ownership and with what limits?” That is why mature identity hygiene treats automation as part of lifecycle management, not as a one-time setup task.

When automation outlives its owner, the usual failure is drift: permissions are never reviewed, secrets are never rotated, and the system keeps calling resources that no one actively supports. A stable process becomes a latent dependency, which is harder to notice than a human account because it may not trigger normal joiner-mover-leaver checks.

How to retire or reissue the automation correctly

The right response is to make offboarding and workflow change a formal decision point for the machine identity. If the automation is no longer needed, disable or retire it cleanly. If it is still needed, reissue it under a fresh ownership decision, confirm the business purpose, and reset the control assumptions around access, secrets, and approvals.

• Confirm whether the automation is still tied to an active process, environment, or control objective.
• Assign a new accountable owner if the original employee is gone.
• Review what the automation can reach, then reduce permissions to the minimum necessary.
• Rotate or replace credentials rather than assuming inherited secrets remain trustworthy.
• Document the reapproval so the automation has an explicit current purpose.

If the workflow crosses system boundaries or holds privileged access, the reissue step should be treated like a new authorisation decision, not a clerical update. The practical test is whether the automation could still make meaningful changes if its original owner no longer exists in the organisation.

Risk and Threat Considerations

Leaving automation in place after the employee leaves can preserve an access path that nobody is watching. If credentials, tokens, or keys were embedded in the workflow, the result is a durable foothold that may survive organisational change, and in the worst case become available for abuse long after the original justification has disappeared.

Failure mechanism: The identity remains valid while ownership and intent become stale, so the automation keeps exercising permissions that were granted for a previous business context. That can lead to unauthorized use, privilege creep, or delayed detection if the secret is reused elsewhere.

Impact: The organisation inherits an unowned control surface that can expose data, alter systems, or create lateral movement opportunities. Even when no attacker is present, the residual access weakens assurance because no one can confidently explain why the automation still exists or who is responsible for it.

Practitioner Guidance

What to prioritise: Treat automation offboarding as part of employee offboarding and workflow change control. The first decision is whether the machine identity still has a valid purpose, because that determines whether you retire it or reissue it.

What to verify: Confirm the current owner, the business process it supports, and whether its permissions match that process today. If any of those cannot be stated clearly, the automation should be considered out of governance until it is reassessed.

Common mistake: Leaving the job in place because “it might still be needed” is not a neutral choice, it is an implicit approval of hidden standing access. Good practice is to force an explicit reauthorisation when the human owner changes.

Practitioner takeaway: When the employee leaves, the default should be to remove the automation unless a current owner can justify, reapprove, and control it as an active business asset.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• What should organisations do when delegated automation changes role or leaves service?
• What should organisations do when an employee leaves to reduce residual risk?
• Who is accountable when a zombie agent remains active after an employee leaves?