Most mid-market organizations have purchased Microsoft 365 Business Premium or an E3/E5 plan, activated the features their vendor recommended, and moved on. What they have not done is apply the security baseline that Microsoft itself publishes — let alone the hardened configurations that a mature IT governance posture actually requires. The result is a tenant that looks secured on paper, passes a superficial audit, and fails in practice. The gaps are not exotic. They are not zero-days. They are well-documented configuration omissions that attackers, including commodity ransomware operators and business email compromise (BEC) actors, exploit routinely. This post names those gaps specifically, explains why they persist in mid-market environments, and provides actionable remediation steps for each.

Why the baseline keeps getting missed

The Microsoft 365 security model assumes that someone will configure it. The platform ships with defaults that prioritize productivity and interoperability over security. That is a deliberate product decision by Microsoft — not a flaw — but it means every tenant begins in a relatively open state. The responsibility to harden it falls on the customer, and in mid-market organizations with IT teams of two to fifteen people managing a full technology stack, security hardening competes with helpdesk tickets, infrastructure projects, and software rollouts.

A second factor is licensing complexity. Microsoft 365 Business Premium, E3, and E5 each unlock different security capabilities. In our experience, organizations frequently purchase E3 without activating Microsoft Defender for Business, or hold E5 licenses without ever enabling the Privileged Identity Management workload. The licenses are paid for. The features sit dormant.

Gap 1: MFA coverage is incomplete, not absent

Few mid-market IT teams will tell you they have not deployed multi-factor authentication. Most have. The problem is that MFA deployment is almost never universal, and the accounts excluded from MFA enforcement are often the highest-value targets for attackers.

The most common MFA gaps we encounter in M365 tenant assessments:

• Service accounts and shared mailboxes. These are frequently excluded from Conditional Access policies targeting MFA, either because they were provisioned before the policy existed or because enforcing MFA on them requires application-level credential management that was deferred.
• Legacy authentication protocols. IMAP, POP3, SMTP AUTH, and older ActiveSync connections bypass modern authentication entirely. If legacy authentication is not blocked at the tenant level, an attacker with a valid password can authenticate without MFA by using a legacy client. Microsoft’s own telemetry has consistently shown that the overwhelming majority of password spray attacks succeed against accounts with legacy authentication enabled.
• Break-glass accounts. Emergency administrator accounts are routinely created, excluded from all Conditional Access policies for operational continuity, and then never monitored. They represent an always-on path into the tenant.
• Newly provisioned accounts. If MFA is enforced via Conditional Access rather than per-user MFA settings, new accounts provisioned before they are added to the scoped group may have a window of unprotected access.

Remediation: Audit Conditional Access policy scope against your full user and service principal inventory. Block legacy authentication with a dedicated Conditional Access policy targeting all users, all apps, and all legacy authentication client types. Configure break-glass accounts with hardware FIDO2 keys rather than phone-based MFA, store credentials in a sealed physical envelope with access logging, and alert on every sign-in from those accounts.

Gap 2: Conditional access policies are either too narrow or in report-only mode

Conditional Access is Microsoft’s primary enforcement mechanism for identity-based security controls. It is also consistently misconfigured in mid-market tenants. The two most common failure modes are: policies that cover too little (scoped to specific apps or groups rather than all cloud apps for all users), and policies left in Report-only mode after initial testing that was never followed by enforcement.

Report-only mode is a legitimate and useful testing tool. A policy in report-only generates sign-in log data that allows administrators to see what would happen if the policy were enforced, without blocking users. The problem is that enabling report-only mode and then never switching to On is a pattern we observe repeatedly — often because the initial assessment surfaced legitimate users who would have been blocked, the remediation work was deferred, and the policy was never revisited.

Additional Conditional Access gaps that are frequently overlooked:

• Sign-in risk and user risk policies. Microsoft Entra ID Protection (formerly Azure AD Identity Protection) generates risk signals — leaked credentials, impossible travel, anonymous IP access — but those signals only trigger action if risk-based Conditional Access policies are configured and enforced. In most mid-market tenants, these policies do not exist.
• Device compliance requirements. Policies that require compliant or Entra-joined devices are only as effective as the Intune compliance policies that define what “compliant” means. Misconfigured compliance policies (for example, a policy with no compliance rules, which marks all enrolled devices as compliant by default) nullify the Conditional Access control entirely.

Remediation: Audit every Conditional Access policy for mode, scope, and grant controls. Use the Microsoft Secure Score recommendations under the Microsoft 365 Defender portal as a baseline checklist. Enable and enforce sign-in risk and user risk policies with appropriate MFA step-up and block thresholds. Set a quarterly review cadence for all report-only policies.

