Zero Trust

Zero Trust is the security model where every access request is verified explicitly based on user, device, location, and risk signals — with no implicit trust granted by being on the corporate network. Microsoft frames it around three principles: verify explicitly (use all available signals), use least privilege (just-in-time, just-enough access), and assume breach (minimise blast radius, segment, encrypt, monitor). In Microsoft 365, zero trust is implemented through Conditional Access (the policy decision point), Intune compliance (device posture), PIM (privileged access), sensitivity labels and DLP (data protection), and Defender XDR (continuous monitoring). Not a product — an architecture realised through these tools.

What it replaces

The model zero trust displaces is often called the castle-and-moat approach: strong perimeter controls (firewall, VPN) at the network edge, with comparatively loose trust once a device or user is "inside." That model assumed the corporate network was a reliable proxy for trustworthiness — a reasonable assumption when all work happened on managed devices, on-premises, behind a firewall. It stopped holding once users routinely worked from home networks, personal devices, and SaaS apps that were never inside any perimeter to begin with; a VPN connection from an unmanaged laptop is not meaningfully more trustworthy than a direct internet connection, so treating "on the VPN" as sufficient to skip further verification stopped making sense.

Worked example

Under a perimeter model, a user connects to the corporate VPN and from there has broad access to file shares and internal apps with no further check — the VPN connection itself was the trust boundary. Under a zero-trust model built on Microsoft 365, that same user's access to, say, a finance SharePoint site is evaluated independently of network location: Conditional Access checks whether the sign-in risk is acceptable, whether the device is Intune-enrolled and compliant, and whether the user is a member of the finance group; a sensitivity label on the site itself may further restrict what can be downloaded or shared externally regardless of how the user connected. The practical difference: a compromised VPN credential used from an unmanaged device gets blocked by the device-compliance check, where a perimeter model would have granted broad access on the strength of the VPN connection alone.

The three principles in practice

Verify explicitly shows up as Conditional Access evaluating identity, device, location, and risk on every access request rather than once at a session's start. Least privilege shows up as PIM's just-in-time role activation and Entra Entitlement Management's time-bound access packages, replacing standing broad grants with narrow, expiring ones. Assume breach shows up as segmentation (sensitivity labels and DLP limiting what a compromised account can exfiltrate even after gaining access), plus Defender XDR's continuous monitoring and Continuous Access Evaluation's near-real-time token revocation, which together shorten how long a successful compromise stays useful to an attacker.

Common misunderstanding

Zero trust is frequently sold and bought as a single product to purchase, but there is no "Zero Trust" SKU — it's an architecture assembled from Entra ID, Intune, Purview, and Defender capabilities a tenant may already own without having configured them toward this end. The practical maturity question for any given tenant isn't "do we have zero trust" but "for our highest-value data and identities, is every one of the three principles actually enforced, or just nominally licensed."