Who is accountable when a malicious OAuth app keeps reading mail after a password reset?

Why This Matters for Security Teams

A malicious OAuth app can survive a password reset because the app was never controlled by the password in the first place. Once consent is granted, the app may keep its token-based access until the organisation revokes the grant, rotates the linked session, or disables the connected identity path. That makes accountability a governance issue, not just a user-behaviour issue.

This is why identity teams increasingly treat OAuth grants like standing access, with ownership, review, and revocation requirements similar to privileged access. The control gap is visible in breach analysis such as the Salesloft OAuth token breach, where token-based access outlived normal password-centric assumptions. Current guidance from the NIST Cybersecurity Framework 2.0 points teams toward governance, asset visibility, and recovery discipline rather than relying on user resets alone.

NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which helps explain why these grants are often discovered only after data access has already persisted. In practice, many security teams encounter lingering OAuth access only after mailbox activity has been abnormal for days or weeks, rather than through intentional lifecycle review.

How It Works in Practice

Accountability should be assigned to the organisation that approved the OAuth app and failed to govern its lifecycle. The user may have triggered the consent flow, but the organisation owns the access decision, the app registry, and the revocation process. In operational terms, the app should be tracked as a non-human identity with a defined purpose, owner, scope, and expiration condition.

Effective handling usually requires four linked actions:

• Inventory every OAuth app, the mail scopes it holds, and the business owner responsible for it.
• Review whether the scope is still needed, especially when access includes inbox read, send, or delegated offline access.
• Revoke the app grant directly at the provider, not just the password, because token validity is independent of the password reset.
• Apply conditional approval, periodic access review, and alerting for unusual mail access patterns.

For agentic or automated mail readers, the same logic should extend to workload identity and runtime authorisation. Instead of trusting a long-lived token, current best practice is evolving toward short-lived, task-bound credentials and policy checks at request time, which aligns with the direction of the State of Non-Human Identity Security research and with CISA Zero Trust guidance. The lesson from incidents such as the Dropbox Sign breach is that a credential reset does not equal access removal when the grant lives outside the password lifecycle.

These controls tend to break down when organisations let business units approve apps informally through self-service consent and never reconcile those grants against a central app registry.

Common Variations and Edge Cases

Tighter OAuth governance often increases operational friction, requiring organisations to balance user convenience against the risk of persistent inbox access. That tradeoff becomes sharper when mail-scanning tools, CRM sync tools, and AI assistants all request similar scopes, because the business value can look legitimate even when the access model is too broad.

There is no universal standard for this yet, but current guidance suggests treating high-risk mail scopes as privileged access. That means a benign-looking app that reads mail should still be subject to ownership assignment, reauthorization, and periodic review. If the app is vendor-managed, accountability does not disappear; it shifts to the organisation that accepted the integration and failed to enforce revocation controls.

Edge cases often involve shared mailboxes, delegated admin consent, or apps connected through a third-party tenant. In those environments, password resets are even less meaningful because the effective access path may be service-to-service rather than user-to-user. The DeepSeek breach is a reminder that downstream trust chains can be broader than the original user session. Practitioners should assume that any app granted offline or mailbox-wide scope can continue reading unless the grant itself is explicitly removed.

Related resources from NHI Mgmt Group

• Who is accountable when risk remains open after security flags it?
• Who is accountable when spoofed mail reaches the inbox despite failed authentication?
• Who is accountable when a compromised session persists after remediation?
• Who is accountable when a malicious message arrives through a vendor account?