You Have EDR, MFA, and SIEM. Here's the Breach Vector None of Them Were Built For.

Your EDR stops attackers. What stops them after they log in?

Most security teams can’t answer that question. Neither could the ones who got breached.

The Stack You Have Was Built for a Different Problem

EDR catches malware, ransomware, known attack signatures — things that look wrong to a system built to detect external threats. MFA stops unauthorized logins at the door. SIEM aggregates logs and surfaces alerts based on rules your team writes against patterns that have already been defined.

All of it is built on the same assumption: the threat is trying to get in.

The majority of modern breaches involve legitimate credentials, trusted identities, or authorized access paths — not attackers who broke through your defenses, but credentials that authenticated exactly the way they always do, users with legitimate access doing something they shouldn’t, service accounts operating outside their normal scope. The threat is already inside. It logged in correctly. And your stack has no model for what happens next.

The Question Your Security Vendor Is Hoping You Don’t Ask

When you ask your security vendor if you’re covered for insider threat, the answer is yes. It’s always yes. They’ll point to SIEM correlation rules, user activity logging, anomaly detection capabilities. All of it sounds like coverage.

What they won’t explain is the difference between logging activity and detecting a deviation from normal.

Your SIEM logs what users do. It flags what matches a rule. But rules are written against known bad patterns — a user accessing a system they’ve never accessed, a login from an unusual location, a spike in data transfer volume. Those rules catch the obvious cases. They don’t catch the user who gradually escalates access over 90 days. They don’t catch the compromised credential that operates entirely within the legitimate permissions of the account it took over. They don’t catch the service account that starts doing something slightly different from what it’s always done — because nobody built a baseline for what “always done” looked like.

The real question isn’t whether your vendor logs insider activity. It’s whether your platform knows what normal looks like for each user, each service account, and each entity in your environment — and whether it alerts when that normal changes.

Many platforms claim this capability. Far fewer deliver meaningful behavioral baselines without extensive tuning, identity maturity, and operational discipline.

What Your Stack Is Logging and What It’s Actually Missing

There are four categories of insider threat. Your stack probably covers one of them well.

Malicious Insiders

Employees who intentionally exfiltrate data generate the most dramatic headlines but represent the smallest percentage of incidents. They’re also the easiest to catch after the fact because intent is usually visible in hindsight.

Negligent Insiders

Employees who create exposure through carelessness, misconfiguration, or poor data handling are far more common and far less visible. No malicious intent means no behavioral signature that looks obviously wrong. The damage accumulates quietly.

Compromised Credentials

External attackers operating inside your environment using stolen or purchased login credentials are the fastest growing category. The attacker authenticates correctly. They operate within the permissions of the account they’ve taken over. To your SIEM, it looks like a legitimate user doing legitimate things. The rules don’t fire because nothing matches a known bad pattern. The breach progresses until the attacker does something dramatic enough to trip a rule — by which point the damage is already done.

AI Agents

AI agents operating with legitimate credentials and system access are the fourth category — the newest and the least monitored. For this discussion, AI agents include autonomous workflows, orchestration agents, and AI-powered systems operating with credentials and access to enterprise resources — Microsoft Copilot, internal automation, LangChain agents, MCP-connected systems, and similar tools your teams are deploying right now.

Unlike human users, AI agents can operate continuously, interact with multiple systems simultaneously, and execute actions at machine speed. A compromised or misconfigured agent can generate business impact far faster than a traditional insider event — which makes behavioral baselining even more critical for non-human identities than for human ones. Most organizations deploying AI agents right now have no behavioral baseline in place for what those agents should be doing. When one deviates, there’s no tripwire. There’s only the discovery after the fact.

Your EDR was built for none of these scenarios. Your MFA blocked the front door but the compromised credential already has a key. Your SIEM has rules for the dramatic cases. The quiet ones — the gradual escalation, the compromised account operating within scope, the service account doing something slightly different — require a different capability entirely.

The One Capability Your Stack Is Missing — And Why Vendors Don’t Lead With It

User and Entity Behavior Analytics — UEBA — is the capability built specifically for this problem.

Where signature-based detection asks “does this match a known bad pattern,” UEBA asks “does this match what this specific user, account, or entity normally does?” It builds a baseline of normal behavior per identity — login times, access patterns, data volumes, system interactions. When something deviates from that baseline, it flags the deviation regardless of whether it matches a known threat signature.

A compromised credential that starts accessing systems the account has never touched gets flagged — not because it triggered a rule, but because it deviated from the account’s established normal. A service account that suddenly starts pulling three times its normal data volume gets flagged — not because a rule fired, but because the baseline was there to compare against.

The difference between your current coverage and UEBA coverage is the difference between a security system that knows what bad looks like and a security system that knows what normal looks like. Only one of them catches the threat that authenticated correctly.

