Mailbox forwarding rules expose offboarding blind spots in IAM

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Artemis Security's blog post: A first-ever email forwarding rule created during offboarding can evade standard identity controls even when login, device, and MFA signals look normal.

Why it matters: It matters because IAM and IGA teams often treat account disablement as the end of access, but mailbox-level persistence can keep moving data after the user is offboarded.

Context

Mailbox forwarding is an access-path problem, not just an email convenience issue. If offboarding only disables the account and revokes tokens, mailbox rules, forwarding attributes, and delegate access can remain active and continue moving information outside the organisation.

In this case, the governance gap is between identity state and mailbox state. The identity profile showed a termination date, but the mailbox still had enough autonomy to create a new forward to a personal address before the account was disabled.

That makes the problem squarely relevant to IAM, IGA, and NHI-style lifecycle thinking. Controls that certify sessions and credentials can still miss a data-exfiltration path embedded in application state.

Key questions

Q: What breaks when offboarding does not remove mailbox forwarding rules?

A: The offboarding process removes the user’s account but leaves a separate data-routing path intact. Mail can still be redirected to an external inbox after disablement, which means the organisation has revoked identity access without revoking message delivery. That creates a persistence channel outside normal session controls and can continue after the user departs.

Q: Why can a clean MFA session still be a mailbox security problem?

A: Because MFA proves who authenticated, not whether the mailbox action was appropriate. A legitimate user on a trusted device can still create a forwarding rule that diverts corporate mail elsewhere. Security teams need to evaluate mailbox-state changes separately from sign-in assurance and device trust.

Q: How do security teams spot risky forwarding behaviour during offboarding?

A: Correlate mailbox-rule creation with termination dates, then prioritise first-time forwarding actions and destinations that match personal addresses on file. A rule that appears while offboarding is already in motion is far more suspicious than the same rule created during normal employment. History and lifecycle context matter more than the rule type alone.

Q: Who owns mailbox-state revocation in an identity programme?

A: IAM and IGA teams should own the control requirement, while messaging or collaboration administrators may execute the technical steps. The key is that mailbox routing, forwarding attributes, and delegate access must be treated as part of the offboarding standard, not as an optional mail admin follow-up.

Technical breakdown

Mailbox rules as a persistence channel

Inbox rules and external forwarding attributes are mailbox-side controls that can reroute message delivery without changing the user’s primary login state. Because they operate inside the email platform, they often sit outside the same detection logic used for authentication, device trust, or MFA posture. That means a user can remain fully legitimate at the identity layer while quietly changing where mail is delivered. In security terms, the control plane for access and the data plane for mail routing are different. If the mail platform preserves a forwarding rule after disablement, the account may be gone while the information flow remains live.

Practical implication: enumerate and review mailbox rules as part of offboarding, not after an incident review.

Why strong MFA did not change the verdict

Phishing-resistant MFA confirms who authenticated, but it does not evaluate whether the authenticated user should be permitted to redirect mailbox content. That distinction matters because MFA is an identity assurance control, while forwarding rules are an authorisation and data-handling concern. The article shows a clean session, healthy managed device, and no failed logins, yet the mailbox action still represented risk. This is a common blind spot in IAM programmes: authentication health can be perfect while post-authentication activity still creates exfiltration exposure.

Practical implication: separate authentication confidence from mailbox action approval in your monitoring and response workflows.

Offboarding that kills the account but not the mailbox state

Routine deprovisioning often focuses on sessions, tokens, and account access, but mailbox state can persist independently. If a forwarding rule is created before disablement, the rule can survive the user’s departure and keep relaying mail to an external inbox. That is why offboarding needs to be treated as a state transition across identity, application, and content-routing layers, not a single account action. The operational risk is not just that a mailbox remains open. It is that the mailbox continues to make delivery decisions after accountability has moved on.

Practical implication: include mailbox-state revocation in the same runbook that disables accounts and revokes tokens.

Threat narrative

Attacker objective: The objective was to move incoming corporate email to a personal inbox in a way that would survive offboarding and continue after account disablement.

1. Entry occurred through a legitimate user session on a managed device with valid phishing-resistant MFA, not through credential theft or malware.
2. The user created the first-ever forwarding rule for the mailbox and pointed it at a personal Gmail address, then extended it to forward as well as redirect.
3. The mailbox rule created a persistence path that could continue after account disablement because offboarding does not automatically remove mailbox rules.
4. The impact was a potential continued mail diversion channel that could outlive the user’s corporate access and expose internal messages externally.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

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

