TL;DR: Zero Trust is still an operating model, not a product, and the 2026 buying problem is whether providers can verify identity, enforce least privilege, and prove effective permissions across hybrid apps, SaaS, and non-human identities, according to Veza. The practical test is authorization depth, not access-path coverage alone: blast radius is the real control variable.
At a glance
What this is: This is a Zero Trust provider guide that argues the real test in 2026 is whether a stack can prove and reduce effective permissions, not just authenticate users or broker access paths.
Why it matters: It matters because IAM, PAM, and NHI teams need to judge Zero Trust programs by blast radius reduction, entitlement evidence, and governance across human, machine, and privileged access.
Context
Zero Trust is an operating model, not a single product category. The governance gap is that many programmes still stop at MFA or access-path control and treat that as full coverage, even though authorization is where blast radius is actually set. For identity teams, the issue is not just who can connect, but what they can do once connected across apps, data, and admin surfaces.
In this guide, the vendor frames providers as implementation layers across identity, ZTNA, SSE, PAM, telemetry, and governance. That framing is useful because it exposes a practical truth: the strongest Zero Trust designs tie policy decisions, enforcement, and evidence together, especially where hybrid applications, SaaS sprawl, and non-human identities create entitlement drift.
Key questions
Q: What breaks when Zero Trust is treated as MFA plus VPN replacement?
A: The programme becomes narrow and fragile because it ignores device posture, workload identity, transaction context, and session behaviour. That leaves gaps after login, which is where real compromise often occurs. A Zero Trust strategy must govern the full access path, not just the authentication event.
Q: Why do over-permissioned identities increase blast radius in Zero Trust programs?
A: Because Zero Trust reduces risk by constraining what an identity can do after entry, not just whether it can enter. When permissions remain broad, compromise, misuse, or delegation can still reach sensitive data and administrative functions even if authentication and network controls are strong.
Q: What are the signs that a Zero Trust program is not reducing risk?
A: A common sign is that teams can report on login events and tunnel usage but cannot describe effective permissions, privileged session scope, or entitlement drift. If evidence stops at access paths, the programme is measuring transport control rather than blast radius reduction.
Q: How do Zero Trust, ZTNA, and PAM differ in practice?
A: Zero Trust is the operating model, ZTNA is the access method for private apps, and PAM governs elevated or high-risk access. They solve different problems, so a programme that uses one of them as a substitute for the others will leave governance gaps in either reachability or privilege.
Technical breakdown
Why authorization depth defines blast radius
Zero Trust only becomes operational when the control plane can distinguish authentication from authorization. MFA proves the subject, but entitlement data determines the damage that subject can cause. That is why access-path tools and transport controls are necessary but incomplete: they answer whether a session can start, not what the identity can read, change, delete, or delegate inside the target system. Effective permissions are the real security boundary in modern environments.
Practical implication: Treat authorization evidence as a first-class control objective, not an audit afterthought.
How ZTNA, SSE, and PAM differ in the control stack
ZTNA is the access method for private applications, SSE is the edge-delivered policy and inspection layer, and PAM governs high-risk privileged paths. These layers can work together, but they solve different problems. ZTNA constrains reachability, SSE shapes and inspects traffic, and PAM reduces standing privilege and session abuse. None of them, by themselves, prove least privilege inside SaaS, cloud data platforms, or administrative back ends.
Practical implication: Map each product to the control it actually provides, then close the entitlement gap with governance.
Why non-human identities change Zero Trust economics
Non-human identities turn Zero Trust from a user-centric programme into a lifecycle and authorization problem. Service accounts, workloads, tokens, and AI agents often accumulate broad permissions that are invisible to network-centric controls. Once these identities are in scope, governance has to follow the identity lifecycle, not just the access path, because compromise or misuse can occur without any human login event at all.
Practical implication: Bring machine identities into the same authorization review and evidence model as human access.
Threat narrative
Attacker objective: The objective is to turn a valid access path into broad internal reach by exploiting over-permissioned identities and weak authorization boundaries.
- Entry occurs through a legitimate identity or session that passes authentication and reaches an application or control plane.
- Escalation follows when excessive permissions, standing privilege, or weak entitlement governance let the identity act beyond its intended scope.
- Impact appears as lateral movement, data exposure, or administrative abuse that broad access-path controls did not prevent.
Breaches seen in the wild
- Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authorization, not authentication, is the control plane that matters in Zero Trust: programmes that stop at identity verification confuse entry control with blast-radius control. MFA and SSO can confirm who is present, but they do not answer what that identity can actually do across apps, data, and admin surfaces. The discipline changes when teams measure effective permissions instead of connection success, and that is where Zero Trust either becomes real or stays cosmetic.
Zero Trust providers now have to prove governance across the access stack, not just coverage across the access path: a vendor that secures reachability without entitlement visibility leaves the organisation with controlled ingress and uncontrolled action. The article’s own framing shows why this market is maturing toward evidence, policy consistency, and authorization reporting. Practitioners should view breadth as useful only when policy, enforcement, and proof remain aligned.
Non-human identities expose the limits of perimeter-era Zero Trust thinking: the same access model that struggles with SaaS sprawl becomes weaker when service accounts, workloads, and AI agents are added to the population. These identities do not behave like human users, but they still accumulate privilege and can be over-scoped for convenience. The practitioner conclusion is straightforward: machine access must be governed as a lifecycle and authorization problem, not as a special case.
Blast radius control is the right naming convention for this category: the industry still talks about Zero Trust in terms of gateways, tunnels, and policy engines, but the real question is how much damage any identity can cause after entry. That wording is useful because it forces evaluation away from logo-based coverage and toward measurable exposure reduction. Teams should use it as the shorthand for whether a programme is changing risk or just reorganising it.
Provider consolidation will increasingly favour stacks that connect identity, privilege, and evidence: the market signal here is not that every platform must do everything, but that Zero Trust buyers are demanding joined-up control planes. Identity governance, privileged access, and telemetry are no longer separate conversations when auditors want proof and operators want containment. Practitioners should expect buying decisions to tilt toward integration depth over isolated point capabilities.
From our research library:
- More than 95% of infrastructure-as-a-service accounts use less than 3% of the entitlements they are granted, according to Gartner.
- Read next: NHI Lifecycle Management Guide
What this signals
Effective permissions are now the real Zero Trust boundary: programmes that cannot answer who can do what inside core systems are still relying on transport and authentication signals rather than governance. The shift is toward proving blast radius reduction in apps, cloud platforms, and SaaS, not just proving that sessions were allowed.
Non-human identities make the governance gap harder to ignore: service accounts, workloads, and other machine identities routinely hold permissions that humans never review closely enough. More than 95% of infrastructure-as-a-service accounts use less than 3% of the entitlements they are granted, according to the Ultimate Guide to NHIs.
Authorization evidence will become the buying criterion: identity, privileged access, and policy enforcement are moving toward a single evaluation question, which is whether the platform can continuously reduce exposure and show it in audit-ready form. Teams that cannot produce that evidence will keep calling their stack Zero Trust while still carrying excessive internal reach.
For practitioners
- Map control ownership by Zero Trust layer Separate identity, ZTNA, SSE, privileged access, and governance into distinct control responsibilities so you do not mistake reachability for least privilege.
- Measure effective permissions first Inventory what users and NHIs can actually do inside high-value apps, cloud services, and admin planes, then use that baseline to shrink blast radius.
- Bring non-human identities into governance Include service accounts, workloads, tokens, and AI agents in the same entitlement review and evidence workflow as human identities.
- Tie privileged access to session evidence Require session-level recording and approval signals for administrative paths so standing privilege does not hide inside normal Zero Trust coverage.
- Validate policy, enforcement, and evidence together Check that the system deciding access, the control enforcing it, and the log proving it all tell the same story when permissions change.
Key takeaways
- Zero Trust programs fail when they equate authentication and access-path control with actual privilege reduction.
- The practical test in 2026 is whether a stack can prove effective permissions across human and non-human identities.
- Teams should judge providers by blast-radius reduction, governance evidence, and the ability to control privilege inside the target system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The article is explicitly anchored to NIST 800-207 and evaluates Zero Trust implementation layers. |
| Recommendation — Use Zero Trust Architecture to separate access, enforcement, and evidence so authentication does not substitute for authorization. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article's core finding is that effective permissions, not logins, determine blast radius. |
| Recommendation — Apply PR.AA-05 to inventory and constrain entitlements across apps, cloud services, and privileged accounts. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Non-human identities are repeatedly identified as part of the Zero Trust evaluation scope and entitlement risk. |
| NHI-07 — Long-Lived Secrets | The guide includes machine identities and privileged paths where persistent credentials keep exposure alive. | |
| Recommendation — Review NHIs for overprivileged access and remove unused entitlements before they expand blast radius. Shorten secret lifetime and pair it with lifecycle governance so machine access does not persist beyond need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central to reducing standing privilege and privileged access exposure. |
| Recommendation — Use IA-5 to govern issuance, rotation, and revocation of authenticators for human and non-human identities. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's blast-radius framing maps to attacker use of credentials and movement after entry. |
| Recommendation — Map privilege gaps to credential access and lateral movement so detections focus on what attackers can do next. | ||
Key terms
- Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org