Zero Trust Security

Why Identity Security Doesn’t Solve the Problem

For the past decade, companies have been told that identity is the new perimeter. Put single sign-on in place, turn on multi-factor authentication (MFA), and the hard part is done. Many organizations did exactly that. They’re still getting breached.

The data backs that up. Verizon’s 2025 Data Breach Investigations Report found that stolen credentials were the most common way attackers got in for the second year running, at 22% of breaches, and that 88% of attacks on basic web applications involved stolen credentials. Attackers aren’t breaking in. They’re logging in.

Identity security isn’t wrong. It’s incomplete. Here’s why it leaves companies exposed, and why the gap is about to get much wider.

Identity is one factor. An access decision needs more.

Identity answers one question: who is this? A sound access decision has to answer several more. Is this the device we expect? Is that device healthy? Does the location make sense? Is the behavior consistent with this person, or with a person at all? Should this session still be trusted ten minutes from now?

An example of how this plays out is Microsoft 365, Microsoft’s cloud suite for email, file storage (OneDrive and SharePoint) and collaboration (Teams). Sign-in is handled by Microsoft Entra ID, Microsoft’s identity service. When a user signs in, Entra confirms who they are, and from that point the user, or whoever holds the user’s session, can reach their mail, files and chats. Entra can add device and location rules, but only for the applications it fronts. The file server in the data center, the remote desktop host, the client-server ERP application and the operational technology (OT) network all sit outside that decision.

When identity is treated as the whole answer, the “who” becomes the only thing standing between an attacker and your data. Steal or spoof the who, and everything else follows.

MFA helps. But steal the token and you’re home free.

MFA is one of the most valuable controls a company can turn on, and nothing here argues against it. But MFA protects the moment of login. It does not protect what happens after.

When you sign in, the identity provider gives your browser a session token, a digital pass that says “this user has already proved who they are.” For hours, sometimes days, every request carries that pass instead of asking you to sign in again. The token is a bearer credential: whoever holds it can use it.

That is precisely what attackers go after. In an adversary-in-the-middle (AiTM) attack, a phishing site sits between the user and the real login page. It passes everything through, including the MFA prompt, and quietly copies the session token the moment the login succeeds. The user did everything right. The attacker walks in with a valid pass. A newer variant, device code phishing, skips the fake page entirely: the victim is tricked into entering a code on Microsoft’s genuine sign-in page, completes MFA themselves, and unknowingly hands the resulting tokens to the attacker. Infostealer malware does the same thing from the device side, lifting session cookies straight out of the browser. SpyCloud recaptured 8.6 billion stolen session cookies circulating in underground sources in 2025 alone.

This isn’t theoretical, and 2026 has made the point repeatedly:

April: Microsoft reported an AiTM campaign that, over just three days, targeted more than 35,000 users at over 13,000 organizations in 26 countries, built to capture authentication tokens that give immediate account access.
July to September: Huntress tracked attackers replaying stolen Microsoft 365 sessions at 79 organizations, with at least 497 successful sign-ins. In 19 of those organizations, the attackers wiped the victim’s MFA methods and registered their own within three hours of getting in.
September: Microsoft and its partners took down EvilTokens, a device code phishing service that had compromised more than 12,000 inboxes across over 10,000 organizations. Victims never gave up their passwords. Microsoft noted that access could persist even after a password reset if the sessions and tokens weren’t also revoked.

It isn’t only user sessions. In August 2025, attackers used OAuth tokens stolen from the Salesloft Drift integration to pull data out of customers’ Salesforce environments. No password and no MFA prompt were involved; the tokens did all the work.

Resetting the password doesn’t help when the attacker never needed it.

Authenticate and abdicate

This is the core design flaw. Most identity solutions authenticate and abdicate. They do a careful job at the front door with a password, MFA and perhaps a device check, then issue a token and step out of the conversation. From that moment on, each application trusts the token, not the person. (We looked at the architecture side of this in an earlier post, Deciding Is Not Enforcing.)

That creates three problems:

Trust is checked once and assumed for hours. Anything that changes after login goes unnoticed by the system that granted access: the device gets infected, the session is hijacked, the behavior turns strange.
The identity provider never sees the traffic. It knows who signed in. It doesn’t know what they reached next, or whether the session is still in the right hands.
A stronger front door raises the value of the token. The harder the login, the more attackers invest in stealing what the login produces. Strengthening authentication without controlling the session moves the risk downstream instead of removing it.

