The Problem with How We Talk About Zero Trust

Walk into any enterprise technology conference today and you will hear the term "Zero Trust" thrown around with alarming frequency. Vendors will tell you their firewall is Zero Trust. Their VPN replacement is Zero Trust. Their endpoint agent is Zero Trust. Buy this product, deploy it in your environment, and congratulations — you have achieved Zero Trust.

This is, to put it plainly, nonsense.

Zero Trust is not a product you can purchase. It is not a checkbox on a compliance form. It is not a feature you enable in a dashboard. Zero Trust is an architectural philosophy — a fundamental rethinking of how we design, evaluate, and enforce trust across every layer of an enterprise IT environment.

I have spent over 13 years working in IAM, Microsoft 365, endpoint management, and IT operations across enterprises in manufacturing, pharma, and technology sectors. In that time, I have seen what happens when organizations confuse purchasing a Zero Trust-branded product with actually implementing a Zero Trust architecture. The result is always the same: expensive tools that sit underutilised, security gaps that persist, and leadership teams that believe they are protected when they are not.

This article is my attempt to cut through that noise. I want to explain — practically and plainly — what Zero Trust actually means, what its three core principles demand of your architecture, and what a real-world implementation journey looks like for a mid-to-large enterprise.

Where Zero Trust Came From

The concept was first formally articulated by John Kindervag at Forrester Research in 2010. His central insight was deceptively simple: the traditional security model is broken.

The traditional model — sometimes called "castle-and-moat" — assumes that everything inside the network perimeter is trustworthy and everything outside is hostile. Once you authenticate to the VPN or cross the firewall into the corporate network, you are largely trusted. Resources on the inside treat you as a known, safe entity.

This model made reasonable sense in 1995. It makes almost no sense today.

Consider the modern enterprise reality:

• Users work from home, coffee shops, hotels, and client sites

• Applications live in Azure, AWS, SaaS platforms — not in your data centre

• Devices include personal phones, contractor laptops, and IoT sensors on the factory floor

• Attackers who compromise a single endpoint immediately begin moving laterally across a flat trusted network

• Insider threats — whether malicious or simply careless — are a persistent reality

The perimeter dissolved. The moat dried up. And yet many organisations are still designing their security architecture as if 1995 is happening right now.

Zero Trust says: stop trusting the network. Start verifying identity, device, and context — every time, for every request.

The Three Core Principles

NIST Special Publication 800-207, which is the most authoritative definition of Zero Trust Architecture, anchors the model on a set of foundational tenets. For practical purposes, I find it most useful to frame these as three core principles.

Principle 1: Verify Explicitly

Never assume. Always authenticate and authorise.

In a Zero Trust model, trust is never granted implicitly based on network location. A user sitting on your corporate LAN is not trusted simply because they are on your LAN. A service account in your data centre is not trusted simply because it is on-premises. Every access request — from every user, device, and workload — must be verified explicitly using all available signals before access is granted.

What does "all available signals" mean in practice?

• Identity: Who is making this request? Is the identity verified through strong authentication (MFA, passwordless)?

• Device health: Is the device managed? Is it compliant with your endpoint policies? Is it running current OS patches? Is CrowdStrike or Defender reporting any active threats?

• Location and network: Is this request coming from an expected geography? Is it a known IP range or an anonymising proxy?

• Application sensitivity: What resource is being accessed? Is it a low-sensitivity intranet page or a privileged admin console?

• Behaviour patterns: Does this access pattern match the user's historical behaviour? Is this an unusual time, volume, or resource?

• Session risk: Is there real-time signal of compromise during this active session?

In Microsoft's implementation — which I work with extensively — this is operationalised through Azure AD Conditional Access policies. A Conditional Access policy is essentially a real-time policy engine that evaluates these signals at the moment of every authentication request and makes a grant, block, or step-up decision.

A policy might say: "If a user is accessing the Finance SharePoint site and their device is not Intune-compliant, require MFA and restrict download." Another policy might say: "If sign-in risk is high, block access entirely regardless of MFA status."

This is explicit verification in practice. Not one-time at login. Every request. Every session.

Principle 2: Use Least Privilege Access

Grant the minimum access required. For the minimum time required. Nothing more.

This is perhaps the most consistently violated principle in enterprise IT — not because organisations do not understand it, but because implementing it properly is genuinely hard work.

Least privilege has several dimensions:

Access scope: Users should only be able to access the resources they need for their specific role. A warehouse manager does not need access to the HR payroll system. A developer does not need production database credentials.

Permission depth: Even within a system a user legitimately accesses, they should have the minimum permission level required. Read access where read is sufficient. Write access only where creation or modification is genuinely required. Never admin access as a convenience.

