The Debt Your Security Team Isn't Tracking

In February 2024, CISA published an advisory describing how a threat actor had successfully breached a U.S. state government network. The entry point was not a sophisticated zero-day exploit. It was not a phishing campaign or a supply chain attack. It was a former employee's account — credentials that had never been deprovisioned after the person left the organization. Using that orphaned account, the attacker accessed virtualized servers including SharePoint and the former employee's workstation, moving through systems that nobody was watching because nobody remembered the account existed.

One account. One overlooked offboarding step. One open door left unlocked long after the person who used it had gone.

However that one account rarely travels alone. Behind it, in most enterprises, are hundreds more just like it — former contractors whose access was never reviewed, service accounts created for a project that ended two years ago, API tokens embedded in systems nobody owns anymore. They do not accumulate because of negligence. They accumulate because the forces that create them are constant and the processes that remove them are not.

This is identity debt. And most enterprises are carrying far more of it than they realize.

Technical debt is a concept most engineering teams understand intuitively: the accumulated cost of shortcuts taken, decisions deferred, and systems not maintained. You borrow against future effort every time you choose the fast path over the right one, and eventually the interest comes due.

Identity debt works the same way, but the ledger is invisible and the consequences are often sudden.

It accumulates across five categories:

Orphaned accounts — identities that belong to people who no longer have a relationship with the organization. Former employees, terminated contractors, departed vendors. The account exists. The person does not.

Over-privileged accounts — identities that were granted access for a specific project, role, or moment in time and never had that access reduced. The developer who needed production database access for a migration six months ago. The manager who inherited their predecessor's permissions without anyone reviewing whether they still made sense.

Unattested access — entitlements that have never been reviewed, confirmed, or challenged by anyone with accountability for them. Not necessarily wrong. Just unexamined.

Unmanaged non-human identities — service accounts, API keys, application credentials, and automation tokens that were created to solve a problem and then forgotten. No owner. No expiration. No lifecycle.

Ungoverned AI agents — this is the newest and fastest-growing category, and most organizations have no framework for it yet. AI agents are being deployed in production with delegated access to systems, data, and workflows. But unlike a human employee, nobody is asking the foundational questions: What is this agent authorized to do? On whose behalf is it acting? Until when? Without clear answers to those three questions, an AI agent can access, modify, and execute actions across systems that nobody explicitly approved — and do so continuously, at a scale no human could match. The identity debt created by ungoverned agents is not just accumulating. It is accelerating.

Each category is a form of accumulated risk. Together they create a surface area that grows silently every quarter, invisible on dashboards, untracked in risk registers, and largely undetected until something goes wrong.

The reason identity debt grows so reliably is that the forces creating it are constant and the forces reducing it are periodic at best.

People join, move, and leave organizations continuously. Access is granted fluidly and revoked rarely. Projects get provisioned and never deprovisioned. Roles are copied rather than designed. Each of these is a small delta — one account, one entitlement, one service credential — but the accumulation is relentless.

Then there is the emergency exception that becomes permanent policy. Someone needs urgent access to complete a time-sensitive task — a system migration, an incident response, a customer escalation. The right access isn't set up, the request would take days to process properly, and the business need is right now. So IT grants a temporary elevated role to unblock the situation. The immediate problem is solved. The ticket is closed. And the temporary access is never revisited. Weeks pass. Months pass. That user is now carrying elevated privileges that nobody remembers granting, for a reason that no longer exists. Multiply this by the number of urgent situations your organization handles in a year, and you begin to understand how over-privileged accounts accumulate even in organizations that believe they are following process.

Most organizations attempt to address all of this through access reviews: periodic campaigns where managers attest to the access their team members hold. In theory this closes the loop. In practice, it rarely does — and the reason is straightforward. Access reviews land in a manager's inbox alongside everything else competing for their attention. Approving or denying an entitlement carries no immediate consequence either way. If a manager approves access their employee no longer needs, nothing happens today. The risk is invisible and deferred. So the path of least resistance is to approve, move on, and get back to the work that feels urgent. The artifacts are produced. The debt is not actually paid down.

The difference between an access review that reduces risk and one that produces documentation is one of the most important distinctions in identity governance. And most organizations are running the latter while believing they're running the former.

If you are looking at an identity debt problem and trying to figure out where to begin, the answer is almost always the same: start with the highest-privilege accounts and work outward.

Administrative credentials, privileged service accounts, and access to sensitive data stores represent the greatest concentration of potential damage. Orphaned accounts in these categories are not just a compliance finding — they are an open door.

A practical first step that most organizations can complete without a major program: run a report of all accounts with administrative or elevated privilege that have had no interactive login in the past 90 days. Disable — not delete, disable — anything that cannot be immediately justified by an accountable owner. Review what remains.

It will not close all the debt. But it will reduce the most dangerous exposure and give you a baseline for what you are actually working with.

The organizations that manage identity debt well are almost never the ones with the most sophisticated tooling. They are the ones that have made access an owned thing — where someone specific is accountable for every entitlement, where that accountability is reviewed on a cadence that actually matches the rate of change in the business, and where the default for unused access is removal rather than retention.

The tooling follows the discipline. It never replaces it.

If this issue was useful, forward it to one person on your team who would appreciate it. The best way to grow a practitioner community is one good referral at a time.