Why identity security is a verb, not a noun

By Ben Baker

April 8, 2026  •  6 minute read



alt=""

This blog is based on a video interview of Jason Rebholz, co-founder & CEO at Evoke Security. You can watch the full interview here

 

TL;DR

  • Attackers have largely stopped trying to break down the front door. They’re stealing session cookies and walking straight in—bypassing MFA, skipping the login entirely, and landing inside environments that have no visibility past the authentication event.
  • Least privilege is the right idea executed badly at scale. It’s manual, expensive, and almost universally incomplete, and the gaps are exactly what attackers exploit once they’re in.
  • Identity isn’t a problem you solve once. It’s an ongoing action that requires continuous visibility, session-level detection, and a plan for non-human identities that most organizations aren’t close to ready for.

 

The way most organizations think about identity security has a fundamental timing problem. They’ve invested heavily in the front door (SSO, MFA, anomaly detection on logins) and then gone almost completely blind the moment a user authenticates. That’s where the real risk lives, and it’s exactly where most teams aren’t looking.

Jason has spent years tracking this gap, having sat in both executive-level and advisory security roles. His view on the state of identity security is direct: attackers have the advantage, the architecture is broken in predictable ways, and the industry is still mostly treating identity as a fixed state rather than a continuous action.

 

The front door problem

Most identity security programs are built around a single question: did this person authenticate successfully? If the answer is yes, access is granted and monitoring largely stops. The problem is that question has become almost irrelevant to how modern attacks actually work.

Info stealers have made session cookie theft one of the most reliable attack vectors available today. The mechanics are straightforward: malware lands on an endpoint through a phishing link or compromised download, scrapes credentials and session cookies, and sends them back to the attacker. The session cookie—the token a user receives after proving their identity—is effectively a hall pass. It grants access without requiring re-authentication. An attacker who obtains it doesn’t need to log in. They teleport directly into an active session, inside an environment that has already decided to trust them.

“The attacker can take that session cookie, pop it into their browser, and now they’re acting as you,” Rebholz explains. “They’re teleporting straight into your moving vehicle that you’ve already taken out of the garage. You’re driving down the highway, and all of a sudden the attacker’s in the car with you, and they can see everything and do everything that you can.”

This is why the authentication checkpoint, however well-defended, is no longer sufficient on its own. The session that follows it is where the actual work and the actual risk lives.

Swimlane diagram showing how attackers steal session cookies via two paths. The top half shows a legitimate user authenticating with username and MFA, receiving a session cookie from the application, and gaining access. The bottom half shows two attack paths: Path A, where info stealer malware lands via a phishing link and exfiltrates the session cookie directly to the attacker; and Path B, where an adversary-in-the-middle phishing page proxies the authentication flow and intercepts the cookie live, bypassing MFA. Both paths end with the attacker loading the stolen cookie in their browser and acting as the authenticated user with no login required.

 

Why attackers shifted to identity

The move toward credential-based attacks isn’t accidental. It reflects a rational response to improving defenses elsewhere.

Endpoint detection and response tooling has raised the bar significantly for malware-based attacks. Getting malware onto a system and keeping it hidden is harder than it used to be. Session hijacking and credential theft carry less risk of detection, require less technical infrastructure, and provide access to everything the legitimate user can reach, which in a SaaS-heavy environment, is a lot.

“Once I get access into that environment, if I’m sitting as the attacker logged into your computer, I don’t need malware to move to another computer,” Rebholz says. “I can just log straight in. There’s this concept of living off the land—what’s available to me on that box, which is a lot. Why risk it if I can just use an identity?”

The answer, increasingly, is that attackers don’t need to risk it. Identity is both the attack surface and the attack path.

 

The architectural flaw: a disjointed picture of who can do what

Ask any CISO what their identity program actually covers and the honest answer is usually: not everything. The gap between the theoretical model (being one system, least privilege enforced, every identity accounted for) and the operational reality is significant at most organizations.

The SSO tax is part of it. SaaS vendors frequently reserve SSO integration for enterprise tiers, which means security teams either absorb the additional cost or accept identity blind spots in their stack. Rebholz encountered this directly: in one environment, 80% of SaaS applications couldn’t be tied into SSO. That’s 80% of the application landscape operating outside the identity perimeter entirely.

Least privilege enforcement compounds the problem. In theory, it’s straightforward. Give people access to what they need and nothing more. In practice it requires manual conversations with every team, continuous maintenance as roles change, and access reviews that depend on managers actually paying attention. “Let’s be honest,” Rebholz says. “They’re not going out of their way to figure that out. If John in finance needs his account escalated, the manager is just approving it.”

