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.
Who should own mailbox-state revocation in an identity programme?
Mailbox-state revocation belongs in the identity operating model, not in an ad hoc mail admin queue. The programme owner should define the control, the offboarding trigger, and the required evidence, while collaboration or messaging administrators carry out the mailbox changes. That division matters because mailbox forwarding, routing, and delegated access can preserve access after employment or role changes.
Why mailbox-state revocation is an identity control, not a mail-only task
Mailbox-state revocation sits at the boundary of identity governance, access management, and collaboration operations. If a mailbox can still forward mail, accept delegates, or retain access paths after an identity event, the organisation has not really revoked access, it has only changed one visible part of it. That is why the control belongs with the identity programme owner, with execution handoff to the system administrators who can change the platform state.
The practical question is not who clicks the buttons. It is who owns the policy that says which mailbox conditions must be removed, when the check must happen, and what counts as complete revocation. In well-run identity programmes, that ownership usually sits alongside offboarding, access review, and privileged access governance so the same control model covers accounts, group membership, delegates, and forwarding rules.
What mailbox-state revocation must cover to be complete
Mailbox-state revocation should cover every mechanism that can preserve message access or redirect data flow after access should have ended. That includes mailbox forwarding, hidden delivery rules, delegate permissions, shared mailbox access, auto-forward configuration, and any connected service that can still retrieve or relay content. NHI Lifecycle Management Guide is useful here because the same lifecycle logic applies: revoke the active access path, then verify that no residual route remains.
The control also needs a clear exception path. Shared mailboxes, executive assistants, break-glass business continuity arrangements, and regulated retention workflows can all justify continued access, but only when the exception is documented, time-bounded, and reviewed. Without that discipline, mailbox exceptions become informal back doors that outlive the business need that created them.
Programme ownership should therefore include three things: the policy requirement, the system evidence, and the business approval for exceptions. Messaging teams can administer Exchange, Google Workspace, or a similar platform, but they should not be left to decide whether forwarding is permitted after offboarding or whether delegate access is still acceptable. Those are identity decisions first and platform decisions second.
How to split responsibility between IAM, IGA, and collaboration teams
IAM and IGA teams should own the control requirement because mailbox-state revocation is part of the broader joiner-mover-leaver model. They define the standard, link it to the identity event, and ensure the mailbox checks are included in the offboarding workflow. Messaging or collaboration administrators own the operational execution, because they understand the mail platform settings, routing rules, and delegation model.
That split works best when the identity programme defines the required end state in plain language. For example, the mailbox must be inaccessible to the departed user, must not forward externally, must not retain delegate access unless approved, and must be covered by an auditable exception if business continuity requires temporary retention. Identity Security Programme Guide is a good reference point for this operating model because it frames ownership, governance, and control boundaries at programme level.
Where organisations struggle is in leaving mailbox controls outside the identity catalogue. That usually creates a gap between HR-triggered offboarding and the technical cleanup of the mailbox. A better pattern is to treat mailbox-state revocation as a standard offboarding control, assign a named control owner in IAM or IGA, and then measure completion through ticket closure or workflow evidence rather than informal confirmation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Mailbox access paths must be revoked and controlled over their lifecycle. |
| AC-6 — Least Privilege | Delegate and forwarding access should be limited to approved business need. | |
| Recommendation — Remove or rotate mailbox-related access paths when offboarding completes. Restrict mailbox delegates and forwarding to the minimum approved access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Mailbox-state revocation is an access control requirement within the ISMS. |
| Recommendation — Define mailbox revocation as a controlled access-management requirement. | ||
| CIS Controls v8 | CIS-5 — Account Management | Mailbox-state revocation is part of account lifecycle and offboarding control. |
| Recommendation — Include mailbox revocation checks in account offboarding processes. | ||
Practitioner Guidance
What to verify: Confirm that the offboarding standard explicitly names mailbox forwarding, delegates, and routing rules as required revocation checks. If those items are only handled informally by the mail team, the control is too weak to trust.
Decision rule: If the mailbox can still receive or forward messages on behalf of the former user, treat the revocation as incomplete, even if the account password has been disabled. If an exception is required, make it time-limited and owner-approved.
What good looks like: The identity workflow triggers the mailbox check automatically, collaboration admins execute the technical change, and the programme retains evidence that the mailbox no longer exposes a usable access path.
Practitioner takeaway: Ownership belongs with the identity programme because mailbox-state revocation is an access control outcome, while the collaboration team is only the execution layer.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org