Common Microsoft 365 Security Gaps in Small and Mid-Sized Businesses

Introduction

After reviewing Microsoft 365 tenants across dozens of small and mid-sized organizations — companies with 50 to 500 users, across industries from healthcare to manufacturing to professional services — a pattern becomes clear very quickly. The same ten security gaps show up in nearly every environment. Not because the IT teams are negligent. Usually, it is because Microsoft 365 ships with permissive defaults, the security surface area is genuinely enormous, and the person responsible for the tenant has fifteen other things competing for their attention on any given Tuesday.

This article is not a settings walkthrough. It is not a screenshot-by-screenshot portal tour. It is a consultative checklist — the same set of findings we discuss with IT directors and managers after an assessment. Each gap gets an honest explanation of what the risk actually looks like in practice, why it tends to persist, and what the remediation path involves. Some of these fixes are free and take thirty minutes. Others require additional licensing and a project plan. The goal is to help you triage.

If you are an IT director or manager at an SMB, this article should give you a clear picture of where your tenant probably stands and which items to prioritize. If you are an MSP, it should validate what you already suspect about most of the tenants you manage — and give you a framework for having the conversation with your clients.

Why SMB Tenants Are Particularly Exposed

The core problem is straightforward: small and mid-sized IT teams cannot afford specialization. The person managing your Microsoft 365 tenant is almost certainly also managing the network, answering helpdesk tickets, dealing with vendor relationships, and probably troubleshooting a printer jam at least once a week. Security configuration does not get deferred because anyone is lazy — it gets deferred because there are only so many hours in a day, and the things that generate visible complaints (the broken VPN, the user who cannot print, the executive whose Outlook is "slow") will always win the triage war against invisible risks like an overly permissive sharing policy.

Microsoft has made genuine progress here. Security Defaults, introduced in 2019 and gradually strengthened since, give new tenants a much better starting posture than they had five years ago. Managed tenants pick up MFA prompts, block legacy authentication for new sign-ups, and enforce a few other baseline protections automatically. But Security Defaults are a floor, not a ceiling. They are the bare minimum for a tenant that has done nothing else. And for organizations that created their tenant before Security Defaults existed — or that disabled them early on because the MFA prompts were disrupting users — the baseline may be even weaker than you think.

The other structural problem is licensing complexity. Microsoft 365 Business Basic, Business Standard, Business Premium, E3, E5, and the various add-on SKUs all include different security capabilities. Many of the most important protections — Conditional Access, Defender for Office 365, Intune device compliance, Microsoft Purview DLP — require specific license tiers that not every SMB has purchased. IT teams often do not know which protections their current licensing actually includes, which means they may be paying for capabilities they have never turned on.

Gap 1: MFA Is Incomplete or Poorly Implemented

Multi-factor authentication is the single most effective control you can deploy against account compromise. Microsoft's own data puts it at blocking more than 99 percent of credential-stuffing attacks. Most IT teams know this. The problem is not awareness — it is completeness. MFA is "enabled" in almost every tenant we review. But when you look closely at how it is implemented, the coverage is almost never as thorough as the IT team believes.

Security Defaults will prompt users to register for MFA and enforce it at sign-in under certain conditions — but it does not enforce it for every authentication event, it does not cover every account type, and it does not give you control over which conditions trigger the MFA challenge. Service accounts are a common blind spot. These accounts are often excluded from Security Defaults because they are not interactive users, but they frequently have elevated permissions and their credentials tend to be static, shared, and stored in spreadsheets or scripts. Break-glass accounts — the emergency admin accounts every tenant should have — are another gap. If your break-glass account has a long static password and no MFA, it is precisely the kind of account an attacker will target.

The real solution is Conditional Access, which requires Microsoft Entra ID P1 licensing (included in Business Premium and E3/E5). Conditional Access lets you define policies that enforce MFA based on user, application, device state, location, and risk level. You can require MFA for all users on all cloud apps as a baseline, then layer in additional policies for high-risk scenarios — admin portal access from outside the corporate network, sign-ins flagged as risky by Entra Identity Protection, or access to sensitive applications from unmanaged devices. The difference between Security Defaults and Conditional Access is the difference between a smoke detector and a fire suppression system. Both are better than nothing. Only one gives you actual control.

Gap 2: Legacy Authentication Is Still Enabled

