Designing a Practical Zero Trust Strategy for a 200

Zero Trust sounds like a buzzword until someone clicks a phishing link, a laptop gets stolen on the Tube, or an ex-employee still has access to your CRM three months after leaving. For a 200–500 user organisation, these are not theoretical problems — they’re weekly risks.

This guide walks through a realistic Zero Trust approach you can actually implement with a small IT team, using modern cloud tools like Microsoft 365, Azure AD (Entra ID), and Intune. No huge budgets, no massive re-platform overnight — just structured, staged improvements.

What Zero Trust Really Means for a Mid-Sized Business

Ignore the hype. Zero Trust for a 200–500 user company is not a perfect, academic model. It’s a set of decisions that ensure:

No user or device is trusted by default, even if they’re on your “internal” network.
Access is conditional on identity, device health, location, and risk.
Access is limited to what a user actually needs to do their job.
Monitoring is continuous, with signals feeding into automated responses.

In practical terms, that means moving away from “If you’re on the VPN, you can see everything” to “You see exactly what you need, when you need it, on a trusted device, and we can revoke it quickly.”

Step 1: Start with Identity – Your New Security Perimeter

In a cloud-first world, your identity platform is your perimeter. For most organisations, that’s Microsoft Entra ID (formerly Azure AD), tied to Microsoft 365.

1.1 Hardening Basic Identity Hygiene

Before fancy controls, you need identity basics locked down. At a minimum:

MFA Everywhere: Require MFA for all users, not just admins. Use Authenticator app or FIDO2 keys. Block SMS where possible.
Disable legacy auth: Block POP/IMAP/SMTP Basic. Legacy protocols bypass Conditional Access and MFA.
Privileged roles: Use Privileged Identity Management (PIM) for Global/Exchange/SharePoint admins. No one should be a permanent global admin.
Password hygiene: Shorter lifetimes don’t fix bad passwords. Use longer passphrases and ban common and breached passwords.

If you only did this step properly, you’d already remove a large chunk of easy attack paths.

1.2 Conditional Access as Your First Zero Trust Control

Conditional Access is where you start enforcing Zero Trust in a way users actually feel. Core policies for a 200–500 user environment:

Require MFA for all cloud apps, excluding a very small emergency break-glass account.
Block access from unsupported countries (anywhere you don’t have staff or partners).
Block unknown / unmanaged devices from accessing sensitive apps like SharePoint Admin, Azure Portal, finance systems.
Require compliant or hybrid-joined devices for key workloads (Exchange Online, SharePoint, Teams).

Roll these in report-only mode first, watch the impact, then enforce. This avoids dramatic surprises on Monday mornings.

Step 2: Make Devices First-Class Citizens (Not Afterthoughts)

Zero Trust without device strategy is wishful thinking. If you don’t know the health of a device, you can’t safely trust the session coming from it.

2.1 Standardise Device Enrollment

For Windows and macOS, decide on a single, standard way devices enter your environment:

Windows: Use Autopilot + Intune for new devices, and hybrid join only if you still rely on on-prem Group Policy.
macOS: Use ABM/ASM + Intune or a dedicated MDM. Avoid “IT-managed” Macs that are really just local admin free-for-alls.
BYOD policy: Decide explicitly what’s allowed. If personal devices are in scope, use app protection policies rather than full device management.

The goal: any device used for corporate work is known, enrolled, and manageable.

2.2 Build Minimum Viable Compliance Policies

Zero Trust isn’t about perfection — it’s about a reasonable baseline that you enforce consistently. Good starting controls:

OS version minimum (e.g. Windows 10 22H2+, macOS n-1).
Disk encryption required (BitLocker, FileVault).
Endpoint protection enabled (Defender or your chosen AV).
Screen lock + password with sensible timeouts.

Tie these to Conditional Access: Only compliant devices can access core apps. Non-compliant devices can see a portal with guidance, not the business data.

2.3 Protect Endpoints as if They Will Be Breached

Assume at some point, malware runs or credentials are stolen on a real machine. Prepare for that:

Enable Defender for Endpoint (if you have it) and integrate it with Conditional Access via device risk signals.
Block local admin for standard users. Use just-in-time elevation (e.g. Endpoint Privilege Management or similar).
Standardise application allow/deny policies where realistic (e.g. block unsigned PowerShell for non-admins).

This reduces the blast radius when, not if, something slips through email filters or web proxies.

Step 3: Move from “Flat” Access to Least Privilege

Most mid-sized companies still operate with overly broad access. One shared drive for “Everyone”, a few over-privileged admins, and customer data sprayed all over personal OneDrives.

3.1 Map Your Critical Assets and User Groups

You don’t need a 200-page data catalogue. Start small:

List your top 10 critical systems (finance, CRM, HR, production, etc.).
Identify who really needs access to each (role-based, not person-based).
Check how access is currently granted (AD group, Azure AD group, app-native roles, random shares).

This gives you a concrete view of where you’re exposed: “Finance shared folder is open to Domain Users” or “All project data lives in a single Teams site.”

