The phrase “zero trust” has been diluted by marketing to the point where it risks meaning nothing at all. Every security vendor claims to offer zero trust, and the definition stretches to cover whatever product they happen to sell. But strip away the positioning and the core concept remains sound and consequential: never trust, always verify, and make access decisions based on identity and context rather than network location.
What makes zero trust relevant to identity professionals is that identity is not just one component of zero trust architecture. It is the foundational layer. Without strong identity, you cannot implement any of the other principles. Continuous verification requires knowing who is making the request. Least privilege requires mapping access to identity attributes. Micro-segmentation depends on identity-aware policy enforcement. Identity is the control plane for everything else.
The Network Perimeter Is Gone - Identity Replaced It
The traditional security model assumed a clear boundary: trusted inside, untrusted outside. Firewalls, VPNs, and network segmentation enforced this boundary. If you were on the corporate network, you were implicitly trusted with broad access to internal resources.
This model collapsed under the combined pressure of cloud adoption, remote work, and the proliferation of SaaS applications. When your data is in AWS, your applications are in Azure, your email is in Google Workspace, and your employees are working from home, there is no meaningful “inside” to protect.
Identity filled the vacuum. The question shifted from “are you on the right network?” to “who are you, what device are you using, where are you, and should you have access to this specific resource right now?” This is the essence of identity-centric zero trust.
NIST SP 800-207, published in 2020, formalized this shift. The document defines zero trust architecture around a policy engine (the brain), a policy enforcement point (the gate), and a policy administrator (the control channel). Identity attributes are the primary input to the policy engine’s access decisions.
Continuous Authentication and Authorization
Traditional authentication is a one-time event. You log in, receive a session cookie or token, and that credential grants access until it expires. The system does not reevaluate whether you should still have access after the initial authentication.
Zero trust demands continuous evaluation. The posture of a session can change after authentication: the user might switch to an untrusted network, their device might fall out of compliance, or threat intelligence might flag their account as compromised. A session that was legitimate at 9:00 AM may be illegitimate by 9:15 AM.
Continuous authentication does not mean forcing the user to re-enter credentials constantly. It means the system continuously evaluates risk signals and adjusts the session accordingly. If a user authenticates from a managed device in a known location, access proceeds normally. If that user’s session suddenly appears from a new geographic location with an unmanaged device, the system can require step-up authentication, restrict access scope, or terminate the session entirely.
Microsoft’s Conditional Access, Google’s BeyondCorp model, and Zscaler’s identity-aware proxy all implement variations of this pattern. The technical approaches differ, but the principle is consistent: access decisions are dynamic and context-dependent, not static and permanent.
Conditional Access Policies
Conditional access is where zero trust identity becomes operationally concrete. A conditional access policy evaluates a set of signals - user identity, group membership, device compliance status, location, risk level, application sensitivity - and makes a real-time access decision.
Examples of conditional access policies in practice:
- Accessing email from a managed device on the corporate network requires standard MFA. Accessing email from an unmanaged device requires phishing-resistant MFA and restricts download capabilities.
- Accessing the HR system requires a compliant device with up-to-date patches. Non-compliant devices are redirected to a remediation page.
- Accessing the production environment requires the user to be a member of the operations team, authenticated within the last hour, from a device with disk encryption enabled.
- Any access from a location flagged as high-risk requires additional verification, regardless of other signals.
The power of conditional access is granularity. Rather than making binary allow/deny decisions, organizations can create nuanced policies that balance security with usability. A user who fails one condition does not necessarily lose all access - they may receive restricted access or be prompted for additional verification.
The challenge is policy complexity. Organizations with dozens of applications and multiple user populations can quickly accumulate hundreds of conditional access policies. Without careful governance, policies conflict, create gaps, or generate so many MFA prompts that users become desensitized.
Just-in-Time Provisioning and Least Privilege
Zero trust’s least privilege principle extends beyond traditional role-based access control. Standing privileges - permanent access rights assigned to users based on their role - violate the zero trust principle because they grant access regardless of whether the user currently needs it.
Just-in-time (JIT) provisioning addresses this by granting access only when needed and revoking it when the task is complete. An engineer who needs production database access requests it through a workflow. The request is evaluated against policy, approved (automatically or by a human), and granted for a defined time window. When the window expires, access is revoked automatically.
This model significantly reduces the blast radius of compromised credentials. An attacker who steals an engineer’s credentials gains access only to whatever the engineer currently has provisioned - not to everything the engineer could potentially access.
Implementing JIT provisioning requires tooling that can dynamically manage group memberships, role assignments, and access policies. CyberArk, BeyondTrust, and Delinea offer privileged access management solutions with JIT capabilities. Azure AD Privileged Identity Management provides JIT for Azure roles. HashiCorp Vault’s dynamic secrets engine generates short-lived credentials on demand.
The organizational change is harder than the technology. Teams accustomed to permanent access resist workflows that add friction. Engineering cultures that value speed may push back against approval processes. Success requires demonstrating that JIT access, when properly automated, adds minimal delay while substantially reducing risk.
Real Enterprise Implementation Challenges
Zero trust identity is architecturally sound and practically difficult. Organizations pursuing it encounter several recurring challenges.
Legacy applications resist modern identity patterns. Applications that authenticate via LDAP, use IP-based access controls, or lack support for modern token formats cannot participate in conditional access or continuous evaluation without middleware (reverse proxies, identity-aware proxies) that adds complexity.
Identity silos fragment the control plane. Organizations with separate identity providers for workforce, customer, and partner populations cannot enforce unified policies. Mergers and acquisitions compound this problem. A coherent zero trust posture requires consolidating identity infrastructure, which is a multi-year effort in large enterprises.
Signal quality limits policy effectiveness. Conditional access policies are only as good as the signals they consume. Device compliance data may be stale, location data may be inaccurate, and risk scores may be noisy. Organizations must invest in the signal infrastructure - endpoint management, threat intelligence, behavior analytics - that feeds the policy engine.
Measuring progress is hard. Zero trust is a maturity journey, not a binary state. Organizations struggle to define metrics that meaningfully track progress. Percentage of applications behind an identity-aware proxy, percentage of access managed through JIT, and number of standing privileges eliminated are useful starting points, but no single metric captures the full picture.
User experience suffers when policies are poorly tuned. Overly aggressive conditional access policies generate constant MFA prompts, block legitimate access, and train users to view security controls as obstacles. Undertested policies create outages when they incorrectly deny access. Policy tuning requires ongoing investment and real user feedback.
Where the Industry Is Headed
The zero trust identity conversation at Auth0 World 2022 reflected an industry in active transition. Most enterprises have adopted zero trust as a strategic direction. Far fewer have achieved meaningful implementation across their full application portfolio.
The next phase is operational maturity: moving from pilot programs and high-value applications to systematic coverage, refining policies based on real-world data, and integrating identity signals from across the security stack. Organizations that treat zero trust as a technology purchase will stall. Those that treat it as an ongoing program with identity at its core will steadily reduce their attack surface and improve their ability to detect and respond to identity-based threats.