Gap 3: SharePoint and OneDrive external sharing is open by default

Microsoft 365 tenant-level SharePoint external sharing defaults to Anyone — the most permissive setting — which allows any user in the tenant to generate anonymous sharing links for any file or folder without authentication, expiry, or audit. In our experience, this default remains unchanged in a significant proportion of mid-market tenants that have not undergone a formal security review.

The specific risk: an internal employee generates an “Anyone with the link” URL for a document that contains sensitive data — a board deck, a contract, financial projections — and shares it via email. That email is later forwarded, the link is indexed, or the recipient’s email is compromised. The document is now accessible to anyone who has the URL, with no authentication required, no access revocation trigger, and no expiry.

A comparison of the available SharePoint external sharing settings and their security posture:

Remediation: Set the tenant-level SharePoint sharing to a maximum of New and existing guests unless a specific, audited business case exists for anonymous sharing. Enable link expiry for Anyone links if they must be retained. Enforce domain allow-listing for external sharing to restrict guest invitations to known partner and customer domains. Enable SharePoint access reviews on a quarterly basis for all sites with external access.

Gap 4: Email authentication is half-implemented

SPF, DKIM, and DMARC together form the email authentication stack that prevents domain spoofing and enables receiving servers to verify that email claiming to come from your domain actually originates from your infrastructure. In mid-market organizations, the implementation pattern is almost always the same: SPF is present (often configured years ago during an Office 365 migration), DKIM is partially enabled (sometimes only for the primary domain, not subdomains or third-party sending services), and DMARC is either absent or set to p=none.

A DMARC policy of p=none is a monitoring-only configuration. It instructs receiving mail servers to take no action on messages that fail DMARC authentication — it simply generates aggregate and forensic reports. If no one is reading those reports (which is the case in most organizations without a dedicated email security tool), a p=none policy provides no protection against spoofing. It is a prerequisite for DMARC deployment, not a finished configuration.

Remediation: Audit your SPF record to ensure all legitimate sending services (marketing automation, CRM, HR platforms, ticketing systems) are included. Enable DKIM signing in the Microsoft 365 admin center for all accepted domains and for any third-party sending services that support DKIM. Deploy DMARC at p=none with a reporting address, monitor aggregate reports for two to four weeks, resolve all legitimate sending sources, then move to p=quarantine and ultimately p=reject.

Gap 5: Defender for Business is licensed but not configured

Microsoft Defender for Business is included with Microsoft 365 Business Premium and is available as a standalone product for E3 customers. It provides endpoint detection and response (EDR), vulnerability management, and next-generation antivirus for Windows, macOS, iOS, and Android devices. In practice, it is frequently activated at the tenant level but left in a default or partially onboarded state, with significant portions of the enrolled device inventory not covered by active policies.

Specific configuration gaps that appear frequently:

• Incomplete device onboarding. Defender for Business requires devices to be onboarded to the Microsoft Defender portal, either via Intune, a local script, or Group Policy. Organizations that use a mix of management approaches often have onboarding gaps — BYOD devices, contractor machines, and recently provisioned hardware are the most common blind spots.
• Tamper protection disabled. Tamper protection prevents local processes and registry modifications from disabling Defender’s antivirus and EDR components. In organizations where IT staff historically disabled endpoint protection for troubleshooting, tamper protection may be off tenant-wide.
• Attack surface reduction (ASR) rules not enforced. ASR rules block specific behaviors commonly exploited in malware — macro execution from Office documents, credential theft from LSASS, execution of scripts downloaded from the internet. These rules default to audit mode and require explicit enforcement.
• No defined incident response workflow. Defender for Business generates alerts. If no one is assigned to review the Defender portal, or if alert notifications are not configured to reach on-call personnel, detections do not translate into response actions.

Remediation: Use the Defender for Business device inventory to identify all enrolled versus all Intune-managed devices and close onboarding gaps. Enable tamper protection via the Microsoft Defender portal. Move ASR rules from audit to block mode incrementally, starting with the rules covering known high-risk behaviors (block credential stealing from LSASS, block execution from USB). Assign alert notification recipients and define a minimum response SLA for high-severity detections.

Gap 6: Privileged identity management is absent

Microsoft Entra Privileged Identity Management (PIM) allows organizations to implement just-in-time privileged access — requiring administrators to explicitly activate elevated roles for a defined time window, with optional approval workflows and MFA step-up, rather than holding those roles on a standing basis. PIM is included in Microsoft Entra ID P2, which is part of Microsoft 365 E5 and the Microsoft 365 Business Premium security add-on stack.

