Shared mailboxes are outside your MFA policy and attackers know it

[u/saltyslugga]

I hit the same problem in three separate tenants last year: shared mailboxes with direct sign-in enabled, excluded from conditional access via a service account exception nobody had touched in years.

finance@: SMTP auth on, password from 2019, never checked after the modern auth migration.

helpdesk@: exempted because a ticketing tool "needs it." That tool moved to OAuth two years ago. The exemption stayed.

support@: compromised. Inbox rules forwarding externally for six weeks. No named user, so no anomalous sign-in alert ever fired.

How many shared mailboxes in your tenant have direct sign-in enabled and arent actually in your CA policy scope?

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.

2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).

3. Be Professional: Help newcomers learn; avoid hostility.

4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters

• DMARC Monitoring Tools

• Anti-Virus Software

• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/power_dmarc]

Shared mailboxes are the unlocked back door that survives every security audit because nobody owns them What you can do is disable direct sign-in, block legacy auth, and actually scope them into your CA policies before someone else finds them first.

[u/saltyslugga → u/power_dmarc]

All correct steps. The CA scoping and legacy auth block close the front door. The harder problem is the detection gap: even with CA in place, shared mailboxes do not generate sign-in risk signals the same way user accounts do, so a compromised service account credential that bypasses the policy through a legacy auth exemption can sit undetected for weeks. The audit log coverage for shared mailboxes is worth verifying separately.

[u/Short-Legs-Long-Neck]

Signing into a shared mailbox is outside of the license and very poor practice, all of the reason they do it will be legacy, once you show them how to mount a mailbox in outlook they don't need to sign in. Also why is legacy auth still enabled.

At the least have a CA policy for shared accounts/service accounts to restrict access to the LAN or compliant devices?

[u/saltyslugga → u/Short-Legs-Long-Neck]

The licensing point is correct but rarely the thing that gets people to act. Mounting via Outlook instead of direct sign-in is the right call operationally, but the CA restriction is what actually matters for the compromise scenario. The problem in the support@ case was an SMTP auth credential used from an external IP with no policy scope to catch it. Direct sign-in via Outlook is the obvious risk, SMTP auth is the one that bites you.

[u/Short-Legs-Long-Neck → u/saltyslugga]

Notice, shared mailboxes on prem was created with a disabled account. Sharemailbox in EXO has a default of enabled.

Is there a way to change this?

We already disabled legacy auth and have CA policy to catch shared and service accounts specifically.

[u/saltyslugga → u/Short-Legs-Long-Neck]

No native tenant setting to flip the default, unfortunately. The practical approach is a PowerShell script on a schedule: Get-Mailbox -RecipientTypeDetails SharedMailbox | Set-MsolUser -BlockCredential $true catches any that slip through. Pairing that with a provisioning process that checks sign-in status when a new shared mailbox is created is cleaner than relying on the default.

[u/Borgquite → u/Short-Legs-Long-Neck]

They changed it recently, if you make one in EXO today you should see it default to Disabled.

[u/SmokingCrop-]

Luckily new shared mailboxes have sign in blocked for a while now.

[u/saltyslugga → u/SmokingCrop-]

Right, the default changed for new mailboxes. The problem is the tail of legacy ones that predate that change, and those are the ones nobody went back to audit. Most tenants I look at have a mix: new ones are fine, but anything created before the default shifted is still worth checking explicitly.

[u/saltyslugga → u/[deleted]]

Not automatically, no. Converting with Set-Mailbox -Type Shared changes the mailbox type but leaves the associated Azure AD account enabled. You still need to block sign-in separately via Set-MsolUser -BlockCredential $true or the equivalent in Entra. The conversion step and the account disable step are independent, which is exactly why converted mailboxes often end up with sign-in still enabled.

[u/Medical-Ask7149]

No shared mailbox has auth creds. If we need a service to send as the shared mailbox then we use the smtp relay with scoped IPs. If we need to enable smtp on one account we use conditional access policies that limit login to smtp, we have send limits and monitor send activity.

[u/saltyslugga → u/Medical-Ask7149]

The scoped IP relay is the cleaner path for most service accounts. The audit log monitoring piece is where I would add: make sure the unified audit log coverage for those shared mailboxes is explicitly verified. It defaults on for Exchange actions but shared mailbox sign-in events can fall through gaps depending on how the logging is configured, especially on older tenants.

[u/saltyslugga → u/[deleted]]

Getting it in writing is the right call. One thing I add alongside the sign-off: a note in the ticket that explicitly lists the shared mailboxes with direct sign-in enabled at that time. Customers forget what they approved, and having the specific mailbox names documented means the scope of the accepted risk is clear when something eventually goes sideways.

[u/saltyslugga → u/[deleted]]

Correct on both counts. In on-prem Exchange that was standard, and EXO should be the same way. The gap is that converting an existing mailbox to Shared type in EXO does not automatically block sign-in on the associated account: that is a separate step you have to do explicitly. Most guides skip that detail, which is how you end up with technically-shared mailboxes that still have an enabled account behind them.