Securing shared mailboxes in Exchange Online starts with blocked sign-in

Shared mailboxes are part of almost every Exchange Online environment. Teams use them for shared inquiries, support cases or group mail, and I find them in nearly every tenant I work in. What often gets overlooked is the technical side: each shared mailbox comes with a complete Entra ID user account, including a password that almost never changes and hardly ever has MFA. If sign-in isn't explicitly blocked for these accounts, attackers have a way in. Securing shared mailboxes is not optional, in my view.

Every shared mailbox has a user account behind it

Most Exchange admins know that a shared mailbox doesn't need a license as long as it stays under 50 GB and doesn't use features like in-place archive or litigation hold (source). Fewer people keep in mind that each shared mailbox is tied to a user account in Entra ID, and that gets lost easily after tenant migrations or bulk changes. Sign-in is disabled by default when you create a shared mailbox, but I've seen it switched back on by accident many times, sometimes by scripts and sometimes by admin actions nobody fully understood. A mailbox account with sign-in enabled almost never has MFA or other strong controls. Conditional Access doesn't help either, because it can't protect accounts that nobody signs into. That's why blocking sign-in is the first thing to get right. And never use a shared mailbox as a personal login.

Blocking sign-in is the core of a secure shared mailbox

The most important step is to disable sign-in for the Entra ID user object of the shared mailbox (technically that's accountEnabled = false). The Exchange Online GUI doesn't show this status clearly, so I check it periodically with PowerShell or Graph. This short PowerShell snippet lists all shared mailboxes that still allow sign-in:

Get-Mailbox -RecipientTypeDetails SharedMailbox | Where-Object {
    (Get-MsolUser -UserPrincipalName $_.UserPrincipalName).BlockCredential -eq $false
} | Select DisplayName,UserPrincipalName

The output shows every shared mailbox whose account someone could still log into. If the list isn't empty, you have some cleanup to do. With sign-in disabled, these accounts can't quietly turn into an attack path.

Pro tip from the trenches: After migrations or bulk changes, always check the sign-in status of your shared mailboxes again. A script that misbehaves or an edge case nobody thought of usually leaves a few of them enabled.

If you want to know how Conditional Access policies behave in these scenarios (or why they don't apply), have a look at my earlier post Getting started with Conditional Access in Entra ID.

Permissions belong in groups and need regular reviews

Permissions are where a shared mailbox setup becomes secure or not. The standard roles are Full Access, Send As and Send on Behalf. You can assign them to individual users or, which scales much better, to mail-enabled security groups (source). For larger teams I always use groups, because access is managed in one place and changes are easier to trace.

One practical point: with Full Access, Outlook automapping usually takes over and the mailbox appears in the user's Outlook on its own. That's convenient, but it gets confusing when teams or memberships change. In large or fast-changing teams, I'd control automapping deliberately or have users add the mailbox manually.

You can't set mailbox permissions once and forget about them. Anyone with Full Access or Send As can act as the team, and that matters for compliance and auditing. Check at least once a year, ideally more often, who holds these permissions and for what reason.

Sent items and licensing need a second look

One small setting that makes a real difference is where sent items end up. By default, a message a user sends from a shared mailbox only shows up in that user's own Sent Items folder, not in the shared mailbox. The MessageCopyForSentAsEnabled option keeps a copy in the shared mailbox's Sent Items as well, so everyone can see what went out. For mailboxes a team works in together, I nearly always turn it on:

Set-Mailbox "[email protected]" -MessageCopyForSentAsEnabled $true

Keep licensing in mind too. Once a shared mailbox grows beyond 50 GB or needs in-place archive, it has to be licensed (source). Many organizations only find out when they run into the storage limit.

Shared mailboxes must not become invisible backdoors

Shared mailboxes work very well for collaboration, as long as they don't turn into hidden backdoors protected only by a password. My rules are simple. I block sign-in for every shared mailbox account, manage access through groups, review permissions regularly and make sure sent items are visible to the whole team. Again and again I come across shared mailboxes that someone set up and then forgot, and over time they become a security risk. If you keep these basics under control, you cut the risk considerably and protect both your data and your identities.

The following diagram shows how access works and why blocking sign-in matters so much:

flowchart TD
    User["User"] --> Outlook["Outlook client"]
    Outlook --> SharedMailbox["Shared Mailbox"]
    SharedMailbox --> EntraID["Entra ID account (sign-in blocked)"]
    Admin["Admin"] --> Permissions["Assign permissions"]
    Permissions --> SharedMailbox

Figure: Users reach a shared mailbox through permissions, never by logging in directly.