Building a Practical Zero Trust Strategy in 2026: What to Do First and What Actually Works
[For IT Pros]
Zero Trust is no longer a slide in a strategy deck — by 2026 it’s the baseline expectation from auditors, cyber insurers, and your board. The problem is, most organisations still treat it like a massive, abstract project instead of a series of small, very concrete security upgrades.
I’ll walk you through how I’d roll out Zero Trust today in a mid-sized Microsoft 365 / Azure environment: what to prioritise, what to ignore for now, and the exact types of policies, checks, and automation that make a real difference.
1. Start with an Honest Zero Trust Baseline (30–60 minutes)
Before adding more tools, you need a clear view of where you are. In 2026, the fastest way to get a practical baseline in a Microsoft-centric shop is to combine Entra (Azure AD) insights with your endpoint and network reality.
1.1 Map Identities, Devices, and Data – Not Just Servers
Zero Trust revolves around three things: who (identities), what (devices), and where (data and apps). Forget the old "inside vs outside" network mindset.
- Identities: Pull a list of all Entra ID accounts (users, guests, service principals, managed identities). Highlight:
- Global Admins and other privileged roles
- Guest accounts with high-risk access (SharePoint, Teams, confidential apps)
- Legacy auth usage (POP/IMAP/SMTP, basic auth to Exchange or custom apps)
- Devices: Check which devices are actually managed (Intune, ConfigMgr co-management, third-party MDM) vs completely unknown. Pay attention to:
- BYOD phones accessing corporate email or Teams
- Contractor laptops that never see your VPN
- Data & Apps: Identify your top 10 critical apps and data locations:
- Line-of-business apps (cloud and on-prem)
- M365 workloads (SharePoint sites with sensitive content, key Teams, Exchange mailboxes)
- Any public-facing APIs or portals
In Entra, the Identity Protection blade and Sign-in logs will already show risky sign-ins, legacy auth usage, and where enforcement will hurt the most. Screenshot and annotate those views — they’re gold when you need to explain Zero Trust decisions to leadership.
1.2 A Simple Zero Trust Maturity Snapshot
Don’t overcomplicate the assessment. Use a quick 0–2 scale for each pillar:
- Identity
- 0 = No enforced MFA, shared accounts, legacy auth everywhere
- 1 = MFA for admins and some users, some conditional access
- 2 = MFA/strong auth enforced for everyone, CA is baseline and risk-based
- Devices
- 0 = Users access from anything, no compliance checks
- 1 = Corporate devices mostly managed, BYOD unmanaged
- 2 = Clear policies: corporate = compliant, BYOD = app/container restricted
- Data & Apps
- 0 = Flat access, no classification, excessive sharing
- 1 = Some sensitivity labels and basic sharing controls
- 2 = Classification enforced, access scoped by role, just-in-time elevation
This gives you a one-page story: "We’re Identity = 1, Devices = 0, Data = 0.5". From there you can prioritise actions instead of chasing buzzwords.
2. Identity First: Conditional Access That Actually Protects You
If you only have the time and budget for one Zero Trust pillar this quarter, fix identity and access. In Microsoft 365/Entra environments, that means solid Conditional Access, strong authentication, and minimal standing privileges.
2.1 Baseline Conditional Access Policies for 2026
These are the core policies I deploy in almost every tenant, adjusted for risk appetite. Use the built-in templates as a starting point, but don’t stop there.
- Policy 1: Require MFA for all users
- Assignments: All users (exclude break-glass accounts)
- Cloud apps: All cloud apps
- Conditions: Include all locations, all device platforms
- Grant: Require multifactor authentication
- Session: Sign-in frequency 12–24 hours, persistent browser session off for sensitive tenants
- Policy 2: Block legacy authentication
- Assignments: All users
- Client apps: Other clients (legacy authentication)
- Grant: Block access
- Monitor in Report-only for 1–2 weeks, then enforce.
- Policy 3: Protect privileged accounts
- Users: Administrative roles (Global Admin, Privileged Role Admin, etc.)
- Conditions: Sign-in risk >= medium OR device not compliant OR location not trusted
- Grant: Require compliant device + strong auth (MFA or phishing-resistant credentials)
- Policy 4: Restrict high-risk sign-ins everywhere
- Users: All
- Conditions: Sign-in risk = high
- Grant: Block access
Use Report-only and the What If tool heavily before enforcing. In 2026, most outages I see are from rushed CA rollouts, not attackers.
2.2 Phishing-resistant Authentication Where It Matters
Email-based MFA and SMS codes are table stakes, but not good enough against modern phishing kits and adversary-in-the-middle attacks. For critical roles and sensitive apps, move to phishing-resistant methods.
- FIDO2 security keys (e.g., YubiKey, Feitian) for admins, finance, and executives.
- Passkeys integrated with device biometrics on Windows 11/12, macOS, Android, and iOS.
- Entra ID certificate-based auth for highly regulated environments.
Roll this out in waves. Start with Global Admins and anyone who approves large financial transactions. Then make it the default for all admins and developers with prod access.
2.3 Remove Standing Privileges with PIM
Zero Trust hates permanent access. If you haven’t fully embraced Privileged Identity Management (PIM) yet, this is your quick win.
- Make admin roles eligible, not permanent.
- Require approval and justification for high-impact roles.
- Use conditional access + PIM: e.g. "Global Admin must activate via PIM, use FIDO2, and be on a compliant device".
- Review PIM logs monthly with your security team.
This single change drastically reduces the blast radius of compromised accounts and gives you a clear audit trail for incidents.
3. Device Trust and Access: Stop Treating All Endpoints the Same
In 2026, users access corporate data from corporate laptops, home PCs, phones, tablets, thin clients, and random contractor machines. Zero Trust means acknowledging they are not equal and enforcing that in your policies.
3.1 Define Your Device Trust Model in One Page
Keep it simple: define three categories and how they’re allowed to interact with your environment.
- Corporate Managed
- Enrolled and compliant via Intune or other MDM
- Full access to corporate resources, subject to CA and risk
- BYOD / Semi-Trusted
- Not fully managed; at best, app-level management
- Allowed limited access via browser or protected apps (e.g., Outlook, Teams with App Protection Policies)
- Untrusted
- No management, no controls
- Only allowed to access low-risk apps, or blocked completely
Once this is written down and agreed with stakeholders, you can codify it into Conditional Access and Intune policies.
3.2 Conditional Access Examples for Device State
In Entra, use the Device platform, Device state, and Filter for devices conditions to enforce your model.
- Policy: Only compliant devices can access high-value apps
- Users: All
- Cloud apps: Finance apps, HR apps, Admin portals, GitHub Enterprise if federated, etc.
- Conditions: Device state = Require Hybrid Azure AD joined or marked as compliant
- Grant: Require device to be marked as compliant + MFA
- Policy: BYOD limited to web and protected apps
- Users: All or specific groups
- Cloud apps: Exchange Online, SharePoint, Teams
- Conditions: Device not compliant or not hybrid-joined
- Grant: Require approved client app and app protection policy
- Session: Use sign-in frequency, block persistent browser sessions, enable continuous access evaluation
This is where traditional VPN-based thinking breaks: you’re controlling access per app, per device state, not just “on VPN = trusted”.
3.3 Intune Compliance That’s Strict but Realistic
Compliance policies should reflect your real risk, not a fantasy baseline you’ll never consistently meet.
- Minimum standards you should enforce on corporate devices in 2026:
- BitLocker (or FileVault on macOS) enabled with escrowed keys
- OS version above a defined minimum (e.g., Windows 11 24H2+, macOS Sonoma+)
- Endpoint protection enabled and reporting (Defender for Endpoint or equivalent)
- Secure boot and TPM (where hardware supports it)
- Use remediation scripts in Intune to auto-fix easy issues (e.g., enabling BitLocker, local firewall).
- Use device compliance state in Conditional Access as a first-class condition, not an afterthought.
Don’t forget onboarding: wire this into Autopilot or your imaging flow, not as a bolt-on months later.
4. Data and App Access: Least Privilege Without Killing Productivity
You can’t implement Zero Trust purely with identity and device checks. The last piece is making sure sensitive data and critical apps are only accessible by the right people, with just enough access, for just long enough.
4.1 Segment by Business Criticality, Not Just Network
Think in terms of business impact, not VLANs. Define tiers for your cloud apps and data:
- Tier 0: Identity and control plane (Entra, domain controllers, Azure management, key vaults)
- Tier 1: Mission-critical apps (ERP, core line-of-business, payment systems)
- Tier 2: Important but not life-or-death apps (departmental tools, Intranet)
- Tier 3: Low-risk, wide-access apps (training portals, general info)
Map each tier to stronger or weaker access control combinations. Example: Tier 0 requires PIM + compliant device + phishing-resistant auth; Tier 3 may allow browser-only access from non-compliant endpoints.
4.2 Use Entra ID App Collections and CA to Enforce Tiers
Group applications logically so you can protect them consistently.
- Create security groups or Entra ID enterprise app collections representing each tier.
- Apply CA policies to those groups instead of per-app one-offs.
- For Tier 0 and Tier 1, require:
- Phishing-resistant auth for admins
- Compliant or hybrid-joined devices
- Block access from high-risk sign-ins and risky IPs
This approach reduces policy sprawl and makes audits and troubleshooting easier.
4.3 Just-in-Time and Just-Enough-Access for Sensitive Operations
Moving from static roles to just-in-time (JIT) and just-enough-access (JEA) is where Zero Trust starts to pay dividends.
- PIM for app roles: Make high-privilege app roles (e.g., Exchange admin, SharePoint admin, application owner) eligible with an approval workflow.
- JEA for servers (if you still run Windows Server):
- Use PowerShell JEA endpoints so admins can only run approved commands.
- Integrate access to these endpoints with Entra ID groups managed by PIM.
- Access reviews: Schedule quarterly access reviews for critical apps and Teams/SharePoint sites with sensitive data.
The aim is to make "temporary, auditable access" the norm and "permanent admin" the rare exception you have to justify.
5. Monitoring, Incident Signals, and Automation: Making Zero Trust Sustainable
Zero Trust isn’t a set of static policies; it’s an ongoing feedback loop. If you don’t watch what’s happening and adjust, you’ll either strangle the business or leave big gaps.
5.1 Core Signals You Should Be Watching in 2026
Whether you use Microsoft Sentinel, another SIEM, or a custom setup, there are some core Entra and endpoint signals you should ingest and alert on.
- Identity-related:
- Impossible travel and atypical locations (Entra risk events)
- Multiple MFA failures followed by success
- New consent grants to high-privilege OAuth apps
- Creation of new Global Admins or role assignments in PIM
- Device-related:
- Devices flipping from compliant to non-compliant in Intune
- Defender for Endpoint high/critical alerts
- New devices accessing high-value apps for the first time
- Data-related:
- Mass downloads from SharePoint/OneDrive by a single user
- New anonymous or "anyone with the link" sharing on sensitive sites
Make sure these are not just logged but tied to an incident response workflow (even a simple one) and tagged to owners.
5.2 Automate the Boring but Critical Responses
Use Power Automate, Logic Apps, or n8n to handle the repetitive reactions so your team can focus on analysis.
- Example: High-risk sign-in automation
- Trigger: High-risk sign-in detected for a user
- Actions:
- Force password reset or revoke refresh tokens via Graph API
- Temporarily move user into a restricted group with tighter CA
- Create an incident ticket and notify security on Teams
- Example: New Global Admin alert
- Trigger: Role assignment event in Entra audit logs
- Actions:
- Validate if the change came from PIM with approval
- If not, flag as incident, optionally auto-remove the assignment
As you mature, you can add more advanced playbooks (e.g., auto-isolate devices via Defender, adjust CA based on live risk scores), but start small and reliable.
5.3 Keep a Living Zero Trust Runbook
Document your Zero Trust controls in a way your on-call engineer at 2am can actually use:
- Where Conditional Access policies live, what they protect, and known exceptions.
- How to safely disable or bypass a policy in an emergency (with approvals).
- Which signals trigger which playbooks, and how to override them if needed.
- Contact points for security, identity, network, and app owners.
Update this every time you change core policies. Treat it like code: version it in Git, review it regularly, and avoid undocumented “hotfix” changes to production policies.
One Clear Next Step: Fix Identity This Month
Zero Trust can feel overwhelming because it touches everything. Instead of trying to "do Zero Trust" as a grand project, commit to one concrete win this month: bring your identity layer up to a modern baseline.
- Implement tenant-wide MFA with smart Conditional Access.
- Block legacy authentication after a short report-only period.
- Move admin accounts into PIM with just-in-time elevation.
Once that’s stable, move on to enforcing device compliance and segmenting your critical apps. Zero Trust becomes manageable when you treat it as a sequence of very specific, testable improvements — not a vague security dream.