Access Control Debt

5 min read

It usually starts with a spreadsheet nobody wanted to build.

Somewhere in every large organization, there’s a moment where someone — an auditor, a new CISO, an integration lead — asks a deceptively simple question:

“Who actually has access to this system, and why?”

The honest answer, more often than not, is: nobody fully knows.

This isn’t a failure of any one team. It’s the natural result of how enterprises actually grow — through mergers, reorganizations, new vendors, offboarded employees, deprecated tools, and permissions granted “just for now” that quietly became permanent.

Two moments tend to surface this problem faster than any other. Let’s walk through both — and what they reveal about a deeper, structural issue most organizations haven’t named yet.

Moment One: The Merger

Mergers and acquisitions are where access control chaos becomes impossible to ignore.

Two organizations — each with their own directories, their own legacy systems, their own permission models built over years or decades — suddenly need to operate as one. Full technical integration often takes years. In the meantime, both environments have to coexist.

What typically gets discovered during that period is sobering. Security researchers consistently note that post-acquisition consolidation routinely uncovers thousands of stale accounts and tokens — credentials from employees who left the acquired company months or years earlier, still active, still carrying whatever access they had on their last day.

It’s not hard to see why. During a merger:

• Two identity systems need to be reconciled, often manually

• Nobody owns the “in-between” period where both old and new systems are live

• Vendor and contractor accounts from the acquired company are rarely inventoried before close

• Integration teams are focused on making systems work together — not on auditing who has access to what

The result is a temporary — but very real — access control blind spot, sometimes lasting years. And attackers know it. Compliance frameworks including ISO 27001, NIS2, PCI DSS, and FedRAMP all treat this kind of residual access as a direct violation of least-privilege and deprovisioning requirements.

Moment Two: The Audit That Finds the Ghosts

The second moment doesn’t need a merger. It just needs a proper look.

When organizations run a genuine identity and access audit — not a checklist review, but real observability into every account across cloud, on-premises, and SaaS systems — the numbers are consistently uncomfortable.

Recent industry research puts the scale of the problem in stark terms:

Roughly 40% of all accounts in a typical enterprise belong to users who no longer exist in the organization’s HR systems. [3]

These are called orphan accounts — identities left behind by an employee departure, a contractor’s end date, a decommissioned service, or a vendor relationship that quietly ended without anyone revoking access. [3][4]

They’re joined by a related and equally under-tracked category: stale accounts — technically valid, technically assigned to a real user, but inactive for 90 days or more, sitting untouched until someone (or something) finds a reason to use them again. [5]

Neither category shows up cleanly in most governance dashboards, because most tools are built to monitor managed accounts — the ones IT already knows about. Orphan and stale accounts, by definition, fall outside that visibility. [6]

Why This Keeps Happening — Even at Well-Run Organizations

It’s tempting to treat orphaned access as a hygiene failure — something a better offboarding checklist would fix. But the pattern is bigger than any single process gap.

Three structural realities make this almost inevitable at scale:

1. Deprovisioning depends on coordination that rarely happens cleanly. HR, IT, and individual application owners each hold a piece of the access lifecycle. When an employee leaves, a contractor’s engagement ends, or a vendor relationship closes, someone has to actively revoke access across every system that person touched. In practice, that coordination breaks down constantly — not from negligence, but because no single team has full visibility into everything a person had access to. [3]

2. Non-human identities compound the problem invisibly. Service accounts, API keys, and automated integrations don’t get “offboarded” the way a person does. They persist by default. Research on non-human identity risk found that two-thirds of enterprises have experienced a successful cyberattack originating from a compromised non-human identity — with affected organizations averaging 2.7 separate incidents in a 12-month period. [4]

3. Risk compounds rather than staying isolated. An orphaned account, still authenticated, with excessive privilege and credentials stored insecurely, isn’t five small problems. It’s one open door — and increasingly, it’s a door that both human attackers and autonomous systems can walk through without triggering a single alert. [3]

What This Actually Costs

The consequences aren’t hypothetical. They show up in three consistent categories:

