No One's Coming to Deprovision That Service Account

Most security teams, when they start thinking seriously about non-human identities, want to jump straight to lifecycle management. Provisioning, rotation (which doesn’t work), deprovisioning, with the full workflows that are automated and auditable.

I understand the appeal. Lifecycle management is concrete. It's what auditors ask about. And it sounds like a solution.

But I've watched this approach fail enough times to recognize the pattern. The problem isn't the automation. It's the sequence.

The Framework: Four Phases, In Order

After working with dozens of Fortune 500 enterprises on NHI security, we've identified a maturity sequence that consistently works. Organizations that follow it build programs that scale. Organizations that skip ahead end up with sophisticated automation covering maybe 15% of their actual NHI population while the other 85% sprawls unmanaged.

The sequence is: Visibility → Risk Prioritization → Ownership → Lifecycle Management. Each phase creates the preconditions for the next. Skip one, and the whole thing wobbles.

Here's how to think about each phase, what it produces, and why you can't shortcut it.

Phase 1: Build Complete Visibility

Goal: Know what exists before you try to manage it.

You cannot manage what you cannot see. This sounds obvious, but the gap between perceived and actual NHI populations is consistently shocking.

I was on a call last year with a security team at a financial services firm. They'd estimated around 8,000 service accounts across AWS, Azure, and their legacy Active Directory. The actual count ended up being north of 140,000. When we got to the discovery readout, the security lead went quiet, then said: "Some of these are older than half my team."

That's not an outlier. The ratio varies, but the surprise never does.

Human identities get counted automatically—you can't pay someone without them existing in HR systems. But NHIs have no such constraint. They get created in cloud consoles, CI/CD pipelines, Terraform scripts, SaaS admin panels, and secret managers. None of these systems talk to each other. There's no central registry.

Discovery is tedious, sometimes embarrassing work. You'll find service accounts from five years ago created by people who left four years ago. You'll find API keys in repos that everyone assumed were decommissioned. You'll find credentials with admin access that exist for no reason anyone can explain.

The instinct is to rush through this phase to get to the "real" work. Resist it. Discovery is the real work.

What this phase produces: A complete inventory of your NHI population—not just the documented slice, but everything that actually exists.

Phase 2: Prioritize by Risk

Goal: Know what matters before you try to fix everything.

A hundred thousand NHIs is an unworkable number. You can't address them all at once, and you shouldn't try.

Some NHIs have read-only access to non-sensitive data. Some have admin privileges across production systems. Some are actively used every second; some haven't been touched in three years.

Without risk prioritization, you'll either burn out trying to address everything or cherry-pick the easy stuff while the dangerous things fester.

This phase forces uncomfortable questions: What counts as "privileged"? How do you weigh exposure versus permission scope? What's the threshold for "stale"?

