Building a Practical Zero Trust Baseline for Microsoft 365 and Azure

Zero Trust has been hyped to death, but most small and mid-sized organisations still run on a patchwork of legacy security settings and good intentions. As an IT leader, you don’t need a 200-page framework; you need a clear, realistic baseline that you can actually deploy and maintain.

This guide walks through a practical Zero Trust baseline for Microsoft 365 and Azure, aimed at IT managers, sysadmins, and technical leaders who want to tighten security without breaking the business.

What “Zero Trust” Actually Means in a Microsoft 365 World

Forget the buzzwords. In Microsoft 365 and Azure, Zero Trust mainly boils down to four things:

• Don’t trust the network — Treat internal and external access the same way.
• Verify identity strongly — MFA, device health, and risk signals decide access.
• Limit access — Users and apps only see what they genuinely need.
• Monitor and react — Assume something will go wrong and detect it quickly.

We’ll build towards that using tools you already have in Entra ID (Azure AD), Intune, and Defender, with a focus on policies you can apply in weeks, not years.

Step 1: Clean Up Identities Before You Add More Controls

If your identity layer is messy, Zero Trust controls will either misfire or get disabled after the first user complaint. Start with fundamentals in Entra ID (Azure AD).

1.1 Fix Accounts and Admin Roles

• Remove shared accounts where possible. If you must keep them, put them behind PIM or at least strict conditional access and logging.
• Inventory Global Admins. You should have no more than 3–5, with break-glass accounts excluded from daily use.
• Move day-to-day IT work to less privileged roles (e.g., Exchange Admin, SharePoint Admin, Intune Admin) using privileged access groups or Entra ID PIM.
• Create at least two break-glass cloud-only accounts with long passwords, no MFA, and strict alerting if they log in.

This gives you a clear structure for who can do what, which is essential before enforcing stronger access policies.

1.2 Standardise Identity Sources

• If you run hybrid, confirm that Entra Connect is documented, monitored, and patched.
• Ensure each user has one identity across Azure, 365, and on-prem, not a mix of local accounts and cloud-only workarounds.
• Disable direct sign-in for service accounts where possible; use managed identities and app registrations instead.

A clean identity plane makes your later Conditional Access and device rules far easier to reason about and troubleshoot.

Step 2: Enforce Strong, Conditional Access by Default

Conditional Access is the core enforcement engine of Zero Trust in Microsoft 365. The goal is simple: every sign-in is evaluated for risk, device state, and context, not just username and password.

2.1 Start with a Baseline Policy Set

A practical starter pack for most organisations looks like this:

• Policy: Require MFA for all users
  • Include: All users (exclude break-glass accounts initially).
  • Include: All cloud apps.
  • Grant: Require MFA.
  • Session: Sign-in frequency 8–12 hours, persistent browser session allowed for compliant devices.
• Policy: Block legacy authentication
  • Include: All users.
  • Include: All cloud apps.
  • Conditions: Client apps = Legacy authentication clients.
  • Grant: Block access.
• Policy: Require compliant or hybrid-joined device for admin roles
  • Include: Directory roles = Administrative roles.
  • Grant: Require device to be compliant OR hybrid Azure AD joined + MFA.

Roll these in Report-only mode first, monitor impact, then switch to enforce once you’re comfortable.

2.2 Introduce Risk-Based Controls

Once the basics are stable, lean on Microsoft’s risk signals:

• Policy: Block high-risk sign-ins identified by Entra ID Protection.
• Policy: Require password reset for users flagged as high-risk.
• Use sign-in risk conditions to demand MFA or block access when logins come from unusual locations or impossible travel.

This closes the gap between “good login” and “bad login” by using behaviour and reputation, not just IP ranges.

Step 3: Make Devices First-Class Citizens with Intune

Zero Trust falls apart if you ignore the device. A fully trusted user on a compromised laptop is still a risk. Intune gives you a way to treat devices as identity-bound assets rather than anonymous endpoints.

3.1 Onboard Devices Properly

