Identity Threat Detection: Why MFA Alone Is No Longer Enough

Harshil Shah
5 days ago
7 min read

Audience: CISOs, IAM leaders, security operations teams, risk leaders, and technology executives responsible for identity security, access control, and account takeover prevention.

MFA still matters. Nobody serious is arguing against it.

But MFA is not a complete identity security strategy anymore. Attackers have learned how to work around weak MFA, trick users into approving prompts, steal session tokens, abuse trusted devices, exploit recovery flows, and hide inside normal-looking access patterns. A login can pass MFA and still be dangerous.

That is the shift CISOs need to deal with. The job is not just proving that a user authenticated. The job is detecting whether the identity is behaving like it should after access is granted.

Identity threat detection gives security teams that second layer of visibility. It watches for suspicious sign-ins, token misuse, impossible travel, privilege changes, unusual application access, new device patterns, and behavior that does not fit the user, role, or business context.

MFA Raised the Bar, But Attackers Moved

MFA makes account compromise harder because attackers need more than a password. CISA still recommends MFA and encourages phishing-resistant methods because MFA adds protection even if a password is stolen. CISA also points organizations toward phishing-resistant MFA methods where possible.

The problem is that not all MFA is equal.

SMS codes can be exposed through SIM swap or social engineering. Push prompts can be abused through fatigue attacks. One-time passcodes can be captured by adversary-in-the-middle phishing kits. Session tokens can be stolen after a valid login. Recovery flows can become the soft spot if they are weaker than the main login path.

Most companies do not fail because they turned MFA on. They fail because they treat MFA as the finish line.

What MFA Does Not See

MFA usually answers one question: did the user complete an authentication challenge?

That question matters, but it does not cover the rest of the identity risk story. A successful MFA challenge does not prove the device is clean. It does not prove the session token was not stolen. It does not prove the user meant to approve the request. It does not prove the access still makes sense 20 minutes later.

Identity threats that can live beyond MFA

Token theft: attackers reuse session tokens to access systems without repeating the full login process.
MFA fatigue: users are bombarded with prompts until one gets approved.
Adversary-in-the-middle phishing: fake login flows proxy the real sign-in and capture credentials, MFA responses, or session data.
Consent abuse: malicious or over-permissioned apps get access to user data.
Privilege escalation: a compromised account gains or abuses elevated access.
Dormant account abuse: old accounts, test accounts, service accounts, and contractor accounts become quiet entry points.

OWASP’s guidance on session hijacking explains the core issue: web sessions often rely on tokens after authentication, and attackers who get control of a valid session can bypass the normal login moment. That is why identity monitoring cannot stop at login. OWASP

Identity Threat Detection Looks at Behavior, Not Just Login Success

Identity threat detection is the monitoring layer that asks, “Does this access still make sense?”

That means looking across users, devices, locations, applications, permissions, tokens, and activity. A normal login from a known device during business hours may be low risk. The same user downloading unusual volumes of data from a new location after a password reset and MFA method change? Different story.

A strong identity threat detection program watches for patterns like:

New or unusual sign-in locations
Impossible travel or suspicious geography
New device registration followed by high-risk access
MFA method changes
Repeated failed logins followed by a successful one
Unusual OAuth app consent
Privilege assignment changes
Access to sensitive apps outside normal working patterns
Suspicious mailbox rules, forwarding, or data exports
Token replay or session anomalies where tooling supports detection

One alert may not mean much. A chain of small signals often does.

Phishing-Resistant MFA Should Be the Direction

Some MFA methods are easier to phish than others. That matters.

Phishing-resistant MFA, such as FIDO2 security keys, passkeys, and certificate-based approaches, reduces the risk that a user can be tricked into handing over a reusable secret. OWASP notes that U2F-style tokens are resistant to phishing because the private key does not leave the token, and CISA also encourages organizations to move toward phishing-resistant MFA methods.

Where to prioritize phishing-resistant MFA first

Administrators and privileged users
Finance and payroll roles
Security operations accounts
Executives and executive assistants
Developers with production access
Users with access to sensitive customer, employee, or regulated data

Do not wait for perfect coverage. Start with the accounts that can hurt the business fastest.

But don’t confuse stronger MFA with full detection

Phishing-resistant MFA reduces major attack paths. It still does not replace monitoring, access governance, device health, session controls, privilege management, and response playbooks.

What Identity Threat Detection Should Include

The best identity programs combine prevention and detection. MFA is prevention. Conditional access is prevention. Least privilege is prevention. Identity threat detection is how security sees the weird behavior that slips through or starts after access is granted.

Core capabilities CISOs should expect

Risk-based sign-in analysis: detect unusual authentication patterns and risky login behavior.
User behavior analytics: compare current activity against normal user and peer behavior.
Privilege monitoring: watch role changes, admin activity, and privilege escalation paths.
Session and token visibility: identify signs of token misuse where platform telemetry allows it.
Application access monitoring: detect suspicious access to sensitive apps, files, mailboxes, and data stores.
Device context: include device compliance, endpoint health, and managed versus unmanaged status.
Automated response: revoke sessions, reset credentials, require step-up authentication, disable accounts, or isolate devices.

