Why Zero Trust Is No Longer Optional – A Field Perspective

I’ve been working with Microsoft environments for over 15 years. In that time, I’ve seen a lot of security models come and go. Zero Trust isn’t one of them – it’s the one that’s finally sticking. And if you’re still not taking it seriously, this post is for you.

The old model is broken – and attackers know it

For years, the dominant security philosophy was simple: build a strong perimeter, and trust everything inside it. Firewalls, VPNs, network segmentation – the idea was that if you kept the bad guys out, you were safe.

The problem? That model assumes attackers will politely knock on the front door. They don’t. Modern attacks go after identities. They phish your users, steal OAuth tokens, abuse over-permissioned service accounts, and move laterally – all without ever triggering a traditional perimeter alert. By the time you notice something is wrong, they’ve been inside for weeks.

The numbers are sobering. In 2025, data compromises hit a new all-time record – over 3,300 tracked incidents, a 79% jump compared to five years ago ^{[ITRC 2025 Annual Data Breach Report]}. The vast majority trace back to identity compromise, not firewall bypass. Credential phishing, adversary-in-the-middle (AiTM) proxy attacks, and token theft have replaced port scanning as the attacker’s entry method of choice.

I see this pattern regularly in the field. Organisations with solid perimeter defences but weak identity hygiene. No MFA on admin accounts. Service accounts with Global Administrator rights that haven’t been reviewed in years. Conditional Access policies that were set up during an M365 migration and never touched again. It’s not negligence – it’s the legacy of a security model that used to work and quietly stopped.

What Zero Trust actually means

Zero Trust gets thrown around a lot as a buzzword. It’s worth being precise about what it actually means – and what it doesn’t.

At its core, Zero Trust is built on three principles:

Verify explicitly. Every access request is authenticated and authorised based on all available signals – identity, device compliance state, IP location, sign-in risk score, and session behaviour. Not once at login, but continuously throughout the session.
Use least privilege access. Users and workloads get only the access they need, for exactly as long as they need it. Just-in-time (JIT) and just-enough-access (JEA) are the implementation patterns here.
Assume breach. Design your controls with the expectation that an attacker is already operating inside the environment. Segment aggressively, limit blast radius, and invest in detection and response – not just prevention.

What Zero Trust is not is a product you can buy. It’s an architectural philosophy. You can’t install Zero Trust – you implement it, gradually, across your identity, devices, applications, data, and network layers. Microsoft maps this to six technology pillars: Identity, Endpoints, Applications, Data, Infrastructure, and Network.

Where Microsoft fits in – and where to start

If your organisation runs on Microsoft 365 and Azure, you’re in a good position. Microsoft has built Zero Trust deeply into their stack – and the tooling is already there in your tenant, often underused.

The most impactful starting point, in my experience, is always Conditional Access in Microsoft Entra ID. This is Microsoft’s Zero Trust policy engine. It evaluates signals in real time – user identity and role, device compliance state (via Intune), named location or IP range, sign-in risk score from Entra ID Protection, and application sensitivity – before issuing an access decision: allow, require step-up MFA, require compliant device, limit session, or block.

A solid Conditional Access baseline I recommend to almost every client:

Require MFA for all users – no exceptions for “it’s too inconvenient.” Target all cloud apps, all users, exclude only break-glass accounts.
Block legacy authentication protocols – IMAP, POP3, SMTP AUTH, and basic auth bypass MFA entirely. Block them at the Conditional Access layer, not just at the application level.
Require compliant or Hybrid Azure AD joined devices for access to sensitive applications. If the device isn’t managed and reporting a healthy compliance state to Intune, it should not be touching your data.
Restrict privileged roles with PIM – Global Admin, Exchange Admin, Security Admin and equivalent roles should require Privileged Identity Management (PIM) activation, be time-bound (e.g. 8 hours max), and trigger MFA on every elevation – not just on initial login.
Enable user and sign-in risk policies – Entra ID Protection scores sign-in events in real time. Anomalous patterns (impossible travel, atypical location, leaked credentials, anonymous IP) should trigger automatic step-up or block. Requires Entra ID P2.

The MFA conversation you need to have – phishing-resistant is the real upgrade

Most organisations, when they finally roll out MFA, reach for the Microsoft Authenticator app with push notifications. It’s better than nothing – a lot better – but it’s not the end of the story.