• For Windows, use Autopilot or at least automatic Entra join + Intune enrolment for all corporate devices.
• For macOS, iOS, Android, ensure devices are enrolled via Company Portal or platform-specific enrollment (ABM/ASM, Android Enterprise).
• Tag devices with ownership (Corporate vs BYOD) and dynamic groups for policy targeting.

A device that isn’t visible in Intune should be treated as untrusted. Make that expectation clear to users early.

3.2 Define a Realistic Compliance Policy

A good baseline compliance policy should enforce:

• Disk encryption (BitLocker/FileVault).
• OS version minimums (e.g., no unsupported Windows builds).
• Secure startup (TPM, Secure Boot where available).
• Defender or equivalent AV active and up to date.

Don’t start with every checkbox ticked. Begin with encryption + AV, then tighten OS versions and other controls once you have visibility into your fleet.

3.3 Link Compliance to Access

Next, wire this into Conditional Access:

• Create a policy: Require compliant device for key apps (SharePoint, OneDrive, Teams, Exchange Online).
• For high-risk workloads (HR, Finance), consider compliant device + trusted location to access sensitive web apps.
• Use app protection policies on mobile to protect data even on BYOD (e.g., prevent copy/paste to personal apps).

Now access isn’t just “do you know the password”; it’s “are you the right person, on a healthy device, in a sane context”.

Step 4: Harden the Data Layer in Microsoft 365

Zero Trust isn’t only about logins and devices; it’s about what happens to data once access is granted. In Microsoft 365, that means bringing SharePoint, OneDrive, and Teams into the model.

4.1 Tidy Up Sharing Defaults

• Set organisation-wide sharing defaults to match your risk appetite. For most SMBs: “New and existing guests” or “Existing guests only” is reasonable; avoid “Anyone” globally.
• Disable anonymous sharing on sensitive sites (HR, Finance, Exec) via site-level policies.
• Enable expiration dates on sharing links so forgotten links don’t linger forever.

Talk to business owners before tightening sharing. They’ll usually support stronger defaults if they know links will still work for external partners with proper accounts.

4.2 Introduce Simple Sensitivity Labels

Start small. Create a three-tier model:

• Public – Can be shared externally, low risk.
• Internal – For staff only; external sharing blocked or restricted.
• Confidential – Strongest controls: restricted sharing, watermarking, and maybe encryption.

Apply these as sensitivity labels to documents and emails. Over time, add auto-labelling rules for obvious patterns (payroll files, national IDs, etc.), but don’t wait for perfect classification before rolling out.

Step 5: Build a Minimal but Effective Monitoring Loop

Zero Trust isn’t a one-off project. You need feedback on what’s happening so you can refine policies without flying blind. You don’t need a full SOC on day one, but you do need a basic, repeatable review process.

5.1 Turn On the Right Logs

• Enable and retain sign-in logs and audit logs in Entra ID.
• In Defender for Endpoint, enable EDR in block mode and at least basic alerting.
• For larger estates, stream logs to a Log Analytics workspace and use Microsoft Sentinel or another SIEM as you mature.

Agree internally how long you need to keep logs for incident response. 30 days is rarely enough; aim for at least 90–180 days where possible.

5.2 Run a Monthly Security Health Check

Create a simple, recurring checklist you review every month:

• New risky sign-in patterns or impossible travel spikes.
• Users repeatedly failing MFA or triggering lockouts.
• Devices falling out of compliance (encryption off, AV disabled, outdated OS).
• New external sharing patterns or unusually large data movements.

Capture these in a short internal report with one or two actions each month. Incremental improvements beat big-bang “security programmes” that never land.

Where to Start This Month

Most organisations don’t fail on Zero Trust because the model is wrong; they fail because they try to do everything at once. Focus on a small, high-impact starter set and build from there.

If you do nothing else this month, do this:

• Inventory and reduce Global Admins, and create proper break-glass accounts.
• Enable Conditional Access with MFA for all users and block legacy auth (in report-only first, then enforce).
• Enroll your core Windows fleet into Intune and enforce encryption + AV as compliance.

Once those three are stable, you’ll have a solid Zero Trust baseline for Microsoft 365 and Azure that you can confidently extend, rather than constantly firefighting around it.