Old permissions can survive the migration and give people more access than they need in the cloud. That creates operational confusion, audit problems, and a higher risk of inappropriate access to sensitive mailboxes. A fresh review should confirm who can access each mailbox, why they need it, and whether those rights still match current business roles.
What survives when mailbox delegation is lifted into Office 365?
Mailbox delegation often moves as part of the migration process, but the access model does not automatically reset just because the platform changes. If the old permissions are copied forward, inherited full access, send-on-behalf rights, and shared mailbox exceptions can stay active until someone explicitly reviews and trims them. That is why the migration is also an access governance event.
A clean migration should answer three questions at once: who has access, what type of access they have, and whether that access is still justified in the new tenant. A mailbox that was sensible in Exchange on-premises can become overexposed in Office 365 if role changes, departures, or temporary arrangements were never cleaned up before cutover.
In practice, the cloud move often exposes hidden dependency chains. Access reviews and certification are the right control pattern because they force owners to confirm current business need rather than trusting legacy delegation lists. The same principle applies to mailbox delegation, where stale rights are easy to overlook but easy to overgrant.
Why VIP mailboxes are the highest-risk place to carry old access forward
VIP access is not just a convenience setting. It is a privilege decision with higher sensitivity because the mailbox can contain strategy, finance, HR, legal, board, or incident-response material. When migration teams preserve access without revalidation, they can unintentionally extend visibility to assistants, backups, shared service accounts, or former support staff who no longer need the same reach.
The risk is usually not dramatic misuse on day one. It is silent accumulation. Delegation that was time-bound, informal, or granted for an old project can remain effective in the cloud long after the business reason has ended. That creates a wider exposure surface for confidential mail, delegated sends, and mailbox content search.
Office 365 also makes access more operationally fluid, which is useful only if rights are intentionally managed. Privileged access management matters here because VIP mailbox control should follow least privilege, explicit ownership, and, where appropriate, just-in-time access rather than standing delegation that nobody revisits.
For teams managing migration at scale, IAM and IGA basics are the useful lens: mailbox delegation is an entitlement, not a one-time admin setting, and entitlements need lifecycle control after cutover.
What a fresh review should prove before the mailbox is trusted
A post-migration review should not stop at technical parity. It should prove that each delegated right maps to a current business role, that the mailbox owner understands the access path, and that the access type matches the task. Full access, send as, send on behalf of, and delegate calendar rights are different privileges and should not be treated as interchangeable.
Ownership is the practical control point. If no named business owner can confirm why a delegate still needs access, the right is already suspect. The review should also look for shared or emergency arrangements that were never formalized, because those are the rights most likely to survive migrations unnoticed.
Regulatory and audit perspectives on access governance are relevant here because mailbox delegation is only defensible when the organisation can explain who approved it, why it exists, and when it was last revalidated. A migration without that evidence produces audit friction even when no incident occurs.
Lifecycle management also applies to access that was granted for a temporary support model, a project handover, or a short-term executive backup. If the business event ended, the entitlement should have ended too.
Risk and Threat Considerations
When legacy mailbox delegation is moved into Office 365 without review, the main risk is privilege persistence: access that was temporary, informal, or role-specific can survive into a new environment with a broader blast radius. That turns a migration task into a confidentiality and accountability problem.
Failure mechanism: Existing delegation and VIP exceptions are copied or reconnected during cutover, but no one revalidates whether each right still has a live business owner, so stale access remains active and may be used by people who no longer need it.
Impact: Sensitive mailboxes can become overexposed, audit trails become harder to defend, and organisations may face inappropriate access, accidental disclosure, or delayed revocation when roles change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Mailbox delegation is an access governance issue in cloud services. |
| Recommendation — Review and remove inherited mailbox rights before trusting the migrated cloud state. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Delegated mailbox access depends on current account and entitlement status. |
| AC-6 — Least Privilege | VIP mailbox access should be limited to the minimum rights needed. | |
| Recommendation — Recertify delegated mailbox accounts and revoke stale access promptly. Restrict mailbox delegation to the smallest effective privilege set. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The subject is about governing who may access sensitive mailboxes. |
| A.8.2 — Privileged access rights | VIP mailbox delegation behaves like privileged access and needs review. | |
| Recommendation — Revalidate mailbox access approvals against current business need. Review and approve elevated mailbox delegation before and after migration. | ||
Practitioner Guidance
What to verify: Check mailbox owner approval, the exact privilege type, and whether the delegate still matches the current operating model. A right that cannot be tied to a current role or documented exception should be treated as stale until proven otherwise.
Decision rule: If a mailbox contains sensitive executive, finance, legal, or HR content, do not accept inherited delegation as “good enough.” Require explicit recertification before you rely on the migrated state.
Common mistake: Treating migration success as access correctness. A mailbox can open correctly in Office 365 and still be wrong from a privilege perspective if legacy delegations were copied forward unchanged.
Practitioner takeaway: The safest migration is not the one that preserves every old right, it is the one that preserves only the rights the business can still justify.
Related resources from NHI Mgmt Group
- What happens when organisations try to manage Office 365 identities and devices without a central identity and access platform?
- When should organizations review access controls?
- What happens when delegation is enabled without compensating access controls?
- What happens when teams remove public access from Microsoft 365 files without checking whether permissions are inherited?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
