These are not edge cases. They are the pattern.
Most small businesses stand up Microsoft 365 once, usually with help from whoever sold them the licenses, and then never revisit the security configuration. The setup gets done. The team gets to work. Nobody goes back.
Microsoft 365's out-of-the-box configuration is tuned for collaboration and onboarding, not for a business that needs to answer a cyber insurance questionnaire honestly. Over the past few years Microsoft has been tightening the defaults for newly provisioned tenants, which is good. It does not help the thousands of tenants that were provisioned before those changes and never had someone go back and lock them down.
The five gaps below are not obscure. They do not require specialist tooling to find. They are findable by anyone with Global Admin access and about ten minutes. I keep writing them down because they keep showing up.
Legacy authentication still enabled somewhere
Legacy authentication refers to older protocols that sign in to Microsoft 365 without the token-based flow that supports multifactor authentication. Basic Auth for SMTP, POP, IMAP, old ActiveSync configurations, and some line-of-business integrations all fall under this category.
The critical detail: a sign-in over legacy authentication bypasses modern MFA entirely. If an attacker has a valid username and password, they can authenticate through a legacy protocol and get into the mailbox regardless of what MFA policies are in place. This is the single most common path for business email compromise.
Microsoft disabled Basic Auth for most Exchange Online services in late 2022, but exceptions remain. SMTP AUTH for client submission is not fully retired until the end of December 2026. Legacy SharePoint IDCRL sign-ins are not fully retired until May 1, 2026. And admins can still re-enable legacy protocols for individual mailboxes, which is usually how the issue persists. Somebody plugged in a copier or a scan-to-email device years ago, turned SMTP AUTH on for a service account, and nobody ever turned it off.
Almost every small business tenant I audit has at least one shared mailbox, service account, or legacy integration where a legacy authentication path is still live. The person who turned it on usually does not work there anymore.
Create a Conditional Access policy in Microsoft Entra that blocks legacy authentication for all users. Then audit Exchange Online mailbox settings for any individual mailboxes with SMTP AUTH still enabled and disable it where there is no documented business need. If a device genuinely needs to relay mail, move it onto a modern authentication method or an SMTP relay service.
MFA enabled per user but not enforced
There are three ways to enforce multifactor authentication in Microsoft 365, and they are not equivalent.
Per-user MFA, configured in the Microsoft 365 admin center under active users, is the oldest method. It flags each account as Enabled, Enforced, or Disabled. It does not block legacy authentication, does not account for trusted locations, and does not apply automatically to new users unless someone remembers to turn it on.
Security Defaults is a tenant-wide toggle that requires MFA for all users and blocks legacy authentication. It is the right choice for a small business that does not have Microsoft 365 Business Premium and is not ready to manage Conditional Access policies. It is on by default for new tenants created after October 2019, but any tenant that had it explicitly turned off, or that pre-dated Security Defaults and never turned it on, is not protected.
Conditional Access is the modern, flexible method. It enforces MFA on all sign-ins, blocks legacy protocols, allows exceptions for break-glass accounts, and integrates with device compliance and sign-in risk scoring. It requires Microsoft 365 Business Premium or an equivalent license.
What I find in almost every assessment: the tenant was configured a few years ago with per-user MFA for some accounts, neither Security Defaults nor Conditional Access is actually enforcing MFA at the policy level, and nobody is watching the gap. New accounts get added without MFA. Legacy clients bypass it. The business believes it has MFA. It does not.
Open the Microsoft Entra admin center. Under Overview, look at the Properties tab to see if Security Defaults is enabled. If it is not, and you do not have Conditional Access policies requiring MFA for all users, then your MFA enforcement has a gap. Per-user MFA alone is not sufficient.
If your tenant is on Business Basic or Business Standard, turn Security Defaults on. If you are on Business Premium, build a Conditional Access policy that requires MFA for all users, with two break-glass admin accounts excluded. Confirm it is blocking legacy authentication as part of the same policy.
External sharing still set wide open on SharePoint and OneDrive
SharePoint and OneDrive have a tenant-level external sharing scope that controls what kind of sharing links users are allowed to create. The options are Anyone, New and existing guests, Existing guests only, and Only people in your organization.
For years, the default on new tenants was Anyone, meaning any user could generate a link that required no sign-in and no authentication to open. Microsoft finally tightened the default in late 2020, and continues to tighten it further with expiration policies rolling out in 2026. New tenants provisioned today default to a more restrictive setting.
The problem: every tenant provisioned before late 2020 inherited the permissive default, and most of them never went back to check it. Even tenants provisioned more recently may have had the setting opened up by a setup wizard, a consultant, or a user who needed to share a file quickly and asked the admin to loosen the restriction.
The result is that documents shared years ago by someone who no longer works there are still live on the public internet. No sign-in to open. Access events are logged in the audit log but attributed to anonymous users, so there is no way to tie an open event to a specific person. And the link does not expire unless someone explicitly configured a policy to expire it.
When I pull the sharing links report on tenants provisioned before 2021, the number of live anyone-links is usually in the hundreds. Client proposals, contracts, invoices, employee records. All accessible to anyone who has or inherits the URL.
In the SharePoint admin center, open Policies, then Sharing. Change both the SharePoint and OneDrive external sharing scopes to New and existing guests at most. Change the default link type to Specific people. Then go to Reports, Data access governance, and pull the Sharing Links report to find and review existing anyone-links. If your tenant does not have SharePoint Advanced Management licensed, the standard sharing activity report under Reports gives you a narrower view of the same problem.
Former employees with accounts still active
Offboarding is where security hygiene goes to die. When someone leaves, the business pulls them out of payroll, reassigns their files, and forwards their email to a teammate. What often does not happen: actually disabling the account in Entra, revoking active sessions, and removing MFA so the account cannot be signed back into.
I routinely find accounts in small business tenants belonging to people who left two or three years ago. The account is still licensed. MFA may have been stripped so a manager could access the mailbox once, and then never re-enabled. In some cases the account is still in an admin group because nobody audited role memberships after the person left.
From an attacker's perspective, these accounts are perfect. They are forgotten, they are not monitored, and they often have the same password the employee set years ago. If that password shows up in a credential dump, it is a free path in.
Run the licensed users report and sign-in activity report in the Microsoft 365 admin center. Any account that has not signed in for more than 30 days without a documented reason should be reviewed. Build an offboarding checklist that includes disabling the account, revoking sessions, removing MFA methods and licenses, and reviewing all group and role memberships. Make the checklist mandatory for every departure.
Global Admins used for daily work, no break-glass account configured
Microsoft's own guidance is unambiguous: Global Administrator accounts should not be used for day-to-day work, and every tenant should have at least two emergency access (break-glass) accounts that are excluded from Conditional Access policies so the business can recover the tenant if normal authentication breaks.
What I find in small business tenants: one or two regular user accounts that also happen to be Global Admins, used for email, Teams, and browsing the web. No dedicated admin accounts. No break-glass accounts at all.
This creates two specific risks. First, if the Global Admin's daily account gets phished or compromised, the attacker inherits tenant-wide administrative control. Second, if a Conditional Access policy, an MFA service, or an identity provider outage locks users out, there is no emergency account to recover with. In both cases, the business's options go from bad to worse quickly.
A Global Admin account used to answer email on a phone is not an admin account. It is a disaster waiting to happen.
Create two cloud-only break-glass accounts in the onmicrosoft.com domain with long randomized passwords, Global Admin role permanently assigned, and explicit exclusion from all Conditional Access policies. Store the credentials offline in a documented location. Separately, require every admin to have two accounts: a standard user account for daily work, and a dedicated admin account used only for administrative tasks, with MFA enforced on both.
None of this is advanced. That is the point.
Every one of these gaps is closeable without a platform migration, without a new license, and in most cases without opening a support ticket. The configuration paths are documented in the Microsoft admin center. Anyone with Global Admin access can walk through them in an afternoon.
They persist because nobody went looking for them. The tenant was stood up to work, not to be secure. Over time, the distance between what was configured and what should have been configured grows, because new people get added, new integrations create exposure, and no one circles back.
If you run Microsoft 365 at a small business, the honest question is not whether you have these gaps. Most tenants do. The question is whether anyone is watching. If you cannot pull your Secure Score, your sharing links report, and your sign-in activity logs from memory, you are not watching.
That is a fixable problem. Start with the five above.
See exactly where your tenant stands on all five.
TenantScan™ runs a read-only check against your Microsoft 365 tenant and flags every one of these gaps, plus about twenty more. Five minutes. No install. Nothing stored. Now listed on the Microsoft Marketplace.
Run TenantScanView on the Microsoft Marketplace · Built by Lowery Solutions, Cedar Park, TX