TL;DR: Web applications use email addresses as the primary identifier for critical functions in 64.9% to 92.4% of cases, while Proofpoint reports 59% of compromised accounts still had MFA enabled and 54% of ransomware victims had stolen credentials first. The security problem is no longer inbox protection alone, but identity governance for both humans and the AI systems acting on their behalf.
At a glance
What this is: Email has become a shared identity layer for humans and agentic AI, with credential theft and prompt manipulation extending the same attack surface.
Why it matters: IAM, PAM, and identity detection teams have to treat inbox identity, recovery flows, and agent workflows as one governance problem rather than separate security domains.
By the numbers:
- Between 64.9% and 92.4% of web applications use email addresses as the primary identifier for critical functions such as account creation and password recovery.
- Proofpoint found that 59% of compromised accounts still had MFA enabled, showing that stronger authentication alone does not stop identity compromise.
- According to the Verizon 2025 Data Breach Investigations Report cited by Proofpoint, 54% of ransomware victims had credentials stolen before the ransomware attack.
- According to the Verizon 2025 Data Breach Investigations Report cited by Proofpoint, stolen credentials are the starting point for roughly a third of human-related breaches.
Context
Email is no longer just a communication channel. In most digital systems it is the primary identity key, the password recovery route, and the default account linkage across services, which makes it a governance problem as much as a messaging one.
That matters for IAM because compromise of the inbox often becomes compromise of the identity behind it. When agentic AI systems can read, summarise, and act on email, the control surface expands from user behaviour to machine behaviour acting under that same identifier.
Key questions
Q: What breaks when email is treated as the primary identity for both users and agents?
A: Recovery, authentication, and delegated action all collapse into one trust channel, so a mailbox compromise can reset access across many systems and trigger automated actions. The failure is not just inbox exposure. It is that one identifier becomes the proof, the recovery path, and the execution channel at the same time.
Q: Why do compromised-password checks matter if MFA is already deployed?
A: MFA reduces some account takeover paths, but it does not make a reused or breached password harmless. Compromised-password checks stop known-bad credentials from being chosen in the first place, which cuts the amount of easy-to-abuse identity exposure before other controls have to intervene.
Q: How can security teams tell whether email recovery is creating too much risk?
A: Look for high-value applications that still use email for password reset, enrolment confirmation, or ownership proof. If those flows can rebind access after mailbox compromise, the recovery path is too powerful. The signal is not whether the inbox is protected, but whether losing it would unlock too many downstream systems.
Q: How should organisations govern AI assistants that can read and act on inbox messages?
A: They should define those assistants as delegated non-human identities with explicit message scope, action scope, and escalation limits. The goal is to prevent natural-language instructions from becoming unauthorised workflow triggers. Review what the agent can read, what it can do, and what requires human confirmation.
Technical breakdown
Why email became the identity anchor
Email works as an identity anchor because it is globally unique, easy to verify, and already embedded in account creation, password reset, and cross-service recovery flows. That convenience also creates concentration risk: the same identifier often proves account ownership, routes recovery, and links the user across multiple applications. In identity terms, email is not merely contact data. It is a durable identity token that many systems trust too broadly. Once attackers obtain access to the mailbox or the recovery path, they often inherit the right to reset or rebind access elsewhere. That is why email compromise so often becomes identity compromise rather than a single account event.
Practical implication: Practitioners should map every system that treats email as proof of identity and reduce recovery dependence on a single mailbox.
Why MFA does not end credential abuse
MFA raises the cost of compromise, but it does not eliminate identity takeover when attackers can phish tokens, force approvals, intercept sessions, or exploit user fatigue. Proofpoint cites cases where compromised accounts still had MFA enabled, which is a reminder that authentication strength and identity resilience are not the same thing. A valid second factor does not protect a recovered password flow, a hijacked session, or a mailbox exposed through social engineering. For practitioners, the useful question is not whether MFA exists, but whether the surrounding lifecycle and detection controls can still stop takeover after the initial authentication step has been bypassed or reused.
Practical implication: Treat MFA as one control in a broader identity compromise path, not as proof that an account is safe.
How agentic AI turns email into a runtime trust boundary
Agentic AI changes the trust model because the system is no longer only reading email on behalf of a user. It can interpret messages, generate replies, trigger downstream actions, and process documents from the same inbox flow. That means email now acts as both an identity boundary and an execution channel for software that can make decisions. When an agent is assigned an email address, the organisation has effectively created a machine identity with human-grade trust signals and workflow reach. The risk is not just prompt injection or data exposure. It is delegated action taken through an identity channel that was designed for human-paced interaction.
Practical implication: Security teams should govern agent inbox access as privileged execution, not as ordinary collaboration access.
Threat narrative
Attacker objective: The attacker wants to turn a trusted email identity into a reusable path for account takeover, data access, and automated action.
- Entry begins with email address reuse and phishing or social engineering that targets the inbox or the recovery path rather than the application directly.
- Credential access follows when the attacker captures passwords, tokens, or recovery access, even in environments where MFA is present.
- Escalation occurs when the compromised inbox is used to reset accounts, approve access, or steer agentic workflows that trust email as an instruction channel.
- Impact is account takeover, downstream data exposure, and, in agentic environments, malicious actions executed through the inbox and its linked automation.
Breaches seen in the wild
- Change Healthcare breach 2024: A stolen login on a Citrix portal without MFA led to ALPHV ransomware, a $22 million ransom and 192.7 million people affected.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Email identity has become an identity governance surface, not just a security control point. The article is right to frame email as the de facto digital identifier, because recovery, authentication, and cross-service linkage all converge there. That makes mailbox governance, recovery design, and identity verification part of the same control plane. The practitioner conclusion is that email must be governed as identity infrastructure, not treated as a communication asset.
Agentic AI turns inbox access into delegated execution. Once an AI system can read and act on email, the control issue shifts from message protection to authority delegation. The relevant governance question becomes who or what is allowed to interpret and execute actions from the mailbox, under what boundaries, and with what monitoring. Practitioners should treat agent inbox access as a privileged operating context, not a convenience feature.
Shared identifiers create shared blast radius. When a single email address binds account creation, password resets, vendor portals, and agent workflows, compromise propagates across unrelated systems faster than most IAM programmes assume. This is the identity blast-radius problem: one identifier, many trust decisions. The practitioner implication is that recovery and linkage paths deserve the same scrutiny as primary authentication.
Mailbox-centric security is now insufficient for identity resilience. The article shows that identity compromise can persist even when MFA is present, because the attack path often shifts to recovery, session abuse, or social engineering. That means identity programmes must measure whether an account can still be rebound, reset, or re-authorised after mailbox compromise. The practitioner conclusion is to test the full identity lifecycle, not only login success.
Email trust assumptions were built for human-paced workflows and are now colliding with machine-paced action. Systems that assume an email recipient will read, decide, and respond manually are exposed when the recipient is an agent that can process instructions continuously. The implication is that governance has to distinguish human inbox trust from machine inbox authority before agentic deployment scales.
From our research library:
- Stolen credentials were involved in 22% of breaches overall and in 88% of basic web application attacks, according to Verizon's 2025 Data Breach Investigations Report.
- Read next: Agentic AI Identity Guide
What this signals
Identity blast-radius control: Email-based recovery should be treated as a privilege multiplier, not a convenience feature. If one mailbox can reset many accounts, then compromise of a single inbox becomes a cross-system identity event, which is why recovery design now belongs in the same conversation as IAM and PAM.
Agentic AI widens the trust boundary further because inboxes can now be read and acted on by software, not only by people. That changes the control question from who owns the mailbox to what authority the mailbox can delegate, and it is exactly where human-paced governance assumptions begin to fail.
The operational test is simple: if losing an email account would let an attacker rebind access, approve flows, or steer an agentic workflow, the organisation has an identity governance problem. Security teams should measure recovery path power, not just login hardness.
For practitioners
- Map every email-based recovery path Inventory where email can reset passwords, approve enrolment, or restore access, then remove it from high-value accounts where possible.
- Classify agent inboxes as privileged identities Treat any AI system that reads or sends email as a governed identity with explicit ownership, scoped access, and revocation controls.
- Test identity compromise beyond MFA Simulate token theft, recovery abuse, and session replay so detection and response can catch takeover even when a second factor exists.
- Separate human and machine email authority Define which mailbox actions require human review versus which can be executed by an agent, and log both paths distinctly.
- Harden identity recovery channels Reduce reliance on email for step-up, reset, and ownership confirmation on systems that hold sensitive data or administrative privileges.
Key takeaways
- Email has evolved from a communication channel into a high-value identity layer that connects login, recovery, and delegated action.
- Credential theft and recovery abuse still drive many compromises, even where MFA is deployed, so authentication strength alone does not define resilience.
- The control question now is whether mailbox access can be limited, reviewed, and revoked before it becomes a cross-system privilege bridge.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Email compromise and recovery abuse are fundamentally authentication problems for non-human and human-linked identities. |
| NHI-10 — Human Use of NHI | Agent inboxes blur human and machine authority by letting software act through human communication channels. | |
| Recommendation — Review email-linked authentication flows and reduce trust in recovery paths that can rebind access after compromise. Separate human email authority from machine email authority and log the agent's delegated actions explicitly. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents reading and acting on email can misuse delegated identity and privilege inside ordinary workflows. |
| Recommendation — Constrain agent identity scopes so inbox access cannot become unrestricted downstream execution. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on controlling who or what can use email-linked identity permissions and recovery rights. |
| Recommendation — Align email recovery, inbox access, and delegated actions to least-privilege authorisations. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern described starts with credential theft and expands through account and workflow movement. |
| Recommendation — Map email compromise to credential access and downstream lateral movement across linked services. | ||
Key terms
- Email identity: The use of an email address as the practical identifier that ties a user or system to accounts, recovery, and notifications. In modern environments, email identity often becomes the trust anchor for authentication flows, which makes inbox compromise an identity problem rather than a messaging problem.
- Identity Recovery: Identity recovery is the process of restoring identity systems to a trusted state after compromise. It includes containment, forensic validation, removal of persistence, and confirmation that access controls and directory relationships no longer expose the environment.
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org