This gap is closely related to MFA, and it is the reason so many MFA deployments provide less protection than they appear to. Legacy authentication protocols — POP3, IMAP, SMTP AUTH, Exchange ActiveSync with basic authentication, and older versions of the Office client that predate ADAL/MSAL — do not support modern authentication flows. That means they do not support MFA. When a user (or an attacker) authenticates using one of these protocols, the MFA policy simply does not apply. The credentials go straight through.

Microsoft began deprecating basic authentication for Exchange Online in 2022 and has progressively disabled it for most protocols. But the rollout has been uneven, tenants have been able to request re-enablement through support, and SMTP AUTH remains enabled by default for mailboxes that need it for scanning, printing, or line-of-business applications that send email. The result is that many SMB tenants still have at least some legacy authentication pathways open — sometimes intentionally for a multifunction printer or a legacy ERP system, sometimes because nobody has checked.

The first step is visibility. Pull your Entra ID sign-in logs and filter for "Client app" values that indicate legacy authentication: Exchange ActiveSync, IMAP, POP, SMTP, Other clients. If you see successful authentications on any of those protocols, you have an MFA bypass in production. The remediation path is to block legacy authentication through Conditional Access (preferred) or by disabling the protocols at the Exchange Online mailbox level. The hard part is not the block itself — it is identifying which users and applications will break when you flip the switch. A multifunction printer that sends scan-to-email using SMTP AUTH will stop working. A user with Outlook 2013 will get locked out. This is why the block needs to be preceded by a monitoring period, not deployed blindly.

Gap 3: Too Many Global Administrators

The average SMB tenant we review has between three and five global administrator accounts. Some have more. In nearly every case, at least one of those accounts is a shared credential — an "admin@" account whose password is known by two or three people and stored somewhere that is not a secrets vault. The reasoning is understandable: the IT team is small, everyone needs access to everything, and the person who set up the tenant years ago did not think about role-based access. But global administrator is the most powerful role in Microsoft 365. An account with that role can read any mailbox, delete any data, modify any configuration, and disable any security control in the tenant. It is the one role where a compromise means total compromise.

Microsoft publishes over 80 built-in admin roles in Entra ID, and most administrative tasks can be handled with a role that is far more limited than Global Administrator. The person who manages Exchange Online should have the Exchange Administrator role — not Global Admin. The person who manages Intune should have the Intune Administrator role. The person who resets passwords should have the Helpdesk Administrator role. The principle of least privilege is not academic here. It directly limits the blast radius when an account is compromised, and it reduces the chance that an administrator accidentally breaks something outside their area of responsibility.

The target for most SMB tenants is two global administrator accounts: one for the primary IT administrator and one break-glass account. The break-glass account should have a strong, unique password stored in a physical safe or a secure vault, should be excluded from Conditional Access policies (so it remains accessible in an emergency), and should be monitored for any sign-in activity. Every other administrator should be assigned the least-privileged role that covers their actual job function. If you currently have five global admins, you can probably get to two within a week — and the security improvement is immediate and significant.

Gap 4: Email Security Is Default, Not Hardened

Microsoft 365 includes Exchange Online Protection (EOP) with every subscription, and EOP is genuinely decent at catching known malware and obvious spam. The problem is everything between "obvious spam" and "targeted phishing," which is where most email-based attacks now live. A well-crafted phishing email with no malware attachment, a clean sender domain, and a convincing Microsoft-branded sign-in page will sail through default EOP settings without triggering anything.

The first layer that most SMBs miss is email authentication — SPF, DKIM, and DMARC for their own domain. SPF is usually configured because Microsoft's setup wizard includes it. DKIM is frequently not enabled because it requires publishing CNAME records and enabling the signing in the Defender portal, and nobody gets around to it. DMARC is either not published at all or set to p=none, which means the domain is telling receiving servers "here are my authentication results, but do not act on failures." A DMARC policy of p=none provides visibility through aggregate reports but zero protection against spoofing. Moving to p=quarantine or p=reject is the actual security improvement, but it requires confidence that all legitimate sending sources (your mail server, your CRM, your ticketing system, your marketing platform) are properly authenticated first.