Compliance exposure. Residual, unmanaged access is a direct violation of the deprovisioning and least-privilege principles built into ISO 27001, NIS2, PCI DSS, and most modern data protection regulation. [1][2]

Operational drag. Beyond security risk, orphaned access inflates license counts, complicates audits, and slows down every review cycle that has to account for accounts nobody can explain. [1]

Incident response friction. When a breach investigation begins, unmanaged accounts muddy the trail. Forensic teams lose time simply figuring out whether an account belonged to a real, current employee — before they can even begin tracing what it accessed. [1]

The common failure mode across recent high-profile breaches isn’t a single dramatic vulnerability. It’s aged credentials, over-permissive access policies, and lifecycle gaps that existed long before the breach — and were technically fixable the entire time. [7]

The Real Name for This Problem

Mergers surface it in dramatic, all-at-once fashion. Audits surface it gradually, account by account. But underneath both moments is the same underlying condition:

Authorization debt.

Just like technical debt, authorization debt accumulates quietly, through completely reasonable decisions made in the moment — a temporary access grant, a vendor integration nobody circled back to review, a merger integration that prioritized “keep the business running” over “revoke everything precisely on day one.”

No single decision was wrong. But the accumulated weight becomes a real liability — one that sits invisibly on the books until an audit, a breach, or a merger forces it into view.

And critically: periodic access reviews don’t solve this. A quarterly or annual certification only catches debt that existed at the moment of review. It says nothing about the account created the week after, the integration added mid-quarter, or the vendor relationship that ended without anyone flagging it. Access control debt accumulates continuously — which means it can only be meaningfully managed continuously, not on a calendar.

What Continuous, Real-Time Access Control Actually Solves

This is the structural argument for moving beyond periodic reviews and static role assignments toward real-time, policy-based enforcement — regardless of whether the driver is a merger, a compliance mandate, legacy modernization, or simply good governance discipline.

A few principles worth carrying into any evaluation of an access control strategy:

Visibility has to be continuous, not scheduled. Orphan and stale accounts don’t wait for the next audit cycle to become risky. A system that only checks quarterly will always be behind the accounts that were created — or should have been revoked — in between.

Enforcement should live at the transaction, not just the account. Knowing an account exists is necessary but insufficient. The more durable control is enforcing, in real time, whether a given transaction — a data pull, an API call, a system-to-system request — is actually authorized, regardless of what the account’s static role says it’s allowed to do.

The rule engine should be system-agnostic. Authorization debt doesn’t respect the boundary between old and new. A 20-year-old core banking system and a newly deployed SaaS integration both accumulate orphaned access the same way. A governance approach that only covers modern cloud infrastructure — while leaving legacy systems to periodic manual review — simply relocates the blind spot instead of closing it.

Evidence should be generated as a byproduct of enforcement, not reconstructed afterward. When access decisions are enforced in real time, the audit trail already exists. Nobody has to scramble to reconstruct who had access to what, when, and why — the record was created the moment the decision was made.

The Takeaway

Access control debt isn’t a failure of any single team, tool, or checklist. It’s the predictable outcome of how organizations actually operate — growing, merging, integrating, and moving faster than manual review cycles can keep up with.

The organizations that manage this well aren’t the ones with zero orphaned accounts. That’s not realistic at scale. They’re the ones who’ve built infrastructure that finds and governs authorization debt continuously — before it becomes the finding in someone else’s audit, or the entry point in someone else’s breach report.

Sources: [1] “The Hidden Risk of Orphan Accounts,” The Hacker News, 2026. [2] “The Hidden Risk of Orphan Accounts,” Blade Intel, 2026. [3] “The Identity Gap: 2026 Snapshot,” Orchid Security, 2026. [4] “Orphan Accounts and Residual Access Expose Identity Control Gaps,” NHIMG / Oasis Security & ESG, 2026. [5] “What Is an Orphaned Account? Definition, Risks & Fixes,” TechPrescient, 2026. [6] “Best Identity Security Posture Management Solutions for Enterprise,” Expert Insights, 2026. [7] “How Stale Credentials Drove the Worst Data Breach Incidents of 2026,” Cybersecurity Insiders, 2026, citing TechCrunch enterprise breach reporting.