3.2 Switch to Role-Based Access Using Groups

For Microsoft 365 and Azure, groups are your friend:

Create role-based security groups (e.g. Finance-AP, Finance-AR, HR-Core, Sales-UK).
Grant access to apps, SharePoint, and file shares via these groups, not individuals.
Use dynamic groups where possible (e.g. based on department in Entra ID).

Over time, this reduces the chaos of one-off permissions and makes audits much less painful.

3.3 Implement Just-in-Time Admin Access

Standing admin rights are an open invitation. Move critical roles to just-in-time access:

Use PIM for Azure AD roles and Azure RBAC. Admins activate roles when needed, with justification and optional approvals.
Apply time-bound access to highly sensitive data (e.g. investigations, M&A folders).
Regularly review active assignments and remove anything that looks like permanent admin access without reason.

This closes the window of opportunity if an admin account is compromised.

Step 4: Treat the Network as Untrusted (Even the Office LAN)

Zero Trust is often misread as “kill the network”. In reality, you still care about networks — you just don’t rely on them as your primary trust signal.

4.1 Simplify and Segment

For a typical 200–500 user office, you don’t need 20 VLANs. You do need basic segmentation:

Separate user, server, and guest networks as a minimum.
Limit east–west traffic between servers and from user VLANs to server VLANs.
Use WiFi with 802.1X where feasible and retire the “shared WPA2 password forever” model.

The idea is to prevent a compromised laptop from chewing through your internal environment unchecked.

4.2 Prefer App-Level Access Over Network-Level Access

Instead of extending your internal network via VPNs everywhere, push traffic through application-aware controls:

Publish apps securely using reverse proxies or application gateways with Entra ID auth.
Use modern VPN or ZTNA solutions that enforce device and identity posture, not just IP whitelisting.
Gradually retire legacy “full tunnel VPN gives you the whole internal subnet” approaches.

This aligns with your Conditional Access and device compliance work instead of bypassing it.

Step 5: Automate Detection and Response for the Inevitable Incidents

Zero Trust reduces risk; it doesn’t eliminate incidents. You need a repeatable way to detect and respond when something does go wrong.

5.1 Centralise Logs for Identity, Endpoint, and Key Apps

You can’t respond to what you can’t see. Aim to centralise:

Sign-in logs and audit logs from Entra ID.
Defender for Endpoint alerts and device risk signals.
Key SaaS logs (e.g. Salesforce, major line-of-business apps) where possible.

Whether you use Microsoft Sentinel or another SIEM, focus on a few high-value detections instead of trying to collect everything from day one.

5.2 Predefine Your First 3 Incident Playbooks

For a mid-sized business, you don’t need a binder of 50 runbooks. You do need clear steps for the top few scenarios:

Suspected account compromise: Disable sessions, reset credentials, revoke tokens, review sign-ins, notify user/manager.
Lost or stolen device: Remote wipe or retire, revoke sessions, check for data exfiltration, re-issue hardware.
Ransomware / malware outbreak: Isolate devices, trigger EDR actions, confirm backups, engage external IR support if needed.

Automate what you can (e.g. SOAR, Defender automated investigation), but ensure people know who decides what and when.

How to Roll This Out Without Burning Out the Team

Many Zero Trust projects stall because they try to do everything at once. For a 200–500 user organisation with a small IT team, you need a phased roadmap.

Phase 1 – Stabilise Identity and MFA (Month 1–2)

Enable tenant-wide MFA and Conditional Access in report-only, then enforce.
Disable legacy auth and lock down admin roles with PIM.
Baseline monitoring of sign-ins and risky users.

Phase 2 – Device Compliance and Core Apps (Month 2–4)

Roll out Intune-based compliance policies for Windows/macOS.
Require compliant devices for Exchange, SharePoint, Teams.
Begin endpoint hardening (AV, BitLocker/FileVault, patching standards).

Phase 3 – Access Minimisation and Network Clean-Up (Month 4–8)

Restructure access for top 10 critical systems using role-based groups.
Implement just-in-time admin for key roles.
Simplify and segment your network; review VPN architecture.

Phase 4 – Detection, Response, and Continuous Improvement (Month 6+)

Onboard key logs to your SIEM and tune priority alerts.
Document and test the first three incident playbooks.
Refine Conditional Access and device policies based on real-world events.

One Recommendation: Treat Zero Trust as an Operating Model, Not a Project

If you treat Zero Trust as a 6‑month project with a finish line, you’ll be back to firefighting within a year. Instead, build it into how you design, approve, and run everything new:

Every new app: How does it integrate with Entra ID? What Conditional Access applies?
Every new device type: How is it enrolled, made compliant, and decommissioned?
Every new vendor: What data do they see, and how is that access limited and logged?

Start small, be consistent, and review quarterly. The organisations that do this well aren’t the ones with the fanciest tools — they’re the ones that apply a simple, disciplined Zero Trust mindset to every IT decision.