Shared mailboxes like info@, accounts@ and support@ handle some of the most sensitive mail a business receives: invoices, client enquiries, payment confirmations. They are also some of the least protected accounts in a typical tenant. Good shared mailbox security comes down to one principle: nobody should ever sign in as the mailbox itself. People get access through their own accounts, and the mailbox account stays locked.
The same thinking applies to service accounts, the scanner, line-of-business app or script that “needs a login”. This guide covers how to secure both without breaking the workflows that depend on them.
Why shared mailboxes become a weak spot
Every shared mailbox in Microsoft 365 has a corresponding user account in Microsoft Entra ID. Microsoft gives that account a system-generated password that nobody knows, and says plainly that the account is not intended for direct sign-in and should always have sign-in blocked.
The problems start when someone works around that. In the tenants I review, the most common patterns are:
An admin reset the shared mailbox password so a team could “just log in to it” on a shared PC or phone.
The account is excluded from MFA because several people share the login.
Sign-in is enabled because the mailbox was converted from a former employee’s account.
A scanner or old app uses the mailbox credentials to send mail over SMTP.
Each one turns a mailbox nobody can sign in to into an account with a known password, often no MFA, and access to finance or client mail. That is exactly what attackers look for.
Step 1: block sign-in on every shared mailbox
New shared mailboxes created in the Microsoft 365 admin center have sign-in blocked by default. Older ones, and mailboxes converted from user accounts, often do not.
List your shared mailboxes in Exchange Online PowerShell: Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | Select-Object DisplayName,UserPrincipalName
For each one, check the account in the Microsoft 365 admin center under Users > Active users. If Block sign-in is not set, set it.
If anyone was signing in directly, give them proper access first (see step 2) so their work is not interrupted.
Reset the password on any shared mailbox that had a known password, then block sign-in. That removes any copy of the old password still sitting in a browser or note.
For defence in depth, create a Conditional Access policy that blocks access for a group containing all shared mailbox accounts. That catches any mailbox where someone re-enables sign-in by mistake. Conditional Access needs Entra ID P1, which is included in Business Premium.
Step 2: give people access the right way
Users reach a shared mailbox through their own licensed account, so their MFA, Conditional Access and device rules all apply. There are three permissions to choose from:
Permission
What it allows
Typical use
Full Access
Open the mailbox and read, move and delete items
Everyone who works the mailbox
Send As
Send mail that appears to come directly from the shared address
Support and accounts teams replying as the business
Send on Behalf
Send mail showing “on behalf of” the shared address
When recipients should see which person sent it
Grant these in the Exchange admin center under Recipients > Mailboxes, or in the Microsoft 365 admin center under Teams & groups > Shared mailboxes. Use the minimum each person needs, and review membership every quarter. Leavers are often removed from their own mailbox but left on accounts@ for months.
Access through Outlook on the web, Outlook desktop and Outlook mobile all work with this model. Nobody needs the shared mailbox password.
Step 3: watch what happens in shared mailboxes
Because several people use a shared mailbox, odd activity is easy to miss. Mailbox auditing is on by default and records actions by delegates, including rule changes, deletions and sends. To make use of it:
When searching the Purview audit log for shared mailbox activity, put the mailbox’s SMTP address in the Keywords field, not the Users field. Microsoft documents this quirk, and it trips people up during investigations.
Check shared mailboxes for inbox rules and forwarding exactly as you would for a compromised user: Get-InboxRule -Mailbox accounts@yourdomain.com.
Block automatic external forwarding with the outbound spam policy in the Microsoft Defender portal, so a rule cannot silently copy finance mail outside the company.
Securing service accounts and app access
Service accounts are the shared mailbox problem’s close cousin. A user account created for a scanner, backup tool or integration usually has a password that never changes, no MFA and broad permissions. Here is how to replace them.
Scanners and devices that send email
Microsoft supports several ways for printers and line-of-business apps to send mail. Pick the one that avoids a password-based login where you can:
SMTP relay through a connector: mail is accepted based on your public IP or certificate, with no mailbox credentials on the device.
Direct send: for devices that only send to internal recipients.
SMTP client submission (SMTP AUTH): requires a mailbox and password. Use it only if nothing else works, keep that account in a tightly scoped exception, and track it.
Apps and scripts
For integrations that read or send mail, use an app registration in Entra ID with application permissions instead of a user account. Then scope it: RBAC for Applications in Exchange Online lets you limit an app to specific mailboxes rather than the whole tenant. Use a certificate rather than a client secret, and for Azure-hosted code, a managed identity removes the credential entirely.
A shared mailbox and service account checklist
Every shared mailbox account has sign-in blocked.
A Conditional Access policy blocks sign-in for a group of all shared mailbox accounts.
Users access shared mailboxes with their own accounts and the minimum permission.
Shared mailbox membership is reviewed quarterly.
No shared mailbox has inbox rules or forwarding nobody can explain.
Automatic external forwarding is blocked.
Scanners use SMTP relay or direct send rather than mailbox passwords where possible.
Integrations use scoped app registrations or managed identities, not user accounts.
Microsoft’s guidance on creating shared mailboxes and blocking sign-in is in About shared mailboxes.
A shared mailbox does not need its own license for normal use. The people accessing it need a licensed Exchange Online mailbox. Some features, such as larger storage, an archive or litigation hold on the shared mailbox, do require licensing, so check before relying on them.
Can I enable MFA on a shared mailbox?
You should not need to. A shared mailbox should never be signed in to directly, so block sign-in instead. Users reach the mailbox through their own accounts, where MFA already applies.
How do I stop a scanner from needing a mailbox password?
Use SMTP relay through an Exchange Online connector based on your public IP address or a certificate, or direct send if the scanner only emails internal recipients. Both avoid storing mailbox credentials on the device.
Not sure which of your shared mailboxes can still be signed in to? Book a free Microsoft 365 security assessment and we will find them, along with any service accounts that need attention.
Shared mailboxes like info@, accounts@ and support@ handle some of the most sensitive mail a business receives: invoices, client enquiries, payment confirmations. They are also some of the least protected accounts in a typical tenant. Good shared mailbox security comes down to one principle: nobody should ever sign in as the mailbox itself. People get access through their own accounts, and the mailbox account stays locked.
The same thinking applies to service accounts, the scanner, line-of-business app or script that “needs a login”. This guide covers how to secure both without breaking the workflows that depend on them.
Why shared mailboxes become a weak spot
Every shared mailbox in Microsoft 365 has a corresponding user account in Microsoft Entra ID. Microsoft gives that account a system-generated password that nobody knows, and says plainly that the account is not intended for direct sign-in and should always have sign-in blocked.
The problems start when someone works around that. In the tenants I review, the most common patterns are:
Each one turns a mailbox nobody can sign in to into an account with a known password, often no MFA, and access to finance or client mail. That is exactly what attackers look for.
Step 1: block sign-in on every shared mailbox
New shared mailboxes created in the Microsoft 365 admin center have sign-in blocked by default. Older ones, and mailboxes converted from user accounts, often do not.
Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | Select-Object DisplayName,UserPrincipalNameUsers > Active users. If Block sign-in is not set, set it.For defence in depth, create a Conditional Access policy that blocks access for a group containing all shared mailbox accounts. That catches any mailbox where someone re-enables sign-in by mistake. Conditional Access needs Entra ID P1, which is included in Business Premium.
Step 2: give people access the right way
Users reach a shared mailbox through their own licensed account, so their MFA, Conditional Access and device rules all apply. There are three permissions to choose from:
Grant these in the Exchange admin center under
Recipients > Mailboxes, or in the Microsoft 365 admin center underTeams & groups > Shared mailboxes. Use the minimum each person needs, and review membership every quarter. Leavers are often removed from their own mailbox but left on accounts@ for months.Access through Outlook on the web, Outlook desktop and Outlook mobile all work with this model. Nobody needs the shared mailbox password.
Step 3: watch what happens in shared mailboxes
Because several people use a shared mailbox, odd activity is easy to miss. Mailbox auditing is on by default and records actions by delegates, including rule changes, deletions and sends. To make use of it:
Get-InboxRule -Mailbox accounts@yourdomain.com.Securing service accounts and app access
Service accounts are the shared mailbox problem’s close cousin. A user account created for a scanner, backup tool or integration usually has a password that never changes, no MFA and broad permissions. Here is how to replace them.
Scanners and devices that send email
Microsoft supports several ways for printers and line-of-business apps to send mail. Pick the one that avoids a password-based login where you can:
Apps and scripts
For integrations that read or send mail, use an app registration in Entra ID with application permissions instead of a user account. Then scope it: RBAC for Applications in Exchange Online lets you limit an app to specific mailboxes rather than the whole tenant. Use a certificate rather than a client secret, and for Azure-hosted code, a managed identity removes the credential entirely.
A shared mailbox and service account checklist
Microsoft’s guidance on creating shared mailboxes and blocking sign-in is in About shared mailboxes.
Shared mailbox and service account reviews are part of our Microsoft 365 security assessment. If you would rather someone else kept on top of it, our Microsoft 365 managed service handles access reviews, and our Microsoft 365 services cover mail flow redesign for scanners and apps.
Frequently asked questions
Does a shared mailbox need a license?
A shared mailbox does not need its own license for normal use. The people accessing it need a licensed Exchange Online mailbox. Some features, such as larger storage, an archive or litigation hold on the shared mailbox, do require licensing, so check before relying on them.
Can I enable MFA on a shared mailbox?
You should not need to. A shared mailbox should never be signed in to directly, so block sign-in instead. Users reach the mailbox through their own accounts, where MFA already applies.
How do I stop a scanner from needing a mailbox password?
Use SMTP relay through an Exchange Online connector based on your public IP address or a certificate, or direct send if the scanner only emails internal recipients. Both avoid storing mailbox credentials on the device.
Not sure which of your shared mailboxes can still be signed in to? Book a free Microsoft 365 security assessment and we will find them, along with any service accounts that need attention.