What should organisations do if offboarding cannot be automated everywhere?

Prioritise the systems with the highest privilege and the weakest governance first. Where automation is not possible, create strict manual controls with ownership, deadlines, and evidence of completion. The programme should measure how much stale access remains, not just how many cases were opened.

Why This Matters for Security Teams

When offboarding cannot be fully automated, the risk is not just administrative delay. It is lingering privilege, stale credentials, and unknown access paths that continue to work long after the business thinks access has ended. For non-human identities, that matters more than for people because service accounts, API keys, tokens, and certificates can remain quietly active across CI/CD, cloud, and integration layers. NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer rotate them consistently.

Security teams often underestimate how quickly manual gaps become systemic. If a key is not tied to a named owner, a deadline, and proof of completion, it tends to survive audits and staff changes alike. That is why current guidance aligns offboarding with control discipline in NIST SP 800-53 Rev. 5 Security and Privacy Controls: the control objective is not paperwork, it is verified revocation. In practice, many security teams encounter the real problem only after an old integration is reused or a forgotten token is exposed, rather than through intentional retirement.

How It Works in Practice

The practical answer is to treat non-automatable offboarding as a risk-managed exception, not as an acceptable steady state. Start by ranking all nhi offboarding tasks by privilege, blast radius, and governance weakness. The highest-risk items are usually production service accounts, signing keys, third-party integration tokens, and vault-stored secrets with broad reuse. NHI Mgmt Group’s NHI Lifecycle Management Guide is clear that lifecycle control only works when ownership, rotation, and revocation are explicit, not implied.

Where automation is impossible, use strict manual controls that behave like a workflow, not a ticket queue:

• Assign a named owner for each offboarding action and a backup approver.
• Set a hard deadline based on credential risk, not convenience.
• Require evidence of completion, such as audit logs, screenshots, or change records.
• Track exception aging and stale access remaining, not just case counts.
• Escalate overdue revocations to identity, platform, and system owners together.

Where possible, reduce the amount of manual work by switching the control primitive from long-lived secrets to short-lived credentials, workload identity, and just-in-time access. That means pairing offboarding with secret discovery, privilege review, and vault hygiene so that the forgotten credential is not left behind in code, chat, or a config file. The broader pattern is consistent with NIST SP 800-207 Zero Trust Architecture: trust should be continually evaluated, not assumed because a lifecycle event was completed. These controls tend to break down in highly distributed environments with unmanaged integrations, where no single team can confirm every credential consumer.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance revocation speed against change-control friction. That tradeoff is real in mainframe estates, vendor-managed platforms, shared cloud accounts, and legacy CI/CD pipelines where automation hooks do not exist or break frequently. In those environments, current guidance suggests using compensating controls rather than waiting for perfect automation.

One useful pattern is to define tiers of manual rigor. High-risk credentials may require two-person approval, same-day completion, and immediate post-revocation validation. Lower-risk access can move on a slower cadence, but still needs documented ownership and periodic review. Where a credential cannot be rotated or revoked immediately, shorten its lifetime, constrain its scope, or isolate its execution path until the next maintenance window.

There is no universal standard for this yet, but the direction is clear: manual offboarding must be measurable, auditable, and time-bound. The point is to reduce the window of exposure, not to pretend the window does not exist. For organisations dealing with the kind of lifecycle failure patterns described in Top 10 NHI Issues, the priority is to make every exception visible until the system can be redesigned.

Related resources from NHI Mgmt Group

• What breaks when organisations cannot inventory tokens and service accounts in SaaS apps?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?