Organizations that skip this phase end up with lifecycle policies that treat all NHIs identically—rotating low-risk credentials (don't) on aggressive schedules while high-privilege, exposed accounts sit unaddressed because they're harder to deal with.

Risk prioritization also surfaces the identities that should have been deprovisioned years ago: service accounts attached to decommissioned applications, API keys for integrations that got replaced, credentials that exist because someone once needed them for a project that ended in 2019.

What this phase produces: A ranked view of your NHI population so you know where to focus.

Phase 3: Establish Ownership (This Is Where Programs Die)

Goal: Attach a human to every identity before you ask anyone to approve anything.

This is where most programs stall, or fail entirely.

Lifecycle management requires approvers. Someone needs to authorize provisioning. Someone needs to sign off on deprovisioning. Someone needs to attest, periodically, that an identity is still necessary.

For human identities, the org chart provides this automatically. Every employee has a manager. The chain of accountability is built in.

NHIs have no such chain. The person who created a service account might report to someone who reports to someone, but none of those people necessarily know the account exists or feel responsible for it.

One CISO described the problem to me this way: "I can't delete anything because nobody will tell me it's okay to delete. And nobody will tell me it's okay because nobody wants to be the person who broke production."

Ownership has to be actively constructed. Trace the identity to the workload it serves. Trace the workload to the application. Trace the application to the team that maintains it. Trace the team to a human willing to be accountable.

This involves uncomfortable conversations. It involves people saying "that's not mine" and being right. It involves negotiation about who owns legacy systems that everyone wishes would disappear. It involves, sometimes, executives making calls about accountability that engineers have been avoiding for years.

It's slow. It's political. It cannot be automated away. And without it, lifecycle workflows produce tickets that sit in queues forever, unapproved and unresolved.

What this phase produces: An owner for every identity, so that when you generate a workflow, someone is responsible for acting on it.

Phase 4: Implement Lifecycle Management

Goal: Automate provisioning, rotation, and deprovisioning—now that you have the foundation to do it right.

With visibility, risk prioritization, and ownership in place, lifecycle management actually works.

You know what exists. You're not automating based on a partial inventory. Any policy you build covers the real population, not just the documented slice.

You know what's risky. Your policies can be proportionate: aggressive approval workflows for high-privilege credentials, lighter touch for low-risk ones. Deprovisioning efforts focus on the identities that actually matter.

You have owners. When a workflow generates a ticket, someone is responsible for it. When you need to attest that a credential is still needed, there's a human who can answer.

Lifecycle management built on this foundation is genuinely useful. Lifecycle management without it is theater—a well-designed system managing a fraction of the problem while the real risk accumulates outside its view.

What this phase produces: Automated, auditable lifecycle workflows that cover your actual NHI population and generate tickets that actually get resolved.

Why You Can't Skip Ahead

The reason organizations try to jump to lifecycle management is understandable. Discovery and ownership work is unglamorous. Lifecycle automation feels like progress.

But the sequence isn't arbitrary. Each phase produces something the next phase requires.

Without visibility, lifecycle management covers only the NHIs that were already known. The service accounts nobody documented, the API keys in legacy systems, the orphaned credentials from previous reorgs—all of it continues to grow outside the system.

Without risk prioritization, you treat all NHIs the same. Access review policies become checkbox exercises that don't actually reduce risk.

Without ownership, workflows generate tickets that nobody acts on. The security team can't force deprovisioning because nobody will approve it. Attestation campaigns become email spam that everyone ignores.

I've seen organizations spend a year building lifecycle automation, then discover it covers 12% of their actual NHI estate. They didn't fail at automation. They failed at the phases that should have come first.

Why Traditional Identity Governance Doesn't Apply

If you've worked in identity governance, you might be wondering: why doesn't the traditional IGA model work here? SailPoint and its peers have been managing identity lifecycle for two decades. Why can't we extend that to NHIs?

The answer is that the entire IGA model rests on an assumption that doesn't hold.

Joiner-Mover-Leaver assumes identities come from HR. Someone gets hired—that's the "J." HR records the event. The IGA system provisions accounts. When that person transfers, HR updates the record. When they leave, HR triggers deprovisioning. The system works because HR is the source of truth, the manager hierarchy provides approvers, and lifecycle events are signaled automatically.

Non-human identities have no "J." A developer creates a service account on a Tuesday afternoon because they need to connect two systems. There's no HR event. No manager is notified. No system records it as an identity lifecycle event. The account just exists.

There's no "M" either. When a human changes roles, HR signals the change. When a service account's purpose changes—the application it served gets refactored, the team reorganizes, the integration it powered gets replaced—nothing signals anything. The account keeps running with whatever permissions it had originally.

And the "L" collapses entirely. Humans leave; that's an event. Service accounts don't leave. They persist until someone explicitly deletes them. That requires knowing the account exists, understanding what it does, confirming nothing depends on it, and being confident enough to pull the trigger. Those conditions are rarely met, so NHIs accumulate indefinitely.

Agentic AI makes this worse. Agents create identities dynamically, at runtime, without human approval. But the JML model was already failing for traditional NHIs. Agentic systems just make the failure undeniable.

Start with Discovery

The path forward isn't a better IGA. It's a different sequence: visibility, risk, ownership, then lifecycle.

Each phase is work. None of it is glamorous. But it's the sequence that actually produces results.

Start with discovery. Everything else depends on it.