Microsoft’s identity guidance describes token theft protection as a layered defense that includes reducing attack surface, detecting suspicious sign-ins, and preparing a mitigation strategy. That framing is right. There is no single switch for this. Microsoft Learn

Recovery Flows Deserve More Attention

Account recovery is often weaker than account login. Attackers know it.

If a user can reset MFA, change a phone number, add a new authenticator, or recover an account through a poorly controlled help desk process, the company may have a bypass path sitting in plain sight. OWASP’s MFA guidance warns that recovery mechanisms must not create an easy way for attackers to bypass MFA and hijack accounts.

Recovery controls worth tightening

Require stronger verification for MFA resets
Log and alert on MFA method changes
Delay or review high-risk changes for privileged users
Train help desk teams on social engineering attempts
Remove stale phone numbers and unused authenticators
Require manager or security approval for sensitive account recovery

A mature identity program treats recovery as part of the attack surface, not an administrative chore.

Identity Detection Needs Ownership, Not Just Tooling

Identity threat detection often fails because nobody owns the full chain.

IAM owns policy. The SOC owns alerts. IT owns devices. HR owns joiner, mover, and leaver data. App owners own access inside business systems. Cloud teams own privileged roles in cloud platforms. The CISO owns the risk, but the signals are scattered.

Someone has to connect the dots.

Questions CISOs should ask internally

Who reviews high-risk sign-ins?
Who investigates suspicious MFA changes?
Who can revoke sessions quickly?
Who owns privileged access reviews?
Who validates that terminated users lose access everywhere?
Who monitors service accounts and non-human identities?
Who decides when identity risk becomes an incident?

That last question matters. Identity alerts die in queues when teams disagree on severity.

A Practical Identity Threat Detection Roadmap

Most organizations do not need a year-long identity transformation before they improve. Start with the riskiest accounts and the most common attack paths.

First 30 days

Inventory privileged accounts, service accounts, and high-risk business users
Review MFA methods and remove weak or unused options where practical
Turn on alerts for MFA changes, risky sign-ins, and impossible travel
Define who can revoke sessions and disable accounts during investigation
Review account recovery and help desk verification steps

Next 60 days

Move privileged users toward phishing-resistant MFA
Implement conditional access based on user, device, app, location, and risk
Connect identity logs into the SIEM or detection platform
Create playbooks for token theft, account takeover, and suspicious MFA reset
Start periodic access reviews for critical apps

Next 90 days

Expand detection to OAuth app consent, mailbox rules, cloud admin activity, and data access patterns
Automate high-confidence response actions
Review non-human identities and long-lived secrets
Test identity incident response through tabletop exercises
Report identity risk trends to leadership in business terms

Do the boring work first. Attackers love boring gaps.

Metrics That Show Identity Risk Is Improving

CISOs need identity metrics that show exposure and response quality, not just “MFA is enabled.”

Phishing-resistant MFA coverage: especially for privileged and high-risk users
Weak MFA method count: SMS, voice, and other higher-risk methods still in use
Risky sign-in response time: how quickly alerts are reviewed and contained
MFA reset volume: changes by user type, department, and risk level
Stale account count: inactive users, contractors, test accounts, and orphaned accounts
Privileged access review completion: critical roles reviewed and corrected
Session revocation time: how quickly security can cut off suspected compromise
Identity incidents by root cause: phishing, token theft, recovery abuse, privilege misuse, or vendor access

“MFA adoption is 100%” looks good on a slide. It may still hide token theft, weak recovery flows, and over-permissioned accounts.

FAQ: Identity Threat Detection and MFA

Is MFA still worth using?

Yes. MFA remains a basic security control and should be enabled broadly. The issue is that MFA alone cannot detect stolen sessions, suspicious behavior after login, weak recovery flows, or privilege misuse.

What is identity threat detection?

Identity threat detection is the process of monitoring users, devices, sessions, permissions, and application activity for signs of account takeover, token theft, unusual access, privilege escalation, or other identity-based attacks.

How do attackers bypass MFA?

Common paths include phishing kits that capture session data, MFA fatigue attacks, weak SMS-based methods, account recovery abuse, malicious app consent, and stolen tokens that allow access after authentication has already happened.

What is phishing-resistant MFA?

Phishing-resistant MFA uses methods such as FIDO2 security keys, passkeys, or certificates to reduce the chance that a user can be tricked into giving attackers a reusable credential or approval.

Where should companies start with identity threat detection?

Start with privileged users, high-risk business roles, weak MFA methods, MFA reset monitoring, risky sign-in alerts, session revocation procedures, and access reviews for critical applications.

MFA Is the Door Lock, Not the Security Program

MFA is still necessary. It is not enough by itself.

Identity security now has to account for behavior after login, session risk, token theft, recovery abuse, device context, privilege changes, and suspicious access patterns. CISOs should keep improving MFA, especially by moving high-risk users toward phishing-resistant methods, but the larger move is building detection and response around identity itself.

For more CISO leadership topics and security strategy insights, visit the CISOMeet.org homepage or browse the latest articles on the CISOMeet.org blog.