Time-bound access: Privileged access — especially to administrative systems — should be granted only for the duration it is needed, then automatically revoked. This is the principle behind Just-in-Time (JIT) access in Privileged Access Management (PAM) solutions. When an administrator needs to make a change to a production system, they request elevated access, it is granted for a specific time window (say, two hours), and it is automatically removed when that window closes. No standing admin accounts with persistent elevated privileges sitting in Active Directory waiting to be compromised.

Privileged Identity Management: In Microsoft Entra, this is implemented through Privileged Identity Management (PIM), which enforces JIT for Azure AD roles and Azure resource roles. An administrator is eligible for the Global Admin role but not permanently assigned. They activate it when needed, provide a justification, and it expires automatically.

Service accounts and workload identities: Least privilege is not just for human users. Service accounts, automation scripts, and application workloads are frequently assigned far more permission than they require. In a Zero Trust model, every workload identity is subject to the same scrutiny. Service accounts should be scoped tightly, monitored continuously, and rotated regularly.

In organisations where I have conducted access reviews — a structured process where resource owners confirm whether each user still requires their access — the findings are almost always uncomfortable. Former employees with active accounts. Users with permissions for roles they left two years ago. Service accounts with Domain Admin rights that were granted "temporarily" in 2018 and never revoked.

Least privilege is an ongoing discipline, not a one-time configuration.

Principle 3: Assume Breach

Design your architecture as if the attacker is already inside.

This is the most psychologically difficult principle for security and operations teams to internalise, because it requires abandoning the comfortable fiction that your perimeter is holding.

Assume breach means:

• Segment your environment so that a compromise of one area cannot immediately spread everywhere (micro-segmentation)

• Monitor continuously for lateral movement, privilege escalation, and unusual data access

• Minimise blast radius — design so that the worst-case impact of any single compromised identity, device, or workload is limited

• Verify end-to-end encryption of data in transit, even on internal networks

• Log everything. Centralise logs. Analyse them. Alert on anomalies.

The practical implication is that you stop designing your architecture around keeping attackers out and start designing it around limiting what an attacker can do once they are in.

Network micro-segmentation replaces the flat trusted LAN. Instead of one large internal network where everything can reach everything, workloads are grouped and access between segments is explicitly controlled. A compromised accounts-payable workstation cannot reach your manufacturing execution system because there is no network path — the traffic would be blocked and alerted.

Application access proxies replace VPNs. Instead of giving a remote user access to your entire network, they are given access to specific applications through an identity-aware proxy (like Microsoft Entra Application Proxy or similar technologies). The user's device never touches the corporate network. The application is published securely without exposing the network.

What a Real Zero Trust Architecture Looks Like

Having established the principles, let me describe what this translates to in practice for a mid-sized enterprise — say, a manufacturing or pharma company with 3,000 to 10,000 employees, a mix of on-premises and cloud workloads, and a workforce that includes office staff, plant floor workers, field sales, and remote executives.

Layer 1: Identity is the new perimeter

Your identity platform becomes the primary control plane. In a Microsoft-centric environment, this means Azure AD (Entra ID) is the authoritative identity provider for every user, every device, and every application — both cloud and on-premises.

Key implementation steps:

• Synchronise all identities to Entra ID via Entra Connect, ensuring on-premises Active Directory and cloud directory are in harmony

• Enforce MFA for all users — no exceptions. Start with Microsoft Authenticator with number matching and additional context enabled to defeat MFA fatigue attacks

• Implement passwordless authentication where possible — FIDO2 security keys for privileged users, Windows Hello for Business for managed devices

• Deploy Conditional Access policies covering all applications, enforcing device compliance, sign-in risk, user risk, and location as signals

• Enable Identity Protection to get real-time risk signals and automated remediation (require MFA on medium risk, block on high risk)

Layer 2: Device health as a trust signal

An identity assertion alone is not sufficient. Zero Trust requires that the device making the request is also verified.

• Enrol all corporate devices in Microsoft Intune (Microsoft Endpoint Manager)

• Define and enforce compliance policies: minimum OS version, BitLocker encryption, AV signatures current, screen lock required, jailbreak/root detection for mobile

• Use compliance state as a Conditional Access signal: non-compliant devices cannot access corporate resources — full stop

• Implement Windows Autopilot for zero-touch provisioning so every new device is enrolled and configured before it reaches the user's hands

• Deploy Microsoft Defender for Endpoint on all managed devices and integrate with Conditional Access so active threats on a device automatically trigger access revocation

Layer 3: Application access without network exposure

• Replace VPN-based remote access for internal applications with Entra Application Proxy or equivalent identity-aware access proxy

• Integrate all SaaS applications with Entra ID for SSO, ensuring access is managed through your central identity platform