The second layer is Defender for Office 365 Plan 1, which adds Safe Links (real-time URL scanning at click time), Safe Attachments (sandbox detonation of attachments), and enhanced anti-phishing policies with impersonation protection. This is included in Business Premium and E5, and available as an add-on for E3. If your organization handles any sensitive data and your users receive external email — which is everyone — this is not optional security. It is the difference between a mail filter that catches yesterday's threats and one that evaluates threats in real time. Beyond Defender, you should also verify that external email auto-forwarding rules are blocked. Attackers who compromise a mailbox frequently set up a forwarding rule to exfiltrate ongoing email silently. This is a transport rule you can deploy in Exchange Online in under five minutes, and it is absent in the majority of tenants we assess.

Gap 5: Audit Logging Is Not Fully Enabled or Monitored

The Unified Audit Log in Microsoft 365 records an extraordinary range of activity — sign-ins, file access, mailbox actions, admin configuration changes, SharePoint sharing events, Teams operations, and more. It is one of the most valuable forensic tools available to you during an incident. It is also, in a remarkable number of SMB tenants, either not enabled, not retained long enough, or enabled but never reviewed by anyone.

Microsoft has improved the defaults over the past few years. For tenants created after January 2019, the Unified Audit Log is enabled by default. For older tenants, it may not be. The check is simple — go to the Microsoft Purview compliance portal, navigate to Audit, and attempt a search. If you get a banner telling you that auditing needs to be turned on, you have been operating without forensic visibility for the entire life of your tenant. Even when auditing is enabled, the default retention period for E3 and Business Standard is 180 days. E5 extends this to one year, with an option for ten-year retention with an add-on license. If an attacker has been in your environment for six months — which is common for business email compromise — you need at least that much retention to reconstruct what happened.

But the bigger issue is not enablement or retention — it is monitoring. Audit logs that nobody reviews are security theater. You are collecting evidence, but only for the post-mortem. The logs are not going to tap you on the shoulder and tell you that a user's mailbox has a new forwarding rule pointing to an external address, or that someone just exported 10,000 files from SharePoint, or that an administrator signed in from a country where your organization has no employees. Alert policies in Microsoft Purview and Microsoft Defender for Cloud Apps can automate some of this, but they need to be configured. The out-of-the-box alert policies cover a few scenarios, but they are not sufficient for a real detection strategy. If you do not have the bandwidth to build and maintain alert rules internally, this is a strong argument for a managed detection service or an MSSP with M365 security expertise.

Gap 6: External Sharing Is Too Permissive

SharePoint Online and OneDrive for Business default sharing settings are more permissive than most IT teams realize. Depending on when your tenant was created and which defaults were applied, your users may be able to create "Anyone" links — shareable URLs that require no authentication and can be forwarded to anyone on the internet. Even if "Anyone" links are disabled, the default may still allow sharing with "New and existing guests," which means any user can invite any external email address to access a document or folder without IT approval.

The risk here is not that external sharing exists — it is that it is uncontrolled and invisible. Users share documents with vendors, clients, and partners because the work requires it. That is legitimate. The problem is when there is no review process, no expiration on shared links, no restrictions on which sites or libraries allow external sharing, and no visibility into who currently has access to what. Over time, the external sharing surface grows without bound. Former vendors still have access to project folders. A "temporary" link shared with a consultant two years ago is still active. An employee shared a folder instead of a file, and the external party can now browse an entire document library.

The remediation is not to disable external sharing entirely — that is usually impractical and creates shadow IT. It is to scope it intentionally. Restrict "Anyone" links at the tenant level. Require guests to authenticate. Set default link types to "Specific people" rather than "People in your organization." Enable link expiration with a reasonable default (30 or 90 days). Use sensitivity labels to block sharing on libraries that contain regulated or confidential data. And most importantly, establish a periodic access review — quarterly at minimum — where someone with business context examines who has external access and removes what is no longer needed. Microsoft Entra access reviews can automate the mechanics of this, but they require Entra ID P2 or Entra ID Governance licensing.

Gap 7: No Device Management or Conditional Access for Endpoints

This is the gap that separates tenants with an identity-only security posture from tenants with a real zero-trust posture. In the majority of SMB tenants we assess, users access corporate email, files, and Teams from whatever device they happen to have — a personal laptop with no disk encryption, a phone with no PIN, a family computer shared with teenagers. IT has no visibility into these devices, no ability to enforce security baselines on them, and no ability to wipe corporate data if the device is lost or the employee leaves the organization.

