%201.svg)
HIPAA Compliance Checklist for 2025
TL;DR
- Treat your identity estate like a balance sheet. Every service account, API key, and agent created and never retired is debt you took on and never paid down.
- Non-human identity lifecycle management breaks down at the same three points every time: these logins have no manager, no leaving date, and no close-out step when the project that needed them ends.
- Nothing in the lifecycle retires a credential by default, so the balance only moves in one direction.
- Cleanup stalls for a rational reason, not a lazy one. Deleting a live credential breaks production, leaving a dead one costs nothing today, so doing nothing always wins the argument.
- You will never prove a non-human identity is dead, so stop making that the bar. Triage on privilege, dormancy, and ownership instead.
- CloudEagle.ai discovers every non-human identity across your stack, assigns an owner to each one, flags orphaned accounts and over-permissioned credentials, and puts expiry dates on new ones so the balance stops growing.
Your organization has a running balance of logins that aren't people, and almost nobody is tracking it.
Non-human identity lifecycle management is the discipline of governing service accounts, API keys, tokens, and agents from creation through retirement, and most teams only ever perform the first half of it.
What accumulates is best understood as debt: taken on deliberately, carried indefinitely, paid down by no one.
What Is Non-Human Identity Debt?
Non-human identity debt is the accumulated access held by credentials that no longer serve an active purpose and that nobody has retired.
It is created every time a service account, API token, or agent is provisioned for a real need and then outlives that need. The debt is not the count of identities. It is the gap between the ones you still need and the ones you still have.
Identity Debt Versus Identity Sprawl
Sprawl is a volume problem. Debt is a compounding one.
Sprawl says you have a lot of non-human identities, which is fine and expected in any automated environment.
Debt says a growing share of them do work for nobody, hold access to something that matters, and get harder to safely remove every quarter they sit.
The 2026 reporting puts numbers on the balance, and they are worse than most teams assume:
- Invisible identity now outweighs visible identity across enterprise environments, 57% to 43% (Orchid Security, Identity Gap: 2026 Snapshot).
- 67% of non-human accounts are created directly inside the application, where identity teams never see them (Orchid Security).
- 40% of accounts are orphaned, still available after the people behind them have gone (Orchid Security).
- 70% of enterprise applications carry an excessive number of privileged accounts (Orchid Security).
- Machine identities outnumber human ones by roughly 17 to 1 (Veza, 2026 State of Identity and Access Report).
- Dormant accounts nearly doubled year over year, with orphaned identities up around 40% (Veza, via Help Net Security).
Read together, they do not describe sprawl. They describe a balance sheet where most of the liabilities sit off the books.
Worth saying that the debt framing is not ours alone, Veza uses the same phrase for the same problem, and our own report on the AI-powered future of IGA covers what governance has to look like when most of your logins are not employees.
Where Does the Debt Accrue Across the Lifecycle?
Debt accrues at four specific moments, and each one adds principal without adding a repayment date. Orphaned accounts are only the most visible of the four.
The pattern is the same at every stage: something creates a credential, and nothing is responsible for ending it.
Creation and the Permissions Granted With It
The debt is taken on in the first ten minutes, and this is the only stage where you could have prevented it cheaply. An engineer needs an integration to work, creates a credential, grants it enough access to stop the errors, and moves on.
What that leaves behind:
- Scope set by what made the job work that afternoon, not by what the job requires.
- Permissions that only widen, because someone adds a role to fix a break and nobody removes it after.
- No record of who requested the credential, so nobody to ask later.
Agents have made this stage much faster. An agent typically inherits the OAuth permissions of whoever built it, so a single build can put admin-level access behind an identity nobody registered as an identity at all, which is how most non-human identities are now AI agents rather than service accounts.
The fix here is boring and effective: scope at creation, and record who asked for it.
How Orphaned Accounts Form When an Owner Leaves
Orphaned accounts form when the person who created a credential leaves and the credential does not. Human offboarding is largely solved because HR fires an event and deprovisioning follows it.
That event revokes the person's own access and does nothing to the service account they set up, because that account was never linked to them in any system offboarding reads.
The gap looks like this in practice:
- The leaver's own logins are revoked on schedule.
- Everything they created keeps authenticating, indefinitely.
- The only person who knew the purpose is gone, so the next reviewer inherits real access and no institutional memory.
Veza put a number on this specifically: 824,000 active identities in its dataset were orphaned accounts with no owner in any HR system, about 8% of all identity provider users, and every one of them still held live entitlements (2026 State of Identity and Access Report).
Orphaned accounts are the stage most worth connecting to work you already run. If your offboarding runbook stops at the leaver's own logins, everything they built keeps running unattended, which is why employee onboarding and offboarding needs to account for what a person created and not only what they could reach.
Project End With No Close-Out Step
Projects end, credentials do not, because no project plan says retire the identities we made. A proof of concept gets funded, an integration gets built, the pilot is judged a failure, and the work stops.
The token created in week one keeps its access indefinitely.
Two things make this stage worse than it looks:
- Ending a project is a business decision, revoking a credential is an operational task, and nobody connects the two.
- Abandoned projects are more dangerous than successful ones, because successful work stays in someone's head and failed work leaves behind access with no living memory attached.
Close-out is the cheapest control in this piece. Add credential retirement to your definition of done and one whole source of principal disappears.
Identities Left Out of Access Reviews
Access reviews are the mechanism designed to catch all of this, and they routinely skip the accounts that need them most. The campaign runs, passes cleanly, and never touches the identities carrying the oldest standing access in the estate.
Three structural reasons why:
- Reviews route to managers, and a service account has no manager.
- They certify against employment status, and a token has no employment status.
- They were scoped to user accounts years ago, and nobody revisited the definition.
That exclusion is a scoping decision, not a technical limit, and reversing it is covered in how to bring non-human identities into your access reviews.
Why Does the Balance Never Get Paid Down?
Because the incentives point at inaction and the evidence needed to act does not exist. Teams know the debt is there.
What stops them is that every argument for cleaning up a specific credential is weaker than the argument for leaving it alone one more quarter.
Veza states the structural half plainly: non-human identities persist indefinitely unless someone explicitly decommissions them, where human users are carried out by HR-managed offboarding (2026 State of Identity and Access Report).
There is no equivalent event for a token. Somebody has to decide, and the rest of this section is why nobody does.
The Asymmetry Between Deleting and Keeping a Credential
Deleting a live credential is loud and immediate. Keeping a dead one is silent and free. That asymmetry, not negligence, is the interest rate on identity debt.
The maths facing whoever holds the mouse:
- Revoke a token that turns out to be load-bearing, and you cause an outage with your name on it.
- Leave a token that turns out to be dead, and nothing happens on any timescale that shows up in your quarter.
- One choice risks a visible failure, the other an invisible one, and people reliably choose the invisible risk.
This is why prompt deactivation of unused accounts is such useless advice. It treats deletion as a decision when in practice it is a gamble, and the person taking the gamble eats the whole downside.
Why Sign-In Logs Do Not Prove a Service Account Is Dead
You cannot prove a non-human identity is unused, and any approach waiting for that proof will never delete anything. Most of these identities do not sign in.
They authenticate with a token or certificate, or sit as a placeholder inside a system that generates no interactive login event at all.
The scale of that ambiguity is the problem. Veza counted roughly 3.8 million dormant accounts across its dataset, 38% of all identity provider users, defined as no activity for at least 90 days while still authenticating (2026 State of Identity and Access Report).
Dormant by one measure and live by another at the same time is exactly the position you are asked to make a deletion call from.
The classic trap is a no-reply address wired into a marketing or alerting system. It has shown no sign-in activity since the day it was made and it is pushing thousands of messages a week.
Delete it on the strength of the log and you break something that was never idle for a moment.
Take this principle from it: absence of login evidence is not evidence of absence. Stop asking whether you can prove an identity is dead, and start asking how much damage it would do if compromised and who is willing to own that answer.
The Cost of a Dormant Privileged Credential
A dormant credential with standing privilege is not a housekeeping issue, it is your blast radius. It is the least defended path into a system that matters.
What makes it the soft target:
- No MFA in any interactive sense.
- Excluded from your access reviews.
- Very unlikely to sit behind conditional access.
- Holding privilege nobody has challenged since the day it was granted.
The same gap surfaces at audit in a quieter form. When an assessor asks who owns a given service account and when its access was last certified, the honest answer across most of the estate is nobody and never, which costs you findings and costs you the ability to argue that your controls on excessive privileged users cover what they claim to.
Both problems share a root and a fix: give every non-human identity an owner and a review, starting with the ones holding real privilege.
What Does Non-Human Identity Lifecycle Management Look Like in Practice?
Practical non-human identity lifecycle management means ranking what you already have by risk, forcing ownership onto every identity, and making sure new credentials arrive with an end date attached. Two efforts run at once: reducing the existing balance, and stopping new principal.
Our webinar on managing risk and compliance across the SaaS stack walks through the same sequence with a live environment.
Triage by Privilege and Dormancy Instead of Certainty
Rank the estate rather than trying to clear it, because the orphaned accounts holding admin scope are worth a hundred of the ones holding none. Sort by what an identity can reach, then by how long since anything was recorded against it, then by whether a living person will vouch for it.
The case for ranking rather than sweeping is in the data. Veza found that just 0.01% of non-human identities control 80% of all cloud permissions (2026 State of Identity and Access Report).
Almost all of your exposure sits in a sliver of the estate, so working that sliver properly beats working the whole list badly.
Work the top of that list with a defined process:
- Notify the owning team and set a deadline for someone to claim the credential.
- Disable rather than delete.
- Remove only after a defined quiet period with no reported breakage.
Disabling is the move that breaks the asymmetry. It makes the reversal cheap, which takes the fear out of acting.
Assigning an Owner to Every Non-Human Identity
Every credential needs a named human accountable for it, and where the original creator has left, ownership has to be reassigned rather than left blank.
An identity with no owner will never be reviewed by anyone, because reviews route to people and there is nobody to route to.
Two rules that make this stick:
- Ownership does not mean understanding the credential on day one. It means being on the hook for finding out.
- Assign it to the team that operates the system the credential touches, not to whoever happens to run identity.
Expiry Dates That Stop New Principal
Set an expiry at the moment of creation, because it is the only control that works without anyone remembering to act later.
A credential that lapses on a date cannot silently become a ten-year liability, and the person creating it is the only one who will ever know the right date.
This is the difference between paying down a balance and stopping the bleeding:
- Triage handles what you already carry.
- Expiry at creation makes sure the pile you clear this year is not rebuilt by next.
The same reasoning applies to the newer standing connections into your systems, which arrive with credentials of their own and default to permanent, a pattern worth reading about in MCP server security.
See Every Identity You Are Carrying
How CloudEagle.ai Helps You Govern Non-Human Identities
We bring service accounts, API tokens, managed identities, and agents into one governed inventory, then apply the ownership, review, and expiry controls our identity governance platform already runs for people.
The goal is a defensible basis for acting on identities you cannot fully explain.
What We Surface Across Azure AD, Okta, and Your SaaS Stack
We pull managed and service identities from your directories and SaaS applications into a single view, so you are not reconciling one console against another.
We are direct about the limit, because it shapes how you should use this. We do not give you API-call-level telemetry proving an identity is dead, and neither does your directory. What we give you are the four things you can actually triage on: scope, dormancy, ownership, and age.
Reviews and Expiry That Keep the Balance Flat
We extend the same governance you run for people across your non-human identities:
- Access reviews extended to non-human identities, so they enter the same certification cadence as human users.
- Owner assignment with direct notification when the original creator is gone.
- Insights that flag identities with no activity in 90 days, and identities holding no roles or permissions at all, usually your fastest route to the orphaned accounts sitting at the bottom of the estate.
- Time-Based Access, putting an expiry on credentials at the point of creation.
Two customers show what this looks like in practice:
- Armorcode raised visibility across their non-human identities from 40% to 95%, remediated 480 unmanaged service accounts, tokens, and agents, and scoped down more than 220 over-privileged ones.
- Coherus Oncology cleared 340 orphaned accounts and cut contractor deprovisioning from three weeks to twelve hours by tying expiry to engagement end dates.
Agents are the reason to start now rather than next year. They are created faster than service accounts ever were, they inherit their builder's permissions, and they are already the fastest-growing line on the balance, which is why AI agents end up with more access than your security team.
Every agent created today without an owner and an end date is principal you will be arguing about in three years.
Stop Adding To The Balance
.avif)
.avif)
.avif)
.png)