AI agents turn the gap into a highway

Now add AI agents. Palo Alto Networks’ 2026 Identity Security Landscape report puts the ratio at 109 machine identities for every human identity, with roughly 79 of those being AI agents, and expects agent identities to grow about 85% in the next year. The same report found that nine out of ten organizations suffered a successful identity-related breach in the last 12 months.

Agents run on tokens. An AI assistant connected to your email, CRM and file shares holds OAuth tokens and API keys that give it standing access, often broad, often long-lived and rarely reviewed. There is no MFA prompt for an agent. Every one of those tokens is exactly the kind of credential already being stolen at scale. The Drift breach was a preview. And attackers are using AI too: Microsoft said EvilTokens used AI “at every step of the attack chain,” including a chatbot that combed stolen inboxes for payment approvals and drafted impersonation emails.

Two more factors make it worse:

Speed. An agent, or an attacker controlling one, can enumerate and extract in minutes what would take a human intruder weeks to find.
Impersonation. The hardest case isn’t the agent you registered. It’s the one riding inside a user’s session: a browser extension or desktop AI tool acting with that user’s own token. To the identity provider, it is the user. An authenticate-and-abdicate model can’t tell the difference, because it stopped looking after login.

More control points, less control

Most companies answered each new access problem by adding another product: a VPN for remote access, SSO for cloud apps, MFA on top, mobile device management (MDM) for devices, a privileged access tool for administrators, a separate portal for vendors and contractors, and native permissions inside every application.

Each has its own policy engine, its own console, its own logs and its own definition of who is allowed. The administrative workload is real, but it isn’t the biggest cost. The biggest cost is that nobody can answer a simple question with confidence: who can reach what, right now, from where, on which device?

Policies drift apart. A contractor removed from the VPN may still hold a valid token to a SaaS application.
Gaps form at the seams. Attackers don’t challenge your strongest control. They look for the application that only one product covers, or none.
Visibility is split. A token stolen in one system and used in another shows up as two unrelated, normal-looking events in two different consoles.
Audits become archaeology. Proving who had access at a given moment means stitching together exports from half a dozen tools.

I’ve worked in IT since 1985, and I’ve watched this pattern repeat with every generation of technology: mainframe terminals, client-server, VPNs, SSO, MDM and the cloud. Each new layer solved the problem in front of it and added one more place where access gets decided. Identity security is the latest layer, not the last word.

What actually closes the gap

The answer isn’t to throw out your identity provider. It’s to change where, and how often, the access decision is made.

One enforcement point for all access. Web, SaaS, remote desktop, SSH, client-server, legacy and OT systems under one policy, one log and one place to revoke.
Bind more than identity to the session. Device validation, managed-device markers, location and behavior, so a stolen token alone isn’t enough to use the session from somewhere else.
Decide on every request, not once. Each request is a decision point, not just the login.
Treat AI agents as their own kind of principal. Identify them, scope what they can reach, and watch for software acting inside a human’s session.

This is the architecture we built Total Access Control (TAC) on at PortSys. TAC sits in front of your applications as a secure reverse proxy, a single gateway every request passes through, so access is evaluated throughout the session rather than only at login. It works with the identity provider you already have; Entra, for example, can remain your identity store while TAC arbitrates access. TAC can bind multiple factors to each session beyond MFA, such as device validation and custom device markers, largely invisible to users. Because it fronts far more than web applications, customers can bring remote desktop, SSH, client-server, legacy and OT access under the same policy and retire overlapping products at their own pace, without a rip-and-replace. We’re extending the same model to AI agents, including detecting agents that operate inside a user’s session.

Three questions worth asking

If an attacker stole a valid session token from one of your users today, what would stop them from using it?
How many separate places decide who gets access in your environment, and do they agree?
Do you know which AI agents hold tokens to your systems, and what they can reach?

If the answers are uncomfortable, identity security alone won’t fix them. Identity tells you who is knocking. Security is deciding, on every request, whether to let them in.

Sources

← Back to Blog Book a Demo