What Zero Trust Actually Means in Azure
Zero Trust is a security model built on one principle: never trust, always verify. Instead of assuming everything inside your network perimeter is safe, Zero Trust assumes breach and verifies every access request explicitly — regardless of where it comes from.
In traditional perimeter-based security, once a user or device is inside the network they're largely trusted. In a Zero Trust model, trust is never implicit. Every request is authenticated, authorised, and continuously validated against policy before access is granted.
Microsoft's Azure implementation of Zero Trust sits across three pillars:
- Verify explicitly — authenticate and authorise based on all available data: identity, location, device health, service, workload, and data classification
- Use least privilege access — limit user access with just-in-time and just-enough-access policies
- Assume breach — minimise blast radius, segment access, encrypt end-to-end, and use analytics to detect threats
Zero Trust is not a single product you buy or a checkbox you tick. It's an architecture you build incrementally. This guide covers the network layer — securing how users and devices access Azure resources. Identity, data, and application Zero Trust layers are separate workstreams covered in future articles.
The Zero Trust Network Architecture in Azure
A Zero Trust network in Azure replaces the traditional VPN model — where users connect to a network and then access resources — with a model where users connect directly to specific applications and resources, verified at every step.
Prerequisites Before You Start
Before implementing Zero Trust network access in Azure, confirm you have these in place:
- Microsoft Entra ID P1 or P2 licence — required for Conditional Access. P2 adds Identity Protection and risk-based policies. Most E3/E5 licences include P1 or P2.
- Entra ID as your identity provider — either cloud-only or hybrid-synced from on-premises Active Directory via Entra Connect
- Microsoft Intune or equivalent MDM — needed for device compliance policies used in Conditional Access rules
- Azure subscription with Contributor or Owner role — to configure network resources
Step-by-Step Implementation
Enable Multi-Factor Authentication for All Users
This is the single highest-impact security control you can implement. Before anything else, enforce MFA across your entire organisation. In the Entra admin portal go to Protection → Conditional Access → Policies and enable the built-in Require MFA for all users baseline policy, or create a custom policy targeting all users and all cloud apps requiring MFA as a grant control.
- Use the Microsoft Authenticator app as the primary MFA method — it's more phishing-resistant than SMS
- Enable number matching in Authenticator to prevent MFA fatigue attacks
- Exclude break-glass emergency access accounts from MFA policies
Enrol Devices into Intune and Enforce Compliance
Zero Trust requires knowing the health of devices before granting access. Enrol all corporate devices into Microsoft Intune and create compliance policies that define what a healthy device looks like — minimum OS version, disk encryption enabled, no jailbreak/root, antivirus up to date.
- In Intune, go to Devices → Compliance policies → Create policy
- Define compliance requirements for Windows, macOS, iOS, and Android separately
- Set a grace period (typically 3–7 days) for devices to become compliant before access is blocked
- Use Entra hybrid join for on-premises domain-joined devices you can't fully manage through Intune
Build Your Conditional Access Policy Framework
Conditional Access is the policy engine of Zero Trust. It evaluates every access request against your defined conditions and either grants access, blocks access, or grants access with additional controls like MFA or compliant device requirement.
A solid baseline Conditional Access framework for Azure includes these policies:
- Require MFA for all users — the foundation, no exceptions except break-glass accounts
- Require compliant device for Azure management — anyone accessing the Azure portal, CLI, or ARM APIs must be on a compliant device
- Block legacy authentication protocols — SMTP, POP3, IMAP, and older Office protocols don't support MFA; block them entirely
- Require MFA for risky sign-ins — use Entra Identity Protection risk signals to require step-up auth when anomalous behaviour is detected
- Block access from high-risk locations — block sign-ins from countries your organisation never operates in
Always run new Conditional Access policies in Report-only mode for 1–2 weeks before enforcing them. This lets you see exactly which users and sign-ins would be affected without locking anyone out. Skipping this step is the fastest way to generate a P1 incident at 2am.
Replace VPN with Microsoft Entra Private Access (ZTNA)
Traditional VPNs grant broad network access — once connected, users can reach anything on the network. Microsoft Entra Private Access (part of Microsoft's Security Service Edge) replaces VPN with application-specific access. Users connect to specific apps, not to the whole network.
- In the Entra admin portal, go to Global Secure Access → Applications → Enterprise applications
- Create a new Quick Access application and define the private resources (IP ranges, FQDNs, ports) users need to reach
- Install the Global Secure Access client on endpoints — this replaces the VPN client
- Assign the application to users or groups through Entra ID
- Apply a Conditional Access policy to the application requiring MFA + compliant device
Implement Network Segmentation with Azure Firewall
Zero Trust at the identity layer is not enough on its own — you also need network-level controls to prevent lateral movement if an account is compromised. Deploy Azure Firewall in a hub VNet and use User Defined Routes to force all spoke-to-spoke and internet-bound traffic through it.
- See our Azure Firewall vs NSGs guide for the full firewall deployment architecture
- Create Azure Firewall application rules that allow only specific FQDNs for outbound internet access
- Use Firewall Policy to centralise rule management across multiple Azure Firewall instances
- Enable threat intelligence in deny mode to block known malicious IPs and domains
Enable Continuous Access Evaluation
Standard OAuth tokens are valid for up to an hour — meaning a compromised token can be used for up to 60 minutes even after you revoke a user's access. Continuous Access Evaluation (CAE) fixes this by enabling near real-time token revocation. When you disable an account, change their location policy, or detect a risky event, access is revoked within minutes rather than hours.
- CAE is enabled by default for Microsoft 365 and Azure services — verify it's active in Entra → Protection → Continuous Access Evaluation
- For custom applications, implement CAE support in your application code using the Microsoft Identity platform SDK
Monitor with Microsoft Sentinel
Zero Trust is not a set-and-forget configuration. You need continuous monitoring to detect policy violations, suspicious sign-ins, and lateral movement attempts. Connect Microsoft Sentinel to your Entra ID, Azure Firewall, and NSG Flow Logs to get a unified view of your Zero Trust posture.
- Enable the Microsoft Entra ID data connector in Sentinel to ingest sign-in and audit logs
- Enable the Azure Firewall data connector for network traffic analysis
- Use the built-in Zero Trust workbook in Sentinel to track policy compliance across your environment
- Create analytic rules to alert on Conditional Access policy failures, impossible travel events, and new admin role assignments
Common Zero Trust Implementation Mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Enforcing CA policies without Report-only testing first | Locking out users, breaking service accounts | Always run Report-only for 1–2 weeks before enforcing |
| No break-glass emergency access accounts | Complete lockout if something goes wrong with CA policies | Create 2 break-glass accounts excluded from all CA policies, store credentials securely |
| Not blocking legacy authentication | Attackers bypass MFA via legacy protocols that don't support it | Create a CA policy blocking all legacy auth protocols immediately |
| Treating Zero Trust as a one-time project | Policies drift, new gaps emerge, monitoring lapses | Schedule quarterly Zero Trust posture reviews |
| Replacing VPN with ZTNA but keeping broad network access via NSGs | Network-level lateral movement still possible even after identity controls | Segment networks and tighten NSGs alongside ZTNA deployment |
Zero Trust Maturity Model
Zero Trust implementation is a journey, not a destination. Microsoft's Zero Trust Maturity Model defines three stages. Use this to benchmark where you are and what to tackle next:
| Stage | Network | Identity | Devices |
|---|---|---|---|
| Traditional | Open flat network, VPN access | Password only, no MFA | Unmanaged, no compliance checks |
| Advanced | Segmented VNets, NSGs, Azure Firewall | MFA enforced, Conditional Access | MDM enrolled, compliance required |
| Optimal | ZTNA replaces VPN, micro-segmentation | Risk-based CA, CAE, passwordless | Full device health telemetry, auto-remediation |
What to remember from this article
- →MFA first — enforce it for all users before anything else, it's the highest ROI control you have
- →Always test Conditional Access in Report-only mode before enforcing — skipping this causes outages
- →Block legacy authentication protocols immediately — they completely bypass MFA
- →ZTNA replaces VPN but doesn't replace network controls — NSGs and Azure Firewall are still required
- →Continuous Access Evaluation closes the token revocation gap — enable it for near-real-time policy enforcement
- →Monitor continuously — Zero Trust is an ongoing posture, not a one-time deployment