A shared mailbox access review fails when the auditor asks who can still send as finance@ and the only artifact is last quarter's user spreadsheet. Shared mailboxes sit outside the employee access review. They have no interactive login, they often carry no license, and Outlook automaps them for anyone granted Full Access. The compliance lead feels the gap when a former contractor's name is still on Send As, and the CTO feels it when the sample request arrives with a three-day turnaround.
Rutagon builds the extract, the owner map, and the revoke path. The GRC platform you already run stays the system of record. We file each decision there. We do not replace that platform, and we do not run your mail tenant as an administrator of record.
Why user reviews miss the mailbox
Entra access reviews walk users, groups, and application assignments. Exchange mailbox permissions live in a different directory of ACEs. Full Access, Send As, and Send on Behalf are not group memberships. A manager can approve every Microsoft 365 group in the Microsoft 365 group access review and still leave five people with Send As on the payroll mailbox.
Automapping makes the miss worse. Full Access causes Outlook to open the shared mailbox on next launch. People stop noticing they have it. The permission remains after a role change because the joiner-mover-leaver job revoked the user account's groups and left the mailbox ACE in place. Employee offboarding automation has to include this ACE or the offboard looks finished while send rights remain.
Inherited ACEs add noise. Get-MailboxPermission returns NT AUTHORITY\SELF, inherited rights from the mailbox plan, and sometimes Anonymous or Default with limited rights. A campaign that asks a human to approve those rows trains the reviewer to click through. We drop them before the review opens.
What we extract
The population is every shared mailbox, room mailbox, and equipment mailbox that still routes mail for an in-scope process. For each one we pull three grants.
Full Access comes from mailbox permissions where AccessRights contains FullAccess, IsInherited is false, and the trustee is not NT AUTHORITY\SELF. Send As comes from recipient permissions with the same self-trustee filter. Send on Behalf comes from GrantSendOnBehalfTo on the mailbox object. The three grants are separate decisions. Full Access reads the archive. Send As lets the trustee impersonate the mailbox to customers and to banks. Reviewers who see a single "has access" flag approve the wrong thing.
Get-MailboxPermission -Identity $mailbox -ResultSize Unlimited |
Where-Object {
$_.IsInherited -eq $false -and
$_.User -notlike "NT AUTHORITY\\SELF" -and
$_.AccessRights -contains "FullAccess"
}
Each row carries the mailbox primary SMTP address, the permission type, the trustee object id, the trustee's account status, and the designated owner. We resolve the trustee to an Entra object so a disabled user is visible without a second lookup during the review meeting. Mailboxes with no matching owner, or an owner whose account is disabled, are exceptions. They do not enter the approve pile.
Microsoft documents these permission cmdlets in the Exchange mailbox permissions reference. We use that model. We do not invent a parallel permission that Exchange will not enforce.
What a shared mailbox access review records
The campaign unit is one row: one mailbox, one permission type, one trustee. The reviewer is the living owner, not a central list of every manager in the company. "Living" means the owner account is enabled and the owner still sits in the department that uses the mailbox. When that stops being true, the row is an owner-repair item. Approving access under a departed owner is how the next sample fails.
The owner chooses approve or revoke. Approve means the trustee still needs that exact right. Revoke means we call Remove-MailboxPermission, Remove-RecipientPermission, or clear the Send on Behalf trustee. We re-read the ACE after the call. A ticket that says "please remove" is not a revoke. The evidence is the second read showing the trustee gone, plus the identity of the owner who decided, plus the timestamp.
We write that triple into the GRC you already run. The export includes the mailbox, the right, the trustee, the decision, and the proof read. Auditors sampling CC6 logical access can see who attested and what the directory showed afterward. Rutagon does not claim a SOC 2 attestation of its own. The evidence belongs in your system.
Shared mailboxes that exist for a departed process, with no enabled owner and no traffic the owner will defend, are candidates for disablement rather than a rubber-stamp review. We surface them as a separate queue so they do not dilute the access decisions.
Production lessons from the cutover
The first extract is always larger than the team expects. Calendar delegates, old migration SIDs that no longer resolve, and a service account used by a scanner all show up. Unresolved SIDs are revokes after a short confirmation window. A scanner service account stays only when a named owner accepts Send As or Full Access and the account is on the non-human inventory.
Timing matters for Full Access removal. Outlook clients cache the automapped mailbox. Users lose it on the next profile refresh. We tell the owner that before the revoke job runs, so the help channel is not surprised. We do not leave the ACE in place to avoid a ticket.
Send As is the right auditors ask about when a mailbox talks to customers. We do not bury it under Full Access. If your policy says Send As requires a tighter reviewer than Full Access, the campaign has two routes and one decision log format.
Room and equipment mailboxes often have Full Access left over from a facilities integrator. They belong in the same pipeline with a filter the owner understands. Dropping them "because they are not user mailboxes" is how a booking account keeps impersonation rights.
We avoid a standing global admin session for the extract. The job uses an app registration with Exchange application permissions scoped to the review task, and the secret or certificate for that app is itself on the credential inventory. A shared mailbox cleanup that creates a new immortal credential has moved the problem.
How this sits with the rest of access governance
Mailbox ACEs are one feed into the same decision log as groups, PIM eligibility, and application roles. The security automation work is the join: one owner map, one revoke style, one place the GRC reads. Teams that review mailboxes in a spreadsheet and groups in another tool will not be able to answer "show every right this contractor still holds."
The owner map is the asset. Once every shared mailbox has an enabled owner, the next campaign is a diff: new ACEs since last attestation, trustees who became disabled, owners who became disabled. The full population still exists for the annual sample. The human time goes to the delta and to anything that never had an owner.
If your GRC can ingest a CSV or an API payload, we match that shape. If it cannot represent a non-user principal, we still keep the decision log in the GRC as an attached evidence item the auditor already knows how to request. The engineering is the extract and the revoke. The workflow product you bought remains the front door for the reviewer when it can host the campaign, and the evidence folder when it cannot.
Frequently Asked Questions
What does a shared mailbox access review cover that a user review does not?
It covers Full Access, Send As, and Send on Behalf on shared, room, and equipment mailboxes. Those ACEs do not appear as Entra group memberships, so a user campaign never asks about them. The reviewer is the mailbox owner, and the decision is per right, not a single access flag.
How do you handle a shared mailbox whose owner account is disabled?
That mailbox is an exception, not an approval. We do not let another reviewer attest rights under a departed owner. The row stays open until a living owner is assigned or the mailbox is disabled and the ACEs are removed.
Do you revoke Full Access and Send As the same way?
They are different Exchange operations and different risk. Full Access is removed with the mailbox permission cmdlet. Send As is removed with the recipient permission cmdlet. We re-read each ACE and store that proof with the owner's decision in the GRC you already run.
Should automapped mailboxes be treated as intentional access?
Automapping is a client behavior that follows Full Access. It is not a separate grant and it is not evidence of a recent business need. The review decides the Full Access ACE. After a revoke, Outlook drops the mailbox on the next profile refresh.
Where does the evidence go for the auditor?
Each decision, trustee, permission type, and post-revoke read is filed in the GRC you already run. We do not stand up a second system of record and we do not claim the attestation is ours. Your auditor samples your evidence store.
See what an Access & Credential Governance Diagnostic finds in your environment. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.