Here’s how the four tools compare across the breach vectors that matter most:

EDR is strong on malware, ransomware, and known attack signatures. It has limited visibility into credential-based threats and no model for behavioral baselines or AI agent activity.

MFA stops unauthorized logins at the door. Once a credential is legitimately obtained — phished, purchased, or stolen — MFA has already done its job. It has no role in detecting what happens after authentication.

SIEM aggregates and correlates logs across your environment. It surfaces alerts based on rules written against known bad patterns. It does not build per-identity behavioral baselines and cannot detect deviation from normal without those baselines in place.

UEBA builds a behavioral baseline per identity — human, service account, and AI agent. It detects deviation from that baseline regardless of whether the activity matches a known threat signature. It is the only capability in this list designed specifically for the insider threat problem.

UEBA isn’t magic. Behavioral analytics generate noise when identity management, access controls, and data classification aren’t mature underneath them. Organizations that deploy UEBA on top of a poorly governed environment get alert fatigue, not answers. The platforms that produce real value are the ones layered on top of strong IAM, clean logging, and a defined understanding of what each identity should be doing. If those foundations aren’t in place, building a behavioral baseline is harder — and the false positive rate will tell you.

A note on service accounts: Most organizations have more service accounts than they’ve mapped — automation workflows, RPA, APIs, integrations, AI agents — many with credentials that haven’t rotated in months and privileges that haven’t been reviewed since deployment. The questions most security teams can’t answer about their own service accounts: how many exist, who owns each one, which have accessed something outside their documented scope in the last 30 days, and which have no behavioral monitoring in place at all. That’s the fastest growing attack surface in most enterprise environments right now. And it’s the one most platforms weren’t designed to monitor at the identity level.

Do You Actually Have This Gap? Five Questions to Answer Right Now

Before evaluating vendors or platforms, answer these five questions about your own environment. They don’t require a tool. They require access to whoever owns your identity and access management.

1. Which accounts accessed your most sensitive data last week — and does that list look right to you?

2. Which service accounts changed their behavior in the last 30 days — accessed a new system, pulled an unusual data volume, operated at an unusual time?

3. Which users have steadily increased their privilege levels this quarter — and was each escalation formally approved?

4. Which AI agents or automation workflows in your environment have accessed data or systems outside what their function requires?

5. Which identities — human or machine — would generate an alert today if their credentials were compromised and used by someone else?

If you can answer three of five with confidence, your visibility is better than most. If you can’t answer two or more, you have a gap — not in your tools, but in your baseline. You can’t detect deviation from normal if you don’t know what normal looks like.

The Question to Ask Before Your Next Security Renewal

Not “do you have insider threat detection?” Every vendor will say yes.

Ask this instead:

“Can you show me a per-user behavioral baseline for an account in my environment, demonstrate how your platform would have flagged a credential compromise that operated within normal permissions over a 30-day period, and show me what the alert looks like before the attacker does something dramatic?”

A vendor who has built this capability has that demonstration ready. A vendor who has added insider threat to the feature list but not rebuilt the detection model routes you back to the log aggregation dashboard and calls it coverage.

That routing is the answer.

258 Days. That’s How Long the Average Breach Runs Before Anyone Catches It.

The average time to identify a breach is 194 days. The average time to contain it is another 64 days. That’s 258 days of an attacker operating inside your environment — accessing systems, moving data, escalating privileges — while your security stack logs activity it has no framework for evaluating.

At machine speed, a compromised AI agent can exfiltrate your entire customer database in minutes. A compromised credential operated by a patient attacker can do the same thing over weeks — slowly enough that no volume spike triggers a rule, gradually enough that the pattern looks like normal user activity to a platform without a behavioral baseline.

The breach that comes from outside leaves forensic evidence of entry. The breach that comes from inside leaves evidence that looks, at every step, like someone doing their job.

The business consequences of that gap aren’t theoretical. A breach involving compromised credentials in a regulated environment — healthcare, financial services, any organization handling customer PII — triggers notification requirements, audit findings, and potential regulatory fines regardless of whether the attacker came from outside or inside. Cyber insurance carriers are increasingly asking specifically about behavioral monitoring and identity governance before underwriting. And the board conversation after a breach that operated undetected for eight months inside a security stack that was supposed to cover it is a different conversation than the one you want to be having.

The question isn’t whether you’re collecting enough logs. Most organizations already are. The question is whether your security stack understands what normal looks like across your users, service accounts, and AI-driven identities. If it doesn’t, the next compromised credential may look exactly like business as usual — until it’s too late.

A peer just had an incident. Your board is starting to ask. Or you’re 90 days from a renewal and not certain your current platform actually baselines behavior — not logs it, baselines it.

This is where that conversation starts→ 

967 providers. No pitch. No prep. Just answers.

Get Started →