Zero trust for real work: why usability now drives resilience

At a glance

What this is: This is Illumio’s analysis of why Zero Trust fails when it is designed around controls instead of actual user workflows, with AI and segmentation raising the stakes.

Why it matters: It matters because IAM, PAM, NHI, and broader security teams need policies that reduce friction without creating exceptions, or users and systems will route around the controls.

By the numbers:

• We’re spending roughly $240 billion on cybersecurity, while cybercrime losses are expected to reach $10.5 trillion this year.

👉 Read Illumio’s analysis of Zero Trust, user behaviour, and AI risk

Context

Zero Trust fails when security design assumes ideal behaviour instead of actual workflows. In this article, the primary issue is not a missing control family but a governance gap: organisations often optimise for compliance and procurement, then discover that users and systems create workarounds that weaken real-world containment. That same gap matters across IAM, PAM, NHI, and agentic AI programmes because friction changes how access is used.

The article also connects Zero Trust to AI oversight and data lifecycle control. When AI systems, service accounts, or human users operate with broad access and weak observability, continuous verification becomes the only reliable way to keep exposure bounded. For identity teams, that means the user journey, the machine journey, and the access path all need to be designed together.

Key questions

Q: How should security teams implement Zero Trust without breaking user workflows?

A: Start by observing how people actually complete work, then redesign access paths so the secure route is also the easiest route. If controls force constant exceptions, users will bypass them and the model fails. The goal is to reduce friction at the point of access while still enforcing continuous verification and least privilege.

Q: Why do users and administrators create workarounds around security controls?

A: They create workarounds when controls are too slow, too rigid, or disconnected from operational reality. In practice, friction becomes a governance problem because the shadow process often becomes the real process. That is why teams need to measure where work is being redirected outside the intended control path.

Q: How do you know if Zero Trust is actually working?

A: Look for reduced lateral movement, narrower trust paths, and faster containment when an account or system is compromised. If teams still rely on exceptions to keep business moving, the policy is not operating as designed. Effective Zero Trust changes the blast radius, not just the documentation.

Q: Who is accountable when AI systems operate with privileged access?

A: Accountability should sit with the team that owns the AI system’s runtime privileges, logging, and decision traceability. If an AI can access data or trigger actions, its identity must be governed like any other privileged system. The organisation remains accountable for what the system does in production.

Technical breakdown

Why user friction breaks Zero Trust enforcement

Zero Trust is a design model that assumes trust must be continuously validated, but validation only works if the control path is usable. When policies are too rigid or workflows are not understood, users create exceptions, store alternate credentials, or bypass sanctioned access paths. That turns a preventive model into a paper exercise. The article’s core point is that security controls fail when they are designed around the buyer’s checklist instead of the user’s operating reality. The technical consequence is that identity signals, access decisions, and network segmentation all become less reliable because they no longer reflect actual behaviour.

Practical implication: map where users circumvent access controls and redesign those paths before tightening policy.

How segmentation contains blast radius in identity-rich environments

Segmentation limits which systems can talk to each other, reducing lateral movement when one account, host, or workflow is compromised. In Zero Trust terms, it narrows the trust boundary to the smallest practical scope instead of assuming internal traffic is safe. This is especially relevant when human users, service accounts, and AI-driven workflows share the same environment, because a single over-broad identity can bridge many systems. Effective segmentation depends on understanding communication patterns, not just tagging assets. Without that baseline, policy becomes coarse, and coarse policy produces either outages or exceptions.

Practical implication: build communication maps before enforcing segmentation so identity-to-system paths remain supportable.

Why AI turns visibility into an identity control problem

The article treats AI as privileged access with its own governance burden. That framing matters because AI systems can read data, trigger workflows, and influence decisions at machine speed, which means conventional approval flows are too slow to be the only safeguard. The technical requirement is immutable logging, verified decision paths, and controls that can observe what an AI system did, not just what it was allowed to do. This is where identity and AI governance intersect: the system identity must be accountable in the same way a human privileged account is, but with tighter runtime visibility.

Practical implication: treat AI runtime identity, logging, and decision traceability as core access controls, not optional telemetry.

Threat narrative

Attacker objective: The attacker’s objective is to turn organisational convenience and weak containment into broader access that is hard to detect and harder to limit.

1. Entry occurs when attackers exploit user friction, unsafe workarounds, or over-broad access paths that were created to keep workflows moving.
2. Escalation happens when a compromised account or system can move through weakly segmented internal paths and reach additional resources.
3. Impact follows when the attacker uses that trust gap to expand access, observe sensitive activity, or contain-bypass into broader compromise.

NHI Mgmt Group analysis

