How should teams offboard workflows that outlive the employee who created them?

Why This Matters for Security Teams

When a workflow outlives the employee who created it, the real asset is not the person but the automation, service account, API key, token chain, and approval path that keep it running. Offboarding only the human leaves a live control plane behind. NHI Management Group’s Ultimate Guide to NHIs shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and that gap is where dormant access becomes active risk.

This is where identity hygiene becomes workflow governance. Teams often assume a leaver process can close once HR and email access are handled, but automations can keep calling internal systems, cloud APIs, ticketing tools, and CI/CD runners long after the owner has gone. That creates a mismatch between business ownership and effective privilege. The NIST Cybersecurity Framework 2.0 pushes organisations toward asset visibility, risk-based control, and continuous governance, which is exactly what orphaned workflows require. In practice, many security teams discover the workflow only after a failed audit, an access review, or a secrets leak has already exposed it.

How It Works in Practice

Effective offboarding starts by inventorying the workflow itself: which jobs, schedulers, bots, integrations, and secrets it depends on, and which systems it can reach. That inventory should include delegated credentials, not just the human account that originally configured them. The current guidance from NHI Management Group’s NHI Lifecycle Management Guide treats lifecycle control as a continuous process, not a one-time cleanup event.

A practical workflow offboarding sequence usually looks like this:

• Confirm the workflow’s business purpose and assign a named business owner.
• Identify every identity it uses, including service accounts, tokens, certificates, CI/CD variables, and vault references.
• Revoke or rotate credentials that were tied to the departing employee or their delegated authority.
• Check whether the workflow can be reauthorised under a current owner with documented need.
• Disable the workflow if no accountable owner or valid purpose can be established.

For mature environments, the better pattern is to move away from long-lived static secrets and toward short-lived, task-scoped access with explicit approval and expiry. That aligns with Zero Trust thinking and reduces the blast radius if ownership is lost. The NIST CSF emphasis on access management and continuous monitoring fits this model, especially when workflows are embedded in cloud automation or software delivery pipelines. NHI Management Group’s Top 10 NHI Issues also highlights how often secrets remain valid far longer than teams expect, which makes automated revocation essential.

These controls tend to break down when ownership lives in personal vaults, undocumented scripts, or shared CI/CD runners because there is no reliable place to prove who can safely inherit the workflow.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, so organisations must balance revocation speed against the risk of disrupting critical automations. That tradeoff is especially visible for workflows embedded in release pipelines, finance operations, or production integrations where a sudden disablement can halt business activity.

One common edge case is a workflow that was created by an employee but is now used by a team. In that case, the leaver process should not simply delete access; it should transfer accountability, reissue credentials under the new owner, and validate that the workflow still needs the same permissions. Another edge case is emergency or ad hoc automation that was never meant to become permanent. Those should be reviewed against a short retention window and retired if they no longer serve a documented purpose.

There is no universal standard for this yet, but current guidance suggests treating orphaned automation as an NHI lifecycle failure, not a help desk issue. Where the workflow interacts with multiple systems, the highest-risk failures usually come from missed downstream tokens, not the primary account itself. That is why offboarding must include secrets outside the obvious identity store, especially in code, config files, and orchestration tools. The Lifecycle Processes for Managing NHIs section and the Coupang Signing Key Breach are strong reminders that unattended signing and automation credentials can become a material exposure when ownership disappears.

Related resources from NHI Mgmt Group

• Who should own the risk created by shadow SaaS in engineering teams?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?