The Microsoft 365 Security Floor Every SMB Should Hit in 2026

If you run IT for a small or medium business on Microsoft 365, your tenant is already a target. Not because anyone has personally heard of you. Because the attack tools that used to belong to nation-states are now $50 phishing kits, and the operators running them do not care who you are, only that you are reachable. The defense those tools were designed to bypass is plain SMS or app-prompt MFA, which is what most SMB tenants still run.

This is a reference piece, not a deployment guide. We walk through the threat model, the three layers that constitute the real security floor for a Business Premium tenant, why the licensing tier matters, and what this stack honestly does not solve. The companion piece, how we lock down SMB Microsoft 365 tenants for $50 of hardware per user, is the step-by-step deployment.

The threat model SMBs actually face in 2026

Three years ago the threat model for SMB Microsoft 365 was credential stuffing and password sprays. Turning on any kind of MFA stopped most of it. That is no longer the model.

What is on the menu now:

• Adversary-in-the-Middle (AiTM) phishing. Commodity kits like EvilProxy and Tycoon 2FA host a reverse proxy that sits between the user and the real Microsoft login. The user types their password and approves their MFA prompt on the proxy. The proxy captures the resulting authentication token and replays it from the attacker's machine. The user sees a normal login. The attacker walks in as them, with valid MFA. Plain push, SMS, and TOTP all fall to this attack.
• Token replay and refresh abuse. Once an attacker has a primary refresh token, they can sit on it for days or weeks, issuing new access tokens for any resource the victim could touch. No re-authentication prompt fires.
• OAuth consent phishing. A malicious third-party app asks for "read your email" or "send mail on your behalf" permissions. The user clicks "accept." No password, no MFA, full delegated access. Default tenant policy in most SMBs allows this.
• BYOD spillover. An employee's personal laptop gets malware. Their browser session has cached M365 tokens. The attacker exfiltrates SharePoint, OneDrive, and email through what looks like a legitimate session from a known device.
• Help-desk social engineering. Attacker calls IT pretending to be a locked-out employee. Asks for the MFA method to be reset. IT helpfully resets it. Attacker enrolls their own MFA method on the victim's account.

The common thread: every one of these defeats plain MFA. The defense has to move up the stack, to "what device is this," "what auth method are you using," and "what conditions does this sign-in have to meet."

Why Security Defaults are not the answer at SMB scale

Microsoft 365 ships every new tenant with Security Defaults turned on. They are free, they require MFA for all users, and they block legacy authentication. For a tenant with zero IT staff, they are better than nothing.

They are not the floor we are describing here. Security Defaults have real limits at SMB scale:

• All-or-nothing. You cannot exclude a service account, a break-glass account, or a kiosk. The setting applies to everyone.
• No phishing-resistant requirement. Push and SMS satisfy them. AiTM laughs at this.
• No device condition. A logon from a managed laptop and a logon from an unmanaged Chromebook in a hostile country are treated identically.
• They conflict with Conditional Access. Once you start writing CA policies for finer control, Microsoft requires you to disable Security Defaults. They cannot coexist.

Security Defaults are the training wheels. Once you have Business Premium licensing, leaving them on is leaving capability on the table.

The three-layer floor

Layer 1: Conditional Access policies. The rule engine. Every sign-in is evaluated against policies that say "if user X, accessing app Y, from condition Z, then require A or block." This is where you write the rules that say "all admins require phishing-resistant MFA" or "no one from outside North America gets into Exchange." As of 2024 Microsoft began auto-creating a set of Microsoft-managed Conditional Access policies for tenants licensed with Entra ID P1 (which is included in Business Premium). These start in report-only mode with sensible names like "Multifactor authentication for admins accessing Microsoft Admin Portals" and "Block legacy authentication." They are objectively better than the CA policies most SMB IT teams write from scratch. Accept them, review the report-only logs for a week, then enforce.

Layer 2: Phishing-resistant authentication. The identity proof. The only MFA factor that survives AiTM is one bound to the origin of the login - meaning the authenticator refuses to release its secret to anything other than the real login.microsoftonline.com. Three options qualify in 2026: FIDO2 hardware keys (YubiKey 5 series, Yubico Security Key series, Token2), Windows Hello for Business on managed Windows endpoints, and Entra passkeys (synced through Microsoft Authenticator or platform passkey providers). At minimum, every Global Admin and Privileged Role Admin needs a FIDO2 hardware key, ideally two (primary plus backup). Mid-sensitivity roles (Finance, HR, anyone with mailbox delegate rights) come next. Then everyone else, in pilots.

Layer 3: Device compliance via Intune. The trusted endpoint. The grant control inside a Conditional Access policy called "Require device to be marked as compliant" tells Entra to look at the device making the request, find its Intune compliance record, and only allow the sign-in if the device is enrolled and meeting the compliance policy. This is what "company device only" actually means in M365. It is also where most SMB deployments fall down, because they turn on the grant control without writing real compliance policies underneath. The grant control without a real policy is enforcement without criteria, which means everything passes. The policy is the work.

