MFA Isn’t Enough: Why Identity Is Now Your Largest Attack Surface

Abstract: Identity has replaced the network perimeter, and attackers understand this better than most defenders. This post explains how privilege creep, misconfigurations, stale accounts, and identity trust relationships create breach paths even in MFA-enabled environments. It provides practical guidance without overwhelming internal teams.

—

Most organizations feel reasonably confident in their identity security. MFA is widely deployed. Authentication events are well-controlled. When questions arise, teams point to concrete improvements and move on. 

That confidence is not misplaced. Across most industries, MFA adoption now sits between 60-80%. Credential-based attacks are harder. Phishing is less effective. From a login standpoint, identity feels handled.

What changed next was quieter. As companies moved faster — adopting SaaS platforms, cloud services, and third-party integrations — identity expanded well beyond the user login. New accounts, permissions, service identities, and trust relationships accumulated across hundreds of systems. 

Identity became more powerful and more distributed. That shift created new constraints for security teams. Duo Security’s latest security leader survey found that 94% believe complexity in identity infrastructure actively reduces security. Their concern reflects the reality of teams managing access that grows faster than visibility.

MFA did not fail. Identity security became riskier for a different reason: trust scaled faster than understanding. This “identity sprawl” is now one of the most common ways attackers move through modern environments. 

Why MFA Confidence Is Earned and Incomplete

MFA worked as intended. Its adoption reduced credential-based attacks, improved audit outcomes, and removed a large class of low-effort compromise. Many companies saw MFA as the first identity control that delivered visible, organization-wide results. Their confidence was warranted.

Success also changed how teams reasoned through identity risk. Once MFA became a baseline control, identity security became measured through coverage metrics: who had MFA, where it was enforced, and whether exceptions existed. Teams took strong numbers as evidence that identity was under control. Attention moved to authentication events instead of what authenticated access allowed.

While MFA matured, identities multiplied. New SaaS platforms, integrations, service accounts, and automation identities were added faster than teams could meaningfully review them. Access accumulated quietly, spread across hundreds of tools and trust relationships. MFA guarded the door. The interior evolved largely unchecked.

Identity Sprawl — Born from Accumulated Trust

Most companies did not make poor security decisions. They expanded. MFA stabilized authentication and reduced noise. Teams could move faster and adopt new tools with less friction. Identity became reliable enough to scale.

That expansion introduced identities everywhere: 

• New SaaS platforms introduced new users, roles, and integrations. 

• Cloud environments add service principals, roles, and conditional access logic.

• Automation and availability pressures consistently favored granting access over revisiting it.

Over time, removal became harder than creation. Access enabled uptime and delivery. Removing access risked outages, incidents, and blame. Ownership blurred as identities outlived projects, vendors, and teams. Temporary access became a permanent structure.

At that point, architecture mattered more than controls. Permissions accumulated faster than review cycles. Trust relationships persisted beyond their original purposes. Visibility lagged growth. As trust accumulated, the attack surface spread quietly, by design.

Non-Human Identities: Where Sprawl Becomes Exposure

Identity sprawl becomes materially risky when access stops being tied to people. Non-human identities — the accounts and credentials systems use to talk to each other — are where accumulated trust transforms into persistent exposure. These interfaces are where privilege concentrates:

• Service accounts created for applications and integrations often carry broad permissions to avoid breaking workflows.

• API keys and OAuth grants issued to third-party tools are designed to run quietly in the background.

• Automation identities are built to operate continuously — making availability more important than restraint.

Each exists for good reasons. Together, they create access paths that are rarely revisited.

Unlike human users, these identities often lack clear owners. They persist across personnel changes, vendor transitions, and system retirements, becoming an assumed baseline instead of something to manage. This helps explain why 79% of IT professionals report being ill-equipped to prevent attacks involving non-human identities. 

Attackers favor these paths because access is valid, persistent, and difficult to separate from normal system behavior. Nothing needs bypassing. Activity blends into automation and service traffic. In this context, MFA is not the control being exercised. The authentication boundary protecting human users is not the boundary being breached.

This pattern played out in an incident involving Dropbox Sign in April 2024. Attackers compromised a backend service account through an automated configuration tool used in the environment. That account held broad privileges across production systems, allowing the attackers to access customer email addresses, usernames, API keys, and OAuth tokens. The impact extended beyond account holders to third-party recipients who interacted with Dropbox Sign documents without ever creating an account themselves.

This was not a user phishing or an MFA failure. The system behaved as configured. Inherited trust enabled lateral access, and identity sprawl expanded the blast radius beyond what teams could reasonably model in advance. MFA could not materially change the outcome because the exposure lived entirely outside the human login flow. Reviewing identity policy rarely surfaces incidents like this. They emerge when access paths are exercised.

Beyond MFA: Validating What Authenticated Access Allows

Identity sprawl and non-human access create risk not because teams do not care but because confidence often comes from policy intent rather than observed behavior. Most organizations understand how identity is intended to work. Far fewer have validated how it actually behaves once access is granted.

This gap carries disproportionate cost in mid-market environments. Data from Old National Bank shows that small to medium-sized businesses spend an average of $2.65 million — or $3,533 per employee — to recover from a security breach. Sixty percent of SMBs that experience a breach close their doors within six months. When the recovery margin is thin, unseen identity exposure carries severe consequences.  

In lean teams with constant business pressure and limited staff, identity sprawl is easy to defer. New access enables delivery, and old access rarely breaks anything. Permissions — and risk — compound quietly.

Mature security teams respond to this reality differently. They do not treat identity as a finished product. They expect drift and replace assumptions with validation. “We have MFA everywhere” is a starting point. In practice, this is why mature teams rely on penetration testing services to validate identity behavior under real access conditions.

Confidence does not come from reassurance but from evidence. That evidence emerges by validating how identity actually behaves when access is used as intended:

• Path evidence showing how far an attacker can move once valid access exists

• Privilege reality revealing what inherited roles, chained permissions, and indirect admin paths actually enable

• Non-human identity exposure across service accounts, API keys, OAuth grants, and automation identities

• Trust relationship validation showing how access flows between systems, platforms, and SaaS tools

This kind of verification replaces assumed safety with demonstrated understanding. Teams can speak about identity risk calmly and credibly — not because controls exist, but because their impact has been tested.

From Assumed Safety to Defensible Cybersecurity Confidence

Identity did not become dangerous because attackers learned new tricks, but because organizations scaled trust faster than understanding. MFA remains necessary, but it is no longer the measure of identity safety.

The difference between assumed safety and defensible confidence is evidence. Teams that validate how identity actually behaves across people, systems, and automation stop overreacting to identity headlines and start making decisions grounded in reality. 

—

Validate identity risk the same way attackers encounter it.