The settingWhat we hold this to
CreativeTechs minimum
Every shared mailbox and every service account has AccountEnabled = false (sign-in blocked). No shared mailbox appears in the MFA-unregistered report.
Benchmark position
No published benchmark states this directly; CIS covers shared mailbox sign-in indirectly. The assertion is ours.
Where we differ, and why
This is a hygiene control we authored because the unregistered-MFA report is otherwise permanently dirty and nobody trusts it.
Where the switch is
Entra admin centre → Identity → Users → select the account → Block sign-in. Confirm delegation still works via Exchange admin centre → Recipients → Mailboxes → Delegation.
How to verify
Get-Mailbox -RecipientTypeDetails SharedMailbox | % { Get-MgUser -UserId $_.ExternalDirectoryObjectId -Property AccountEnabled } # expect AccountEnabled False- Why it matters
- These accounts don't need MFA — they need to not be sign-in-able at all. They fill every “unregistered for MFA” report and then never get fixed.
- How we check
- Maester MT.1024.mfaRegistrationV2 — then sort the list into enrol versus block.
- Fix — M365
- Entra → user → Block sign-in. Confirm the shared mailbox is reached by delegation, not direct sign-in.
- Fix — Google
- Suspend the account, or convert to a group or delegated mailbox.
- User notices
- None if nothing signs in directly. Something breaks if a script uses the account — replace with an app registration.
- Expected pushback
- None, but the audit is an afternoon per tenant. Our own tenant: 14 of 20 unregistered, several exactly this.