This stack works because each layer covers a different category of failure. Layer 1 is the policy fabric: it decides what rules apply where. Layer 2 closes the credential-theft path. Layer 3 closes the token-replay-from-untrusted-device path. Defeating all three at once is a meaningfully harder problem than defeating any one.

The licensing reality

You cannot build this floor on Microsoft 365 Business Standard. You can build it on Business Premium. The price gap is roughly $10 per user per month: Business Standard is ~$12.50/user/month, Business Premium is ~$22/user/month, both billed annually. The math for a 25-person company:

• Business Standard: 25 × $12.50 × 12 = $3,750/year
• Business Premium: 25 × $22 × 12 = $6,600/year
• Delta: $2,850/year, or $114 per user per year

For $114 per user per year, Business Premium adds Entra ID P1 (Conditional Access, group-based licensing, Application Proxy), Intune (full MDM/MAM), Microsoft Defender for Business (endpoint detection and response), Defender for Office 365 Plan 1 (Safe Links, Safe Attachments), and Azure Information Protection P1 (sensitivity labels). One contained ransomware incident, or one prevented business email compromise wire transfer, pays for that delta across the entire company for the rest of the decade. Business Premium is not the "nice to have" tier for SMBs. It is the baseline.

The deployment order matters

The single most common way SMBs break their tenant during a security rollout is doing the layers in the wrong order. The order that works:

1. Break-glass accounts first. Two cloud-only Global Admin accounts, FIDO2-backed, excluded from every Conditional Access policy you will ever create. If you do not do this, the day you misconfigure a policy is the day you cannot log into your tenant to fix it.
2. Microsoft-managed CA policies in report-only mode. Let them collect data for a week. Review the report-only sign-in logs for any user who would have been blocked. Investigate and remediate.
3. Enable phishing-resistant auth methods in Entra. Roll FIDO2 keys to admins first, while plain MFA still works as a fallback for everyone else. Do not require phishing-resistant MFA tenant-wide until your users actually have keys.
4. Enforce the Microsoft-managed CA policies. Now you are gated by CA, not Security Defaults.
5. Intune enrollment and compliance policies. Stand these up before you turn on the "Require compliant device" grant control. Compliance has to exist before you can require it.
6. Add the "Require compliant device" grant control. Again, in report-only mode first, then pilot group, then tenant-wide.

Skipping the report-only step, or doing layer 3 before layer 1, is how IT teams accidentally lock themselves and their users out for an afternoon. The companion deployment guide walks through each phase with the gotchas we have actually hit.

What this floor does not solve

Honest tradeoffs, because this is a reference piece and the reader needs to know where the floor stops:

• Insider risk. A trusted employee with legitimate access who copies a SharePoint library to a personal Dropbox before resigning is not stopped by this stack. That is a DLP and information protection problem.
• Supply-chain compromise of a sanctioned third-party app. If you have approved a vendor's OAuth app and the vendor gets breached, the attacker inherits the permissions you granted. App consent governance and conditional access for workload identities help. Neither is in this floor.
• Social engineering against the help desk. "I lost my YubiKey, can you reset my MFA" is the new "I forgot my password." Your help-desk identity verification process matters more than your MFA strength.
• Contractor and vendor access. Guest accounts in Entra do not always inherit your CA policies cleanly. External Identities and B2B collaboration settings are a separate config surface.
• Recovery from a breach that does happen. Prevention is the floor. Recovery is the floor below the floor. We have written about that side: how a $1,000 Synology NAS completed our Microsoft 365 backup strategy covers the on-site backup layer that makes ransomware survivable rather than fatal.
• Endpoint malware that is already on a "compliant" device. Intune compliance proves enrollment and basic posture. It is not a guarantee the machine is clean. Microsoft Defender for Business (included in Business Premium) provides the EDR layer that catches what compliance does not.

The floor is necessary, not sufficient. It is the part where the cost-benefit is so lopsided that nothing else you can buy comes close. After this is in place, the next investments are user training (against social engineering), DLP policies (against insider risk and accidental sharing), and a tested incident response runbook (for when something gets through anyway).

Bottom line

The three-layer floor is the smallest stack that meaningfully changes your tenant's outcome against the attacks that are actually running in 2026. Conditional Access plus phishing-resistant MFA plus device compliance. Business Premium licensing pays for all three with no add-ons. The work is not in buying it. The work is in deploying it in the right order, with break-glass accounts and report-only safety nets, so you do not lock yourself out on the way to locking attackers out.

If you are ready to deploy, the step-by-step lockdown guide is the runbook we follow. If you are still pricing the gap, the workstation side of the equation is in the WFH workstation setup we ship to every remote employee, and the recovery side is in the Synology backup piece. Prevention, recovery, endpoint. That is the whole shape of a defensible SMB Microsoft 365 environment.