A mailbox feature that allows one account to act on behalf of another account for reading, sending, or managing email. Attackers abuse delegated access to hide in trusted workflows, expand visibility into sensitive conversations, and move laterally without immediately changing the victim’s password or obvious login settings.
What Inbox Delegation Actually Changes
Inbox delegation changes who can act inside a mailbox without becoming the primary account holder. That makes it an access and trust feature, not just a convenience setting, because delegated users can read sensitive messages, send mail that appears to come from the owner, and manage conversation history, rules, or folders depending on platform permissions.
The security significance comes from the fact that the mailbox is usually trusted by colleagues, customers, finance teams, and automated workflows. A delegated path can therefore preserve normal business operations while quietly extending visibility and action rights beyond what the account owner may realise.
In practice, this is why inbox delegation is often discussed alongside mailbox permissions, auditability, and NIST Cybersecurity Framework 2.0 governance expectations, because the control problem is as much about ownership and oversight as it is about the mailbox feature itself.
How Delegated Mailbox Access Is Used
Legitimate uses are common. Executive assistants may triage correspondence, support staff may monitor shared mailboxes, and compliance or legal teams may need controlled access to communications for retention or review. The feature is useful because it reduces password sharing and enables role-based handling of mail without transferring full account ownership.
The critical distinction is whether delegation is narrowly scoped and monitored, or broadly granted and forgotten. Broad send-as or full-access permissions can create a standing trust path that survives role changes, staffing changes, or temporary business needs long after the original reason has disappeared.
That is why mailbox delegation is operationally close to NIST AI Risk Management Framework-style governance in one important sense, control should follow an explicit purpose, not just a convenient technical capability. The same principle applies to email access even though the subject is not AI.
Where organisations use the feature heavily, they should expect it to interact with audit logging, approvals, periodic review, and offboarding. The real risk is not the existence of delegation, but the accumulation of unreviewed delegated rights.
Why Attackers Abuse Delegated Access
Attackers value delegated inbox access because it is less visible than a fresh login or obvious password reset. Once inside a trusted mailbox workflow, they can monitor sensitive threads, impersonate the owner in ongoing conversations, intercept password resets, and blend malicious messages into ordinary business traffic.
This makes delegation a useful persistence and fraud mechanism. It can support business email compromise, internal impersonation, invoice diversion, and quiet reconnaissance without immediately triggering the kinds of alerts that focus on failed logins or impossible travel.
The broader lesson aligns with OWASP Non-Human Identity Top 10, where overprivilege, weak lifecycle control, and hidden trust paths are recurring failure modes. Inbox delegation is a human-mailbox analogue of the same control problem.
The same access path can also become a lateral movement pivot. If one mailbox is tied to finance approvals, shared documents, account recovery, or customer communications, a delegated compromise can open multiple downstream trust relationships at once.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organisational Context | Delegated mailbox access must align with business purpose and ownership. |
| PR.AA-01 — Identity and Access Management | Inbox delegation is a mailbox access control that grants acting rights on behalf of another account. | |
| PR.PS-03 — Configuration Management | Delegation settings are configuration state that can persist after need has passed. | |
| Recommendation — Define mailbox delegation ownership and review it against business purpose. Restrict delegated mailbox access to explicitly approved roles and scope. Continuously review mailbox delegation settings and remove stale permissions. | ||
| CIS Controls v8 | 6.3 — Disable Dormant Accounts | Delegated access often survives role changes and should be removed when no longer needed. |
| 6.8 — Manage Access Control | Inbox delegation is a direct access control that should follow least privilege. | |
| Recommendation — Remove delegated mailbox access when the business need ends. Apply least privilege to delegated mailbox permissions and send-as rights. | ||
| MITRE ATT&CK | T1114.002 — Email Collection: Remote Email Collection | Abuse of delegated mailbox rights enables collection of mail from trusted accounts. |
| T1098 — Account Manipulation | Changing mailbox delegation or send-as permissions is an account manipulation technique. | |
| Recommendation — Monitor delegated mailboxes for abnormal collection and message access patterns. Alert on mailbox permission changes and investigate unexpected delegation grants. | ||
Practitioner Guidance
Governance implication: Treat delegated mailbox rights as privileged access, not as a casual collaboration setting. Owners, approvers, and reviewers should know who can act on behalf of whom, why the access exists, and when it must be removed.
What to watch for: Unexpected send-as activity, unusual inbox rule changes, access granted from stale projects, and delegation that persists after role changes are strong indicators that the feature is being overused or abused. For organisations that want a broader control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the right control family perspective for access control, audit, and configuration governance.
Practitioner takeaway: If a delegated mailbox can influence money, identity recovery, or external trust, it deserves the same review discipline you would apply to any other privileged pathway.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