The result is an identity program that looks functional on paper and leaks badly in practice. And when something does go wrong, the blast radius reflects the accumulated permissions drift of years of approvals nobody scrutinized closely.

 

The blind spot after authentication

Even organizations with mature front-door controls typically lose visibility the moment authentication succeeds. Post-authentication security is the gap most teams haven’t closed: in cloud-native environments built entirely on SaaS, losing that thread means going blind across almost everything users actually do.

Rebholz experienced this firsthand. His environment had solid authentication controls. What it lacked was any coherent view of what happened afterward. “Once they logged in, we were totally blind,” he says. “The times we had to go do investigations after somebody logged in, I had to go to every SaaS application and see what logs they potentially had so I could recreate it. It’s a very kludgy process.”

The challenge is partly architectural and partly a reflection of how identity tooling has historically been scoped. SSO providers surface login events. What happens inside each application after login—what files were accessed, what was exported, what lateral movement occurred—lives in disparate logs across dozens of systems that aren’t connected to each other. Without a unified identity threat detection capability, reassembling a meaningful picture of an attacker’s session from that data is slow, incomplete, and often happens too late.

“It’s like reading a book where every third page is ripped out,” Rebholz says. “You might get some sense of what was happening, but it’s not going to make a lot of sense. And if I’m missing every third page, I have a potential of missing the exact point in time where I would have detected an attack.”

 

What good looks like: identity security as a verb

Addressing this requires a conceptual shift before it requires a technical one. Identity can’t be treated as a state—authenticated or not, authorized or not—because the risk doesn’t live in that state. It lives in what happens next.

“Identity security is a verb,” Rebholz says. “You have to think about it as an action. It’s ongoing, and you have to keep pace with it.”

Practically, that means building detection programs that extend beyond the authentication event. The questions worth asking aren’t just whether a login looks anomalous, they’re what a user is doing once they’re inside. When did they access HubSpot? What did they pull from Google Drive? Did they attempt to reach a resource they don’t normally touch? What does normal look like for this user, and what deviates from it?

That kind of session-level visibility requires getting the right logs in place ahead of time, correlating activity across the application stack, and building detections that treat post-authentication behavior as the primary signal, not an afterthought.

Standard out-of-the-box detections from SSO providers aren’t sufficient for this. Attackers have adapted to them. A common question from security leaders is how attackers bypass MFA, and the answer is that they often don’t need to. Geo-based anomaly detection is easily defeated with a well-positioned proxy. MFA push notifications can be phished. Adversary-in-the-middle attacks let attackers steal session cookies without ever triggering a failed authentication event. Post-authentication security isn’t a nice-to-have layer on top of solid front-door controls. It’s the layer that catches what the front door misses. The teams most exposed are the ones who’ve implemented the standard controls and assumed the work is done.

 

The coming complexity: non-human identities

The identity security challenge that exists today is about to get significantly harder. Non-human identities like service accounts, API keys, OAuth tokens, and AI agents already outnumber human users in most cloud environments. AI agents acting autonomously on behalf of users or organizations add another layer: they require their own identities, their own permissions, and their own governance frameworks. Most security teams aren’t ready for what that looks like at scale.

“Anyone that’s looked at any cloud environment and sees how many non-human identities are there, prepare yourself,” Rebholz says. “It’s a long list. Nobody’s tracking that in their heads. When we have agents, it’s just going to add to that.”

The complexity multiplies when agents communicate with other agents. They create transitive trust chains that don’t map cleanly onto existing least privilege frameworks. The question of what a non-human identity should be permitted to do isn’t just about resource access. It’s about autonomy.

The relevant concept for agentic systems may not be least privilege, but least autonomy. How much independent action should a given agent be permitted to take? That question doesn’t have a clean answer yet, but security teams that aren’t asking it now will be well behind when it becomes urgent.

 

What to do with this

The practical takeaway isn’t that identity is an unsolvable problem. It’s that the current approach doesn’t match how attacks actually happen today.

The gap between a well-defended login page and meaningful post-authentication visibility is where most attacks succeed. Closing it requires better logging across the application stack, detection programs built around session behavior rather than just authentication events, and a willingness to treat identity as something that requires continuous attention rather than periodic review. Least privilege is still worth pursuing, but it’s table stakes, not a finish line.

“Identity is the real crux of security today,” Rebholz says. “With how technology is being built and how systems are operated, identity is the central thing that’s either going to make or break you. Take the time to round out your detection program to make sure you’re getting that session-based activity, so that you’re not just relying on that front door. You have to assume the attacker is going to bypass it.”

Still want to hear it straight from Jason? Watch the full conversation below.