Adversary-in-the-middle (AiTM) attacks have made traditional MFA push notifications increasingly unreliable as a sole control. In an AiTM attack, the attacker proxies the authentication flow in real time – your user enters their credentials and approves the MFA push, and the attacker simultaneously relays that to Microsoft and captures a valid session token. The MFA was satisfied. The attacker is in. Tools like Evilginx2 have made this trivially accessible to low-skilled threat actors.

This is where phishing-resistant MFA becomes a major upgrade. Phishing-resistant MFA methods are cryptographically bound to the specific origin (domain) of the authentication request – which means an AiTM proxy can’t relay them, because the credential is only valid for the legitimate endpoint.

Microsoft supports two phishing-resistant methods in Entra ID:

FIDO2 security keys (passkeys) – hardware tokens (YubiKey, Feitian, etc.) or device-bound passkeys. Authentication is based on a public/private key pair that is cryptographically tied to the relying party. The private key never leaves the device. Cannot be phished, cannot be proxied.
Windows Hello for Business – certificate or key-based authentication tied to a specific Windows device and user. Strong, seamless, and available at no additional licence cost if you’re already on Entra ID P1 and Intune.
Microsoft Authenticator with number matching + additional context – not fully phishing-resistant, but number matching (where the user must type a number shown on screen rather than just tapping approve) significantly reduces MFA fatigue attacks and accidental approvals. This should be the minimum configuration for Authenticator-based MFA.

In Conditional Access, you can enforce phishing-resistant MFA specifically for your most sensitive access scenarios – privileged admin roles, access to financial or HR applications, or any scenario where a compromised session would have significant impact. This is done via Authentication Strengths, a Conditional Access feature that lets you specify the exact MFA methods acceptable for a given policy.

My recommendation: deploy Authenticator with number matching as the baseline for all users, and enforce FIDO2 or Windows Hello for Business for all privileged identities. It’s a meaningful step up in security posture and, in my experience, far less disruptive to roll out than most people expect.

The practical challenge: Zero Trust without breaking the business

Zero Trust implementation, if done clumsily, will generate a flood of helpdesk tickets and frustrated users. I’ve seen it happen – overly aggressive Conditional Access policies that block legitimate users in edge cases, MFA fatigue attacks on accounts that had push-only MFA configured, PIM setups so complex that admins work around them with standing access anyway.

A phased, structured approach works better:

Start in report-only mode. Every Conditional Access policy can be set to Report-only before enforcement. Run it for 2-4 weeks. Review the sign-in logs in Entra ID (under Monitoring – Sign-in logs, filter by CA policy name). Identify legitimate users or scenarios that would have been blocked. Fix before you flip to enabled.
Exclude break-glass accounts. Always maintain at least two emergency access accounts that are excluded from all Conditional Access policies. These should use strong passwords, FIDO2 keys ideally, and be monitored via an alert on any sign-in. Store credentials in a physical vault.
Use named locations correctly. Trusted IP ranges (office networks, VPN exit nodes) can be used to reduce MFA friction for managed scenarios – but don’t use location as a substitute for device compliance. Location is a soft signal; device compliance is a hard one.
Review regularly. Conditional Access policies are not set-and-forget. New applications get added to the tenant, user roles change, guest access patterns shift. A quarterly review of your CA policy set is the minimum. I’d recommend monthly for the first year post-deployment.

Zero Trust is a journey, not a destination

Microsoft’s own documentation puts it well: Zero Trust adoption is a gradual, long-term effort. Every organisation starts from a different place. The goal isn’t perfection on day one – it’s consistent forward movement across the six pillars.

In practice, I always start with Identity – get Conditional Access right, enforce phishing-resistant MFA for privileged accounts, clean up stale guest identities and over-permissioned roles. That alone meaningfully reduces your attack surface before you’ve touched Defender XDR, Intune, or data classification.

Identity is the control plane for everything else. Get that right first, and the rest of the Zero Trust journey becomes significantly easier to execute.

If you’re not sure where your organisation stands, a security posture assessment is a good starting point – not to produce a report that sits on a shelf, but to deliver a prioritised, actionable roadmap tied to your actual risk profile and existing Microsoft licensing.

Karel Dehertogh is an independent Microsoft cloud consultant specialising in Azure, Microsoft 365, and enterprise security. He helps organisations design and implement security that actually works in practice – not just on paper. Want to talk through your Zero Trust posture? Get in touch.