The first step toward addressing this is Intune enrollment, which requires Microsoft Intune Plan 1 licensing (included in Business Premium, E3, and E5). Intune lets you enroll devices, push configuration policies, enforce encryption, require a PIN or password, and mark devices as "compliant" or "not compliant" based on a set of rules you define. But enrollment alone is not enough — you need to connect it to access. This is where Conditional Access comes back into the picture. A Conditional Access policy that requires a compliant device for access to Exchange Online and SharePoint Online means that a user on an unmanaged personal laptop will be blocked from corporate data. They can still authenticate, but they cannot access the resources until their device meets your baseline.

The objection IT teams usually raise is that requiring managed devices will disrupt users who work from personal devices, especially in BYOD-heavy environments. That is a valid concern, and there are intermediate steps. Intune's app protection policies (MAM without enrollment) can containerize corporate data within managed apps on personal devices without requiring full device enrollment. Outlook and Teams on a personal phone can be protected with app-level PIN requirements, encryption, and selective wipe — without IT controlling the entire device. This is a reasonable middle ground for organizations that are not ready for full device management but need to stop the current state of completely uncontrolled access.

Gap 8: Data Loss Prevention Is Absent

Data Loss Prevention (DLP) is one of those capabilities that organizations know they should have but almost never implement until a regulatory requirement forces the issue or an incident makes the gap impossible to ignore. In most SMB tenants, there are no DLP policies at all. No rules that detect credit card numbers in outbound email. No policies that flag Social Security numbers shared through Teams chat. No restrictions on uploading files containing health records to a personal OneDrive. Sensitive data flows through Microsoft 365 with zero friction and zero detection.

The practical consequence is that data leaks happen quietly and continuously. An employee forwards a spreadsheet with customer payment data to their personal email so they can "work from home." A contractor pastes account credentials into a Teams channel instead of using a secure vault. A manager shares a folder containing employee health information with an external benefits consultant using an unrestricted sharing link. None of these actions trigger an alert, a block, or even a log entry that anyone reviews. The data is gone, and nobody knows.

Microsoft Purview DLP is included in Business Premium, E3, and E5, with more advanced capabilities in E5 and the E5 Compliance add-on. A reasonable starting point for most SMBs is three policies: one for financial data (credit card numbers, bank account numbers), one for personally identifiable information (SSNs, passport numbers), and one for health data if you handle any protected health information. Start in "test mode" — the policy detects and logs matches but does not block anything. This lets you tune the rules and identify false positives before you start blocking users. Sensitivity labels add another dimension by classifying documents and emails at the content level, enabling you to build DLP policies that key off the label rather than pattern matching alone. The combination of sensitivity labels and DLP policies gives you a classification and enforcement layer that most SMB tenants are completely missing.

Gap 9: Secure Score Is Ignored or Misunderstood

Microsoft Secure Score is a numeric rating of your tenant's security configuration, expressed as a percentage of the maximum achievable score for your licensing tier. It lives in the Microsoft Defender portal and provides a ranked list of recommended actions with estimated point values. It is, in concept, exactly the kind of prioritization tool that resource-constrained IT teams need. In practice, it is either completely ignored or pursued with the wrong mindset.

The "ignored" case is straightforward. The IT team has never opened Secure Score, does not know it exists, or looked at it once and found the number discouraging enough to close the tab. This is a missed opportunity. Secure Score is not a perfect tool — it sometimes overweights low-impact actions and underweights high-impact ones — but it is a free, built-in assessment that identifies real configuration gaps with specific remediation guidance. Even if you disagree with the prioritization, the inventory of findings is valuable.

The "misunderstood" case is more subtle and arguably more dangerous. Some IT teams or MSPs treat Secure Score as a gamification exercise — chasing the number for its own sake, implementing every recommendation without evaluating whether it is appropriate for the organization, or reporting the score to leadership as a proxy for security posture without explaining what it actually measures. Secure Score does not assess the quality of your detection rules, the readiness of your incident response process, the security awareness of your users, or the resilience of your backup strategy. It measures configuration state. A tenant can have a high Secure Score and still be one phishing email away from a full compromise if the users are not trained and the detection is not monitored. Use Secure Score as one input among many, not as the scoreboard.

Gap 10: No Incident Response Plan for Cloud

