Too Privileged To Fail: The Identities Nobody Is Stress-Testing

The contractor's account provided an initial foothold. A hardcoded administrator credential in an internal script turned that foothold into much broader access across the company. Banking has a phrase for anything whose failure drags everything else down with it: too big to fail. After the 2008 crisis, U.S. regulators made the largest banks prove every year that they could survive a severe recession, and file a plan showing how they could be shut down in an orderly way if they failed.

Every enterprise I work with has identities in the "too big to fail" category. Somewhere in your environment sits a small group of identities whose compromise could do structural damage to your business. A few of these identities belong to people, but most will belong to service accounts and integrations. Nobody set out to make them powerful. They accumulated authority one reasonable decision at a time, and because no single decision looked dangerous, none of them appear on a risk register.

The Growing Threat

Verizon's 2026 Data Breach Investigations Report drew attention because, for the first time in the report's 19-year history, exploiting software vulnerabilities overtook stolen credentials as the most common way into an organization, at 31% of breaches. Some people read that as identity mattering less. I read it the other way. Credentials still feature in 39% of breaches somewhere in the attack chain, usually after the first foothold, when an attacker needs to move sideways and climb.

The way in matters less than what is waiting inside. An attacker who lands on an unpatched web server starts hunting for the identity that can reach everything else. In most companies, that identity already exists. The same report found that "for weak passwords and permission misconfigurations, the time to resolve 50% of all findings [reached] almost eight months." Eight months is a long time to leave a door open when you know where it is. Most organizations do not know where their most important doors are.

Hidden Privileged Identities

Let's think about a logistics company that is confident about its privileged access. Its administrators use hardware keys, and every privileged session is recorded. When we map effective authority across the environment, the most powerful identity in the company belongs to none of those administrators. It is a service account created for an ERP migration in 2019. Through nested groups and a delegation set up by a contractor who had long since left, it can read the payroll export and reset any password in the directory.

The ERP migration finished years ago. And yet, the service account was still running a scheduled job at 3:15 a.m. every morning, and nobody could tell what the job did. This pattern repeats time and again. At a financial services firm, a marketing automation integration had been given write access to the CRM. A later change to a shared group handed it read access to a file share that stored scanned customer identity documents. Two different teams approved the permissions, 18 months apart, each for a sensible reason.

Testing Critical Identities

These identities are dangerous because their authority comes from the relationships between systems. An access review looks at one system at a time and asks whether a person should hold a given permission. It has no way to see what that permission connects to two or three steps away. Here are two tests to run.

Start with concentration. Ask your team to name the 10 identities holding the most effective authority across your systems. Effective authority means what an identity can actually do once inheritance and delegation are counted, which is often very different from what it was originally granted. If the list comes back as your senior administrators and the executive team, your team has answered with intent. They have told you who should be powerful. Ask them how they know.

Then test resolution. Pick one identity from that list and revoke it everywhere, then prove you did. That covers the account itself, the tokens issued to it, the API keys it created, the delegations it holds and every scheduled job running under its name. In a tabletop exercise I ran this year, a team estimated it could do this in under an hour. Working it through properly took 11 days, most of them spent tracing a key that had been copied into a pipeline in a contractor's code repository.

Taking Action

Nobody is going to mandate this. The banks did not volunteer for stress tests. Regulators imposed them after the damage was done, and the lesson cost a great deal. No equivalent regulator exists for identity currently, and I don't expect one soon. Most frameworks still ask whether access was reviewed, which is a different question from whether anyone knows where authority actually sits. That leaves the job with the CISO.

My suggestion is modest and simple. Before your next board meeting, find out which identities in your business are too privileged to fail. Put them on your risk register by name, and give each one a specific owner. Then test whether you could switch each identity off in a hurry. If the answer is uncomfortable, a conference room is a far better place to learn it than an incident report.