Compliance-led security creates a control illusion when it replaces operational design. The article is right to challenge checklist thinking because Zero Trust fails when controls satisfy auditors but not actual users. In IAM and PAM programmes, that means access policy must be measured against behaviour, not just policy text. The practical conclusion is that resilience starts where the user journey starts.

User friction is a governance signal, not just a UX issue. When controls are painful, users and administrators work around them, and those workarounds become shadow policy. This is especially relevant to NHI and agentic AI programmes, where service accounts and automated workflows often inherit exceptions that human teams would never approve deliberately. Practitioners should treat friction hot spots as indicators of privilege drift and containment weakness.

Zero Trust must extend to machine identities and AI systems, not just employees. The article’s AI framing points to a broader reality: autonomous or semi-autonomous systems can hold privileged pathways, and those pathways need continuous validation, logging, and scope control. That is where machine identity governance and human IAM converge. The practical conclusion is to govern runtime access by system identity, not by trust in deployment intent.

Blast-radius control is becoming the defining metric for effective Zero Trust. The article’s emphasis on segmentation is important because organisations rarely eliminate compromise, but they can decide how far it travels. In identity-heavy environments, that means least privilege, path restriction, and observability must work together. Practitioners should judge Zero Trust by how quickly it stops movement, not by how many controls are deployed.

AI governance is now part of access governance. Treating AI as privileged access is the right conceptual move because decision-making systems can create the same downstream risk as a human administrator. The field should stop separating AI oversight from identity controls and start managing them as one policy domain. The practical conclusion is to bring AI runtime identity into the same governance model as PAM and NHI oversight.

What this signals

A Zero Trust programme that is not designed around actual work patterns will keep producing exceptions, and exceptions are where containment fails. The identity lesson is direct: user friction, service-account sprawl, and AI runtime access all need to be measured as governance risks, not treated as separate operational annoyances.

Control-path drift: when the secure path and the real path diverge, the organisation has effectively created two policies, one written and one operational. That divergence is especially dangerous in environments that mix human users, NHIs, and AI systems, because each can inherit different trust assumptions. The practical response is to track where access decisions are made versus where work actually happens.

The broader signal is that AI and machine identity governance are becoming inseparable from access governance. For teams already struggling with NHI visibility, the next stage is to align runtime logging, segmentation, and least privilege so that identity controls still matter once automation enters the workflow.

For practitioners

• Measure friction before you tighten policy Identify where users create workarounds, shared accounts, or alternate paths because official controls slow delivery. Use those findings to redesign the access path rather than layering more approvals onto a broken process.
• Build segmentation around real communication flows Map how systems, users, and service accounts actually communicate, then apply segmentation to those paths. That prevents broad exceptions and makes containment supportable in production.
• Put AI runtime identity under governance Require immutable logs, decision traceability, and scoped privileges for AI systems that can read data or trigger actions. Treat AI access as a privileged identity problem, not a model-only issue.
• Align Zero Trust metrics to containment outcomes Track how fast a compromise is isolated, how many paths remain open after compromise, and how often exceptions are granted to keep controls usable. Those signals show whether Zero Trust is reducing blast radius.

Key takeaways

• Zero Trust fails when it is designed as a compliance exercise instead of an operational model that fits how people and systems actually work.
• The evidence points to a widening gap between security spend and real-world resilience, with friction and poor visibility driving workarounds that weaken containment.
• Practitioners should focus on reducing blast radius, aligning access paths to actual workflows, and bringing AI runtime identities into the same governance model as human access.

Key terms

• Zero Trust: A security model that assumes no implicit trust for users, devices, or systems, even inside the network. Access decisions are continuously evaluated using identity, device, context, and policy so that compromise is harder to spread and easier to contain.
• Blast Radius: The amount of damage a compromised account, system, or workflow can cause before it is contained. In identity-heavy environments, blast radius is shaped by privilege scope, segmentation, and the number of systems an identity can reach.
• Control Path Drift: The divergence between the secure route an organisation intended and the route people or systems actually use. It often appears when controls are too rigid, poorly designed, or detached from workflows, and it turns policy into workaround behaviour.
• Runtime Identity: The identity used by a system, service, or AI workflow while it is operating in production. It needs the same governance discipline as human access because its privileges, logging, and allowed actions determine how far a compromise can move.

What's in the full article

Illumio's full article covers the operational detail this post intentionally leaves for the source:

• Specific examples of how user friction creates security workarounds in real environments.
• Theresa Payton’s practical guidance on observing workflows in call centres and client sites.
• Further discussion of AI as privileged access and why immutable logs matter for governance.
• How segmentation and least privilege are used together to contain lateral movement in practice.

👉 Illumio’s full post expands on segmentation, compliance limits, and practical Zero Trust design.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that supports real-world access control programmes. It is suitable for practitioners who need a stronger bridge between identity design, operational risk, and runtime enforcement.