When we ask SMB IT teams what they would do if they discovered a compromised mailbox tomorrow morning — right now, today — the answers are usually vague. "We'd reset the password." Okay. What else? Revoke active sessions? Check for mailbox rules? Review the audit log for lateral movement? Determine whether the attacker accessed SharePoint or Teams data? Notify affected parties? The honest answer, in most cases, is that nobody has thought through the sequence in advance, and the team would be figuring it out in real time while the compromise is still active.

An incident response plan for cloud does not need to be a 50-page document. For an SMB, it needs to be a concise, practiced runbook that covers the most likely scenarios: compromised user account, compromised admin account, business email compromise with financial fraud, ransomware delivered through email, and mass data exfiltration. For each scenario, the runbook should answer six questions: How do we detect it? How do we contain it? How do we investigate the scope? How do we remediate? How do we recover? Who do we notify? The specific M365 actions — revoking sessions via Entra, disabling the account, checking sign-in logs, reviewing mailbox rules, searching the unified audit log, checking for OAuth app consents — should be documented step by step so that the person responding at 2 AM on a Saturday does not have to search Microsoft documentation under pressure.

The other dimension that most SMBs miss is preparation for incident investigation. If the Unified Audit Log is not enabled (Gap 5), you cannot reconstruct what happened. If you do not have the appropriate licensing for advanced hunting in Microsoft Defender, your forensic capabilities are limited. If mailbox audit logging is not configured to capture the right actions, you may not be able to determine which emails the attacker read or forwarded. Incident response readiness is not just about having a plan — it is about making sure the logging, retention, and tooling are in place before you need them. The worst time to discover that your audit logs only go back 90 days is during an investigation that needs six months of data.

A Prioritization Framework

Ten gaps is a lot to stare at, and the instinct for most teams is to either try to fix everything at once or feel overwhelmed and fix nothing. Neither works. What follows is a three-tier prioritization framework based on impact, effort, and dependency. Tier 1 items protect against the most common and most damaging attack patterns and can be completed in days. Tier 2 items address significant gaps that require a bit more planning but are achievable within a month. Tier 3 items are strategic investments that need project-level planning and may require additional licensing or headcount.

This is not arbitrary. Tier 1 items are at the top because they directly address the initial access and privilege escalation techniques that appear in the majority of real-world M365 compromises. An attacker who cannot authenticate (because MFA is enforced and legacy auth is blocked) and who does not have a global admin account to target has a dramatically harder time getting into and moving through your tenant.

A note on licensing: Tier 1 items are achievable with Entra ID P1, which is included in Business Premium and M365 E3. If your organization is on Business Basic or Business Standard, the upgrade to Business Premium is often justifiable on the strength of Conditional Access and Intune alone. Tier 2 adds Defender for Office 365 P1, also included in Business Premium. Tier 3 items draw on Intune P1 and Microsoft Purview capabilities that are distributed across several license tiers. The licensing can be confusing, but the key insight is that Business Premium includes a remarkable amount of security tooling that most SMBs on that plan have never turned on.

Final Takeaways

The pattern across all ten gaps is consistent: the majority are configuration problems, not licensing problems. The controls exist. The settings are available. The documentation is public. What is missing is the time, the focus, and the systematic attention to work through the security surface area and make deliberate decisions about each control. Microsoft 365 ships with defaults that prioritize ease of use and rapid adoption — which is the right call for getting an organization onboarded, and the wrong posture for operating securely over time. The gap between "tenant is working" and "tenant is hardened" is where most of the risk lives.

Of the ten gaps listed here, at least half can be addressed with existing licensing and an afternoon of focused work. Block legacy auth. Reduce admin accounts. Enable DKIM. Publish a DMARC record with enforcement. Restrict external sharing defaults. Block auto-forwarding rules. Enable audit logging if it is not on. These are not projects — they are configuration changes. The items that do require additional licensing — Conditional Access, Defender for Office 365, Intune, DLP — are worth the investment because they address the categories of risk that configuration alone cannot cover: adaptive authentication, real-time threat detection, device trust, and data classification. If your organization handles any regulated data or serves clients who expect you to handle their data responsibly, these are not nice-to-have capabilities. They are operational requirements.

If you recognize your organization in this list and want an independent assessment of where your Microsoft 365 tenant stands, that is exactly what our IRIS assessment is designed to deliver — a structured review across twelve governance domains with prioritized findings and a remediation roadmap. But whether you engage outside help or work through this list internally, the important thing is to start. The gaps do not fix themselves, and the risk compounds over time.