Mailbox forwarding creates an offboarding blind spot when identity governance stops at account disablement. The control failure is not weak authentication, it is incomplete lifecycle coverage. A mailbox can still alter delivery behaviour after the identity has been marked for termination, which means the governance boundary was drawn too narrowly. Practitioners need to treat mail-routing state as part of the access surface, not as a separate operational detail.

Strong MFA can coexist with harmful mailbox-state abuse. This case proves that authentication confidence does not equal authorisation safety. The session was clean, the device was known, and the activity still created an external data path. The lesson for IAM teams is that good sign-in signals cannot be allowed to mask post-authentication control gaps in collaboration platforms.

First-ever forwarding rules are high-signal because they combine novelty with destination risk. The novelty matters because a mailbox with no prior forwarding history suddenly changing behaviour is structurally different from routine user configuration. The destination matters because personal addresses on file create a plausible exfiltration endpoint that can look administratively normal unless lifecycle context is applied. This is exactly where mailbox-history analytics add value to offboarding governance.

Mailbox-state revocation is a lifecycle control, not an email admin task. The organisation’s identity programme has to own what happens to mailbox routing, delegate access, and forwarding attributes when a user leaves. If those artefacts remain live, the organisation has deprovisioned the person but not the channel. That gap is now a governance issue, not a tooling issue.

Identity programmes should name the concept of email-delivery persistence as a control problem. The useful mental model here is mailbox-state persistence: access can be removed while delivery continues. That concept helps teams align IAM, IGA, and messaging operations around a shared failure mode rather than three separate checklists. The practitioner conclusion is simple: offboarding is incomplete until routing state is removed.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Around 59% of companies report experiencing a data breach related to poorly managed offboarding processes.
• Read next: NHI Lifecycle Management Guide

What this signals

Mailbox-state persistence: organisations need a specific governance model for email delivery rules, because identity disablement does not automatically stop message routing. When a user is leaving, the meaningful question is no longer only whether the account is active, but whether the mailbox can still move data outside the organisation.

This is a practical offboarding design issue for IAM and IGA teams. Joining termination events to mailbox-rule creation gives defenders a way to distinguish routine user behaviour from a latent exfiltration path, especially when the destination matches a personal address already on file.

For practitioners

• Add mailbox-state checks to offboarding Require rule enumeration, external-forwarding review, and delegate-access inspection before a mailbox is considered fully offboarded.
• Alert on first-ever forwarding rules Flag any new inbox rule that forwards or redirects to an external or personal address, especially when the mailbox has no prior forwarding history.
• Join identity lifecycle data to mailbox monitoring Correlate termination dates from the identity provider with mailbox-rule creation so a change becomes high priority when it intersects offboarding.
• Treat strong MFA as necessary but not sufficient Use phishing-resistant MFA and trusted device signals to confirm the actor, then evaluate whether the mailbox action itself should be allowed to stand.

Key takeaways

• The breach surface here was not password theft or MFA failure, but a mailbox-level forwarding rule that could continue after the account was disabled.
• The strongest evidence was contextual rather than technical: a first-ever forwarding rule, a personal destination, and a termination date already set in the identity profile.
• Offboarding only closes the incident if it revokes mailbox routing state as well as identity access, because delivery controls can outlive the user session.

Key terms

• Mailbox Rule Persistence: Mailbox rule persistence occurs when an attacker creates forwarding, deletion, or filtering rules that keep control of a compromised inbox after the initial login. These rules can hide evidence, redirect messages, and preserve access even when the password is changed.
• Forwarding rule novelty: Forwarding rule novelty describes a mailbox creating its first external-forwarding or redirect rule within a monitored history window. New behaviour is often more meaningful than the rule type itself because it can indicate a change in intent, especially when paired with offboarding timing or a personal destination.
• Offboarding blind spot: An offboarding blind spot is a governance gap where account disablement is treated as the end of access, but application-state controls remain active. In email systems, that blind spot can leave forwarding rules, delegate permissions, and mailbox attributes untouched even after the user leaves.
• Mailbox-level exfiltration path: A mailbox-level exfiltration path is any email platform setting that moves messages to an external destination without using a traditional login compromise. It can be created by a legitimate user, which makes authentication telemetry look clean while the information flow becomes unsafe.

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.