• Implement session controls in Microsoft Defender for Cloud Apps for sensitive SaaS applications — restrict download, copy, print based on device compliance state

Layer 4: Privileged access hardened

• Deploy Entra Privileged Identity Management (PIM) for all Azure AD admin roles and Azure resource roles — eliminate standing privilege

• Implement Privileged Access Workstations (PAWs) for administrators performing sensitive operations — dedicated, hardened devices used only for admin tasks

• Deploy a PAM solution (CyberArk, BeyondTrust, or Entra's native capabilities) for on-premises privileged accounts — vaulted credentials, session recording, JIT checkout

• Rotate service account credentials regularly and audit all service account activity

Layer 5: Data protection and monitoring

• Implement Microsoft Purview Information Protection — classify and label sensitive data, enforce protection policies (encryption, access restriction) that travel with the data

• Centralise all security logs in Microsoft Sentinel or your SIEM of choice

• Build detection rules for lateral movement, impossible travel, mass download, privilege escalation

• Conduct regular access reviews via Entra Identity Governance — quarterly for privileged roles, annually for all application access

Common Implementation Mistakes

Having worked through Zero Trust implementations, I want to name the mistakes I see organisations make most frequently.

Starting with technology instead of architecture. Organisations buy a product, deploy it, and then try to retrofit a Zero Trust philosophy around it. The correct sequence is the opposite: define your architecture, identify your gaps, then select tools to fill those gaps.

Treating Zero Trust as a project with an end date. Zero Trust is a continuous operating model, not a project that gets closed out. Access reviews, policy tuning, new risk signals, new workloads — all of this requires ongoing operational investment.

Underinvesting in Conditional Access policy design. I have seen organisations with Entra ID deployed who have three Conditional Access policies: require MFA for admins, block legacy authentication, and allow all other access. This is not Zero Trust. Conditional Access policy design is a discipline that requires understanding your application landscape, your user populations, your device management posture, and your risk tolerance.

Neglecting non-human identities. Service accounts, managed identities, application registrations — these are frequently the path of least resistance for attackers. Zero Trust must cover workload identities with the same rigour as human users.

Boiling the ocean. Trying to implement everything at once leads to paralysis. A pragmatic approach is to start with identity and MFA (highest impact, foundational to everything else), add device compliance next, then layer in application controls and privileged access hardening. Iterative progress beats perfect planning.

Measuring Progress: Zero Trust Maturity

The Cybersecurity and Infrastructure Security Agency (CISA) publishes a Zero Trust Maturity Model with five pillars — Identity, Devices, Networks, Applications and Workloads, and Data — each with three maturity levels: Traditional, Advanced, and Optimal.

This is a useful framework for assessing where your organisation stands today and charting a realistic roadmap. Most organisations are Traditional or partially Advanced across these pillars. Very few have reached Optimal in any pillar. The goal is not to reach Optimal overnight but to move deliberately in the right direction, measured against a clear model.

I recommend using CISA's model as the basis for an annual Zero Trust posture review — assess each pillar, identify gaps, prioritise investments, and track progress year over year.

Key Differences: Traditional Perimeter vs. Zero Trust

• Traditional: Trust inside the firewall/VPN; focus on keeping threats out.

• Zero Trust: No implicit trust anywhere; continuous verification + least privilege + breach assumption. Better suited for cloud, remote work, and modern threats.

Zero Trust is a journey, not a destination. Start with high-impact areas like privileged access, critical apps, or remote workforce, then expand. Measure success through reduced blast radius, faster incident response, and improved visibility rather than "being Zero Trust."

This approach significantly strengthens security posture when implemented thoughtfully with IAM as the core.

Final Thought

Zero Trust is not a destination you arrive at. It is a direction you commit to.

Every enterprise has a different starting point — a different mix of legacy systems, cloud services, device types, user populations, and risk appetite. There is no single architecture that fits all of them. But the principles are universal: verify explicitly, use least privilege, assume breach. These principles should be the lens through which every architectural decision is evaluated.

The next time a vendor tells you their product delivers Zero Trust, ask them which of these three principles their product addresses, and what architectural gaps remain after you deploy it. The quality of their answer will tell you everything you need to know.

Zero Trust is not something you buy. It is something you build — continuously, deliberately, and with clear architectural intent.

Suvankar Chakraborty is a Principal Engineer with 13+ years of experience in Identity & Access Management, Microsoft 365, Intune/Endpoint Management, and IT Operations. He works with European and APAC enterprises in IT Software , manufacturing sectors across Delhi NCR. Connect with him on LinkedIn for more technical content on IAM, Zero Trust, and enterprise IT operations.

Read next:

• Azure AD vs Entra ID — what changed and why it matters

• How to design a PAM strategy for a 5,000-user enterprise

• Conditional Access policies that actually work in production