In organizations we work with that hold the appropriate licensing, PIM is unconfigured the majority of the time. Global Administrators hold their roles permanently. There is no activation audit trail beyond standard sign-in logs. Role assignments are never reviewed. When an account with Global Administrator access is compromised, the attacker has full tenant control immediately and indefinitely.

Remediation: Enable PIM for all privileged Entra ID roles. Start with Global Administrator, Exchange Administrator, SharePoint Administrator, and Security Administrator. Convert standing role assignments to eligible assignments. Define activation policies: require MFA re-authentication, set a maximum activation window of four to eight hours, and require a business justification on activation. Configure access reviews for eligible role assignments on a quarterly cadence. Reduce the number of permanent Global Administrators to the minimum required (typically zero for day-to-day operations, with break-glass accounts as the exception).

Building a remediation roadmap

The six gaps above are not independent. Addressing them in isolation produces a fragmented result. A structured approach organizes remediation into three phases:

1. Immediate controls (Week 1-2): Block legacy authentication. Enable and enforce MFA for all user accounts. Set SharePoint external sharing to a maximum of New and existing guests. These three actions close the highest-probability attack paths with the lowest operational disruption.
2. Policy hardening (Week 3-6): Enforce Conditional Access policies currently in report-only mode. Implement DMARC at p=none and begin monitoring aggregate reports. Complete Defender for Business onboarding and enable ASR rules in audit mode. Enable PIM for Global Administrator and begin converting standing assignments to eligible.
3. Sustained governance (Ongoing): Move DMARC to p=quarantine then p=reject. Move ASR rules to block mode incrementally. Configure PIM access reviews. Establish a quarterly Secure Score review cadence and assign ownership of the Microsoft 365 security posture to a named individual or function.

Frequently asked questions

We use a third-party IT managed service provider. Shouldn’t they have handled this?

Not necessarily, and this is a common source of false assurance. Many managed service providers focus on availability, helpdesk support, and patching — not proactive security hardening. Security baseline configuration for Microsoft 365 is often not included in a standard MSP contract unless it is explicitly scoped and priced. If your MSP has not provided a formal security assessment of your M365 tenant with documented configuration findings, it is reasonable to assume the baseline has not been applied. Requesting a written security posture report is a fair and appropriate ask of any technology partner.

Our Microsoft Secure Score is above 60%. Does that mean we’re in reasonable shape?

Secure Score is a directionally useful tool, but it has meaningful limitations. It rewards point-in-time configuration states, and many of the highest-weighted recommendations relate to features that are easy to enable without being useful in practice — for example, enabling an audit log setting scores points regardless of whether anyone reviews the audit log. A score above 60 does not indicate that the specific high-risk gaps described in this post have been addressed. Use Secure Score as a checklist driver, not as a pass/fail certification of your security posture.

Is this relevant to us if we’re on Microsoft 365 Business Standard rather than Business Premium?

Several of the controls in this post — specifically Defender for Business and Privileged Identity Management — require Microsoft 365 Business Premium or E3/E5 licensing. MFA, Conditional Access, SharePoint sharing settings, and DMARC apply to all Microsoft 365 plans. If your organization is on Business Standard, the most impactful immediate action is evaluating an upgrade to Business Premium, which adds Defender for Business, Intune device management, and Azure AD P1 (enabling Conditional Access) for a per-user premium that most mid-market organizations find cost-justified relative to the risk reduction.

How long does it take to go through this hardening process?

For a mid-market organization with 100 to 500 users, a competent IT team or external partner can complete the immediate and policy hardening phases in four to six weeks, assuming no major architectural complications (such as a complex hybrid Active Directory environment or a large inventory of legacy line-of-business applications that rely on basic authentication). The sustained governance phase does not have an end date — it is an ongoing operational practice, not a project.

We had a third-party security audit done two years ago. Is that sufficient?

A security audit conducted two years ago reflects your tenant’s configuration at that point in time. Microsoft 365 security defaults, licensing capabilities, and threat actor tactics have all changed materially in that period. Microsoft introduced Security Defaults as a baseline for new tenants, released Defender for Business as a new product, expanded Conditional Access capabilities, and updated its recommended baselines multiple times. Organizations we work with that rely on stale audit findings consistently have a different actual posture than they believe they have. An M365 tenant security assessment should be performed annually at minimum, and after any significant licensing change or organizational restructuring.

Microsoft 365 Security Baseline: What Mid-Market IT Teams Most Commonly Miss

Most mid-market IT teams believe their Microsoft 365 environment is adequately secured when the reality is a set of well-documented configuration gaps that represent active risk. This post provides a specific diagnosis of those gaps and a structured remediation roadmap for senior operations and IT leaders ready to close them.