How We Lock Down SMB Microsoft 365 Tenants for $50 of Hardware Per User

The security floor we recommend for every SMB Microsoft 365 tenant is a three-layer stack: Conditional Access, phishing-resistant MFA, and Intune device compliance. That piece is the why. This one is the how. Below is the exact phased rollout we run, the order we run it in, and the gotchas we have hit hard enough to remember.

This is a Business Premium deployment. If you are on Business Standard or Apps for Business, the licensing piece in the floor article covers why you need to upgrade before any of this works.

Prerequisites before phase 0

Before the first policy is touched:

• Licensing: Business Premium for every user who will be protected. Frontline workers and shared device accounts can run on F-series with different policies.
• Named Global Admin accounts: Two human Global Admins minimum, each on their own named account. No shared admin@ mailbox holding the keys to the tenant.
• Time budget: 8 to 12 hours of admin time spread across two weeks of calendar time. The calendar time is mandatory because report-only logs need a week to be useful.
• Pilot user group: Three to five willing volunteers, ideally one technical, one non-technical, one mobile-heavy. They will hit policy issues before the rest of the tenant does.
• Communication plan: A short email template warning users that MFA prompts may change, and a Teams channel for them to report breakage in real time.

Phase 0: Break-glass accounts

This is the part everyone skips. Do not.

Create two cloud-only Global Admin accounts (not synced from on-prem AD, not federated, not tied to a human). Names like [email protected]. Use the .onmicrosoft.com domain so they survive a custom-domain DNS failure.

For each account:

1. Set a 64-character random password. Print it on paper. Put the paper in a physical safe. Do not store the password digitally anywhere.
2. Register two FIDO2 hardware keys per account (primary plus backup). Put one key in the safe with the paper, one in a separate secure location.
3. Exclude the accounts from every Conditional Access policy you will ever create. Set up an Entra security group called BreakGlass-Exclude and add it to the Exclude tab of every policy as a habit.
4. Configure sign-in alerts. Microsoft Entra has an audit rule for Global Admin sign-ins; route the alert to a mailbox at least two people read.

The point of these accounts is the day everything goes wrong. Entra has an outage and your federated logins fail. You misconfigure a CA policy and lock out every admin. Your FIDO2 vendor pushes a buggy firmware update. The break-glass account is the only thing between you and a support ticket that takes 72 hours to resolve while your business is offline.

Phase 1: Microsoft-managed Conditional Access policies in report-only mode

In the Entra admin center, go to Protection > Conditional Access > Policies. Tenants licensed with Entra ID P1 (which Business Premium includes) will have a set of policies named with the Microsoft-managed prefix already created. Examples:

• Multifactor authentication for admins accessing Microsoft Admin Portals
• Block legacy authentication
• Multifactor authentication for users
• Securing security info registration
• Require multifactor authentication for guest users

If you do not see them yet, click New policy from template and add the recommended ones. They ship in Report-only state by default. Leave them there.

For one week:

1. Sign in normally as users and as admins.
2. Check Conditional Access > Insights and reporting daily. The dashboard shows which sign-ins would have been blocked or challenged if the policies were enforced.
3. Investigate every report-only failure. Common ones: legacy IMAP/POP from a forgotten device, a service account using basic auth, a shared mailbox accessed via OAuth from an unsupported client.
4. Remediate before enforcement. Move legacy clients to modern auth, swap service accounts to managed identities or app-only auth.

After a clean week, flip each policy from Report-only to On. You are now gated by Conditional Access. Disable Security Defaults at this point (Entra > Properties > Manage Security Defaults > No). The two cannot coexist and CA is strictly more capable.

Phase 2: Roll FIDO2 YubiKeys to admins

Authentication method config first: Entra > Authentication methods > Policies > FIDO2 security key. Set the state to Enabled, target it at a group called FIDO2-Users, and configure key restrictions if you want to require attestation (we recommend on, with the allowed AAGUID list scoped to Yubico).

Then physically distribute keys. Our standard issue per admin is two YubiKey 5C NFC keys (B08DHL1YDL): one on the keyring, one in the desk drawer. Both registered to the account. If the primary is lost or breaks, the user enrolls a replacement from the backup without an IT ticket.

The model decision comes down to three options:

• YubiKey 5C NFC for any device built in the last five years. USB-C plus NFC means it works on laptops, iPhones, Androids, and iPads. This is the default we ship to admins because one key covers both the workstation and the phone.

Our Pick

YubiKey 5C NFC

Check Current Pricevia Amazon

View Deal

• YubiKey 5C Nano is what we personally carry. It sits flush in the USB-C port and stays there permanently, so there is no "where did I put my key" moment and no risk of leaving it in a hotel room. The honest tradeoff: no NFC, so it does not work for phone-based MFA. We pair it with a 5C NFC on the keyring when phone auth matters. For desk-bound admins or users who lose things, the Nano is the lower-friction choice.

YubiKey 5C Nano

Check Current Pricevia Amazon

View Deal

• Yubico Security Key C NFC for non-admin users at scale. ~$30 per key, FIDO2 and WebAuthn only (no OTP, no Smart Card, no OpenPGP). The full YubiKey 5 series is overkill for a sales rep who only needs M365 sign-in.

Yubico Security Key C NFC

Check Current Pricevia Amazon

View Deal

Order two keys per admin ($110 to $120 per admin), one key per non-admin user when you roll out tenant-wide ($30 to $60 per user depending on tier). For a 25-person company with 3 admins, total hardware cost lands around $1,100 to $1,500 once everyone is covered. One-time spend, 5-plus year hardware life.

Once admins are enrolled with keys, write a Conditional Access policy: Users: Directory roles > Global Admin + Privileged Role Admin + Authentication Admin + Security Admin + others. Cloud apps: All. Grant: Require authentication strength > Phishing-resistant MFA. Report-only for a week. Then enforce.

Phase 3: Intune device enrollment and compliance policies

The grant control "Require device to be marked as compliant" does nothing without an actual compliance policy underneath it. Build the policy first, before you touch any CA grant.

In Intune > Devices > Compliance policies, create one policy per platform you support:

• Windows 10/11 corporate: BitLocker required, Secure Boot enabled, antivirus enabled with signatures up to date, minimum OS build (set to current N-1 release), Defender real-time protection on, no jailbreak/root.
• macOS corporate: FileVault required, firewall enabled, OS version minimum, system integrity protection on, gatekeeper enabled.
• iOS/iPadOS corporate: not jailbroken, OS version minimum, passcode required with complexity, encryption enabled (automatic on supported devices).
• Android Enterprise corporate: not rooted, Play Protect attestation passing, OS version minimum, screen lock with complexity.

Set each policy's Actions for noncompliance to:

1. Mark device noncompliant after 1 day grace period.
2. Send email notification to end user explaining what to fix.
3. Send email to admin after 3 days of continued noncompliance.

Enroll your pilot group's devices via the platform-appropriate path (Autopilot for Windows, Apple Business Manager for Mac/iOS, Android Enterprise for managed Android). Verify the devices show as Compliant in Intune before moving to phase 4.

Phase 4: Add the "Require compliant device" grant control

Now you have compliance policies and you have devices marked compliant. Write the CA policy that requires it.

Create a new Conditional Access policy:

• Users: All users. Exclude: BreakGlass-Exclude group. Exclude: a Contractor-Exemption group you will use for short-term external users.
• Cloud apps: All cloud apps. Exclude: device enrollment endpoints (otherwise you cannot enroll new devices because they are not yet compliant).
• Conditions: Client apps > Browser, Mobile apps and desktop clients. Skip "Other clients" unless you have a specific reason.
• Grant: Require one of: Require device to be marked as compliant OR Require Microsoft Entra hybrid joined device. Use the For multiple controls: Require one of the selected controls option.

Ship it in Report-only state. For one week, watch the Insights and reporting dashboard for users who would be blocked. The usual offenders:

• Personal phones with the Outlook app that were never enrolled.
• A spouse's home laptop the user occasionally checks email from.
• Macs that are technically enrolled but failing compliance because FileVault recovery key escrow has not completed yet.

Remediate each one. Then move the policy to On for your pilot group only (use the Users: Pilot-Group scoping for a few days). When the pilot group has zero new issues, scope it to All users with your standard exclusions.

You now require company-managed devices for tenant access. Phone email on a personal device no longer works unless that device is enrolled. This is the intended outcome.

Phase 5: Tighten the floor

With the three layers live, finish the hardening pass:

• Disable per-user MFA: it conflicts with CA-driven MFA. Entra > Users > Per-user MFA > Bulk disable.
• Disable SMS and voice as MFA methods in Authentication methods policies. Phishing-resistant only.
• Restrict app registrations to admins (Entra > Users > User settings > Users can register applications: No).
• Restrict third-party app consent to admin-approved apps only. Configure the admin consent workflow so users can request rather than self-grant.
• Block legacy authentication explicitly even though the Microsoft-managed policy covers it. Belt and suspenders.
• Audit guest access: Entra > External Identities > External collaboration settings. Restrict guest invites to admins or specific roles. Set guest user permissions to the most restrictive option compatible with your collaboration patterns.

Gotchas we have actually hit

Things the documentation glosses over and we learned at runtime:

• Hybrid join vs Entra-only join. If you have on-prem AD and use Entra Connect, devices can be Hybrid Azure AD Joined. If you are cloud-only, they are Entra Joined (formerly Azure AD Joined). The "Require Hybrid Azure AD joined device" and "Require device to be marked as compliant" grant controls behave differently. For most cloud-only SMBs, compliance is the right primary control; hybrid join is a legacy AD-anchored concept.
• Mac compliance lag on FileVault. New Mac enrollments report non-compliant for up to 24 hours because the FileVault recovery key has not escrowed yet. Build a 24-hour grace period into your compliance policy or your day-one Mac users will be locked out.
• BYOD phone email breaks loudly. The day "Require compliant device" enforces, every user with personal Outlook on iPhone gets a sign-in failure. Have a one-paragraph email ready explaining how to enroll the phone in Intune App Protection (MAM-WE, which does not require full device management).
• Contractors and short-term users. You need a workflow: dedicated Contractor- user accounts with a separate Conditional Access policy that allows access from any device but requires phishing-resistant MFA and limits the apps they can reach. Issue them a temporary YubiKey (you will get most of them back) or a cheap Security Key C NFC.
• Service principals and app-only auth. Conditional Access for workload identities is a separate (paid) Entra add-on. Plan for service accounts and unattended scripts before you start blocking everything else.

Bottom line

Six phases. Two weeks of calendar time. Roughly $30 to $110 of hardware per user, depending on tier. The deployment is not technically hard. It is procedurally unforgiving: the order matters, the report-only step matters, the break-glass account matters. Skip any of those and you will spend an afternoon explaining to your CEO why they cannot read email.

Run it in the order we listed. If you want the conceptual background before you start clicking, the security floor reference piece covers what each layer does and why this stack is the modern floor. When prevention fails (it will, eventually, somewhere), the recovery side of the equation is the Synology backup setup we deployed alongside this. Prevention, identity, device, recovery. That is the full picture.