Shared Mailbox Permission Audit: Find Stale Full Access, Send As and Disabled Delegates

What a shared mailbox permission audit actually checks

Microsoft 365 shared mailboxes carry three separate permission types, and each one is assigned, removed and audited independently:

• Full Access — lets a delegate open and act inside the mailbox as if it were their own, including reading and sending mail when AutoMapping or a manually added folder makes it visible.
• Send As — lets a delegate send mail that appears to come directly from the shared mailbox address, with no "on behalf of" header.
• Send on Behalf — lets a delegate send mail that shows both their name and the mailbox address, so recipients can see who actually sent it.

An audit walks every configured mailbox and answers one question for each delegate on each permission type: is this entry still supposed to exist?

Why permission drift accumulates

No single event causes stale delegation. It builds up from several ordinary changes that each look harmless in isolation:

• A user changes role or team and their old access is never revisited.
• An account is disabled or deleted, but the mailbox permission referencing it is not cleaned up in the same step.
• A helpdesk grants direct access for an urgent request and it's never brought under the same management process as everything else.
• A group mapped as the source of truth for a mailbox is deleted, renamed, or accidentally converted to a non-security type, so nothing about it is enforceable anymore.
• Offboarding removes a user from Active Directory but the process never checks which shared mailboxes they had direct delegation to.

Each of these produces a specific, checkable audit finding rather than a vague "something might be wrong":

• Disabled account still holding access — the AD account behind a delegation has been disabled, but the Exchange permission was never removed.
• Orphaned or unresolvable trustee — the delegate on the mailbox no longer resolves to an Exchange recipient or an AD account at all.
• Missing or non-security mapped group — the group a mailbox is supposed to be governed by is missing, deleted, or no longer security-enabled.
• Unmanaged direct access — a delegate has Full Access, Send As or Send on Behalf outside the group mapped as that mailbox's source of truth.

Desired state vs. actual state

Every one of those findings comes from comparing two lists: who the group saysshould have access (desired state), and who Exchange says currently has access (actual state). A mismatch in either direction is worth flagging — someone missing an expected permission is as much a finding as someone holding a permission they shouldn't. Audit surfaces both sides of that mismatch; it doesn't assume the drift only ever runs one way.

Why a one-time CSV export isn't enough

Exporting current permissions with Get-MailboxPermission andGet-RecipientPermission gives you a snapshot of actual state at the moment you ran the script. It does not tell you which of those grants are still intentional, and it stops being accurate the moment someone joins or leaves a group afterward. A permission audit that only happens once a year, during a compliance review, finds the drift that accumulated over the entire year in one uncomfortable sitting — instead of catching each piece of it close to when it happened.

Audit vs. reconciliation

These are two different operations, and conflating them leads to either false confidence or unsafe automation:

Audit is read-only. It tells the administrator where current state looks wrong or suspicious, and leaves the decision about what to do with each finding to a person.

Reconciliation is the process that actually changes permissions — adding missing managed grants and removing stale managed ones — but only for entries inside its own configured management scope. Not every audit finding should be auto-remediated by reconciliation; some findings (a deleted mapped group, an unmanaged direct grant someone added deliberately) need a human decision first.

When PowerShell auditing is enough

A scheduled script built around Get-MailboxPermission,Get-RecipientPermission and a lookup against Get-ADUser for enabled/disabled state can answer most of these questions for a handful of mailboxes. It becomes harder to keep current as the mailbox count grows, as more admins make ad hoc direct grants outside the script's knowledge, and as the script itself needs its own monitoring to notice when a scheduled run silently stops working.

How Tenvero's Delegation Audit fits

Tenvero's Delegation Audit runs the same four checks above — disabled accounts, orphaned trustees, missing or non-security mapped groups, and unmanaged direct access — across every mailbox mapping it already manages, on demand or on a schedule, and exports results to CSV. It is read-only: running an audit never changes AD group membership or Exchange permissions on its own. Reconciliation, which does change managed permissions, is a separate step the administrator controls.