Your identity attack surface is bigger than you think.

Most organizations know who their employees are. The harder question is whether they know every identity operating in their environment.

They know who has a laptop, who has a login and, at least broadly, what those users can access. What tends to get missed is everything outside that familiar employee lifecycle.

The contractor whose project ended six months ago but still has elevated access. The service account running an integration no one wants to touch because nobody is quite sure what will break. The AI tool that needed a token to connect to company data. The vendor who was given temporary access—with no expiration date attached to it.

Every one of those is an identity. Every one carries some combination of credentials, permissions and trust. And every one becomes part of your attack surface whether your security team can see it or not.

The identity ecosystem has outgrown the org chart

For a long time, identity management mostly meant managing users. Someone joined the company, changed roles or left, and a process followed. It may not always have been perfect, but at least there was an event that told IT something needed to change.

That model doesn’t work for the full identity environment we have today. Applications, service accounts, cloud workloads, automation platforms and AI tools all need access to systems and data. The difference is that a service account doesn’t get an exit interview. A workload doesn’t tell HR that its project ended. Unless someone is responsible for reviewing those identities, they can remain active long after their original purpose has changed.

This is where I would encourage teams to look beyond the number of identities and focus on how they are managed. Who owns the account? How does it authenticate? Is it using a password, certificate, token or stored secret? When was that credential last rotated? Does the identity have more access today than it did when it was created?

Organizations are also adding identity providers and authentication systems over time. Each one may solve a legitimate problem, but it also creates another place where access has to be understood. Disabling a user in the primary directory doesn’t necessarily remove an application account, invalidate an existing session or eliminate access granted through another provider.

What security teams can’t see, attackers can find

The difficult thing about identity risk is that it often looks completely normal.

A dormant account looks inactive. An excessive permission simply sits there. A service account continues running in the background. None of that necessarily triggers an alert.

But look at the same environment from an attacker’s perspective. That dormant account may still have valid credentials and useful group memberships. The service account may rely on a secret that hasn’t been rotated in years. An account that appears to have very little privilege may inherit access through a nested group, cloud role or application trust relationship.

Attackers don’t always need to break through a control. Sometimes they can log in with an overlooked account, recover a stored credential or take over an active session. Once they are authenticated, they can use the same permissions and trust relationships the environment relies on every day.

That’s why identity sprawl is so easy to underestimate. The risk isn’t only in the accounts you know are powerful. It’s also in the identities no one is watching and the connections no one has mapped.

Identity sprawl isn’t a mistake. It’s a side effect of growth. But left unmanaged, it can become one of the largest and least visible risks in your environment.

Visibility is where it starts

If I were evaluating an organization’s identity attack surface, I wouldn’t begin by asking for a spreadsheet of employee accounts. I’d want to understand the identities operating across the entire environment: directories, identity providers, cloud platforms, SaaS applications, service accounts, workloads and third-party connections.

Then I’d start asking practical questions. Who owns this identity? Why does it exist? How does it authenticate? What direct and inherited permissions does it hold? When was it last used? Most importantly, what could it reach if it were compromised?

An inventory tells you that an identity exists. Those questions tell you whether it creates meaningful risk.

The right response also depends on the identity. Employee access should change when someone joins, moves or leaves. Contractor access should have a sponsor and an expiration date. Service accounts and workloads need accountable owners, narrowly scoped permissions and a reliable way to rotate or eliminate long-lived credentials. Privileged access should be available when the work requires it—not left standing indefinitely in case someone needs it later.

The goal isn’t to manage every identity in exactly the same way. It’s to understand the role each identity plays, give it only the access it needs and make sure that access changes when the business need changes.

Organizations that can do that are in a much better position to remove unnecessary access, improve compliance and limit the damage a compromised identity can cause. Organizations that can’t often discover the gap only after an attacker has already found it.