How should security teams review delegated mailbox access for BEC risk?

Treat delegated inboxes, shared mailboxes, forwarding permissions, and sender impersonation rights as access-review items, not just collaboration conveniences. Review who can send, forward, approve, and modify business mail paths. If those permissions are broad or stale, BEC can turn a trusted account into a fraud execution channel.

What security teams should review first in delegated mailbox access

Start with the business mail paths that can be used to move or alter messages, not just the mailbox owner list. That means delegated send-as, send-on-behalf, mailbox folder permissions, forwarding rules, and any ability to approve or redirect payment-related mail. The review goal is to separate legitimate collaboration from standing access that can be abused.

For BEC, the key question is whether the delegate can influence a message after it enters the mailbox or after it should have been seen by the real owner. If a user can send as an executive, auto-forward externally, or silently alter rules, the access is operationally equivalent to trusted mail authority and should be treated that way.

Security teams should also verify whether the mailbox is shared, inherited, or connected through multiple admin paths. Shared mailboxes often accumulate permissions from different owners over time, and that makes it easy to miss who still has effective control. The safest review is one that traces the actual rights in use, not the original ticket that created them.

How to judge whether delegated access is risky or acceptable

Use the pattern of privilege, not the label on the mailbox, to decide. Delegation that is narrowly scoped, time bounded, and easy to audit is materially different from broad mailbox control that persists after a role change. The risk rises when the delegate can read sensitive threads, alter sent mail, create forwarding paths, or act in a way recipients will trust as the mailbox owner.

Another practical test is whether the permission can be used to create payment fraud without first taking over the account. If the answer is yes, the delegated access itself is a BEC-enabling control gap, even if authentication is strong and the owner’s password is never exposed. That is why mailbox review should sit alongside access governance and approval-path review.

Security teams should also challenge any permission that is left in place “just in case”. BEC campaigns succeed when trust assumptions are stale, so old assistants, finance delegates, and temporary approvers should be revalidated as part of the same review cycle as the account owner. Where the mailbox supports high-value workflows, require a clear business justification for each non-owner right.

What a useful delegated mailbox review looks like in practice

A useful review starts by listing who can send, forward, read, and modify rules on each high-value mailbox, then matching that list to current job function. It should include send-as rights, send-on-behalf rights, delegated folder access, external forwarding, inbox rule creation, transport rule influence, and any mail-flow change that could hide or reroute a suspicious message.

Reviewers should also look for mail access that has drifted outside normal ownership. That includes assistants who no longer support the executive, team mailboxes that still have ex-employees attached, and service workflows that were granted broad mailbox control for convenience. The question is not only whether the access exists, but whether the business still needs that exact form of access.

In many organisations, the strongest control is to reduce the number of delegates who can act on behalf of a mailbox and to make every remaining exception visible. Access reviews and certification work best here when they focus on the highest-risk mail paths, not on a generic roster check. For the broader identity model behind these reviews, see IAM and IGA Basics and Privileged Access Management Guide.

Why mailbox delegation becomes a BEC control problem

delegated mailbox access matters because BEC is often a trust abuse problem, not a password problem. If an attacker can use an allowed delegate path, they may not need to defeat MFA or steal the owner’s credentials. They only need a permission set that lets them act inside the normal business communication channel.

The same logic applies to finance, payroll, legal, and executive mailboxes, where message authenticity is judged by sender identity and thread history. Broad delegation can let a malicious actor insert themselves into an existing conversation, alter instructions, or create a convincing internal endorsement of a fraudulent payment request. In that sense, mailbox delegation is part of the attack surface, not a separate convenience feature.

This is why mailbox permissions, identity governance, and message-authentication controls should be reviewed together. Email authentication helps outsiders less easily impersonate the domain, but delegated access can still let an insider, compromised account, or overprivileged delegate operate from inside the trusted boundary. Security teams should use Email Identity and BEC Guide as the companion view for the mail-authentication side of the problem.

Risk and Threat Considerations

Delegated mailbox access becomes dangerous when it can be used to send authoritative mail, suppress warnings, or redirect payment conversations without the owner noticing. BEC actors look for these permissions because they let fraud ride on legitimate trust, which is far less visible than a direct login attack.

Failure mechanism: Overbroad or stale delegation lets a trusted mailbox path be reused for impersonation, message tampering, or invoice redirection, even when the primary account remains protected.

Impact: The organisation can suffer fraudulent payments, lost correspondence integrity, and delayed detection because the malicious activity appears to come from an approved business relationship.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Delegated mailbox rights need periodic review and removal when no longer justified.
	AC-6 — Least Privilege	Mailbox delegation should be limited to the minimum rights needed to send or manage mail.
	IA-5 — Authenticator Management	Forwarding and send-as paths depend on credentials, tokens, and mail access material that must be controlled.
Recommendation — Review delegated mailbox access on a defined schedule and revoke stale permissions promptly. Limit mailbox delegates to the smallest set of actions required for the business task. Control and rotate mail access material so delegated paths cannot persist unchecked.
CIS Controls v8	CIS-5 — Account Management	Mailbox delegation is an account lifecycle and access-review problem with fraud exposure.
Recommendation — Inventory mailbox delegates and remove dormant or unnecessary access.
ISO/IEC 27001:2022	A.5.15 — Access control	Delegated mailbox permissions are access rights that need governance and review.
	A.5.16 — Identity management	Mailbox delegates must be tied to current identities and ownership.
	A.5.18 — Access rights	The question is fundamentally about reviewing and revoking mailbox rights that can enable fraud.
Recommendation — Define and enforce mailbox access rules for delegation and periodic review. Ensure delegate identities are current, owned, and traceable to business need. Recertify mailbox access rights and remove excess delegation immediately.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Delegate rights can let users perform mail actions they should not be able to invoke.
Recommendation — Restrict mailbox functions so delegates cannot invoke unauthorized send or rule actions.

Practitioner Guidance

What to prioritise: Put the highest-value mailboxes first, especially executives, finance leaders, legal, HR, and shared service accounts that can influence payments or approvals. These are the places where a single delegate right can create disproportionate fraud exposure.

What to verify: Confirm each delegate right is still tied to a current role, has an explicit business owner, and cannot be used to create or hide outbound forwarding paths. If a right cannot be justified in one sentence by the line manager or mailbox owner, treat it as a removal candidate.

Common mistake: Teams often review mailbox ownership but miss the effective control path created by send-as, inbox rules, and forwarding. That leaves a control gap where the account looks well managed while the mail flow remains easy to abuse.

Practitioner takeaway: For BEC, the important control question is not “who can open the mailbox?” but “who can change the conversation, redirect the message, or make the recipient trust the wrong sender?”