Zero Trust rollouts stall when identity baselines are incomplete

At a glance

What this is: This is an analysis of five recurring reasons Zero Trust rollouts slow down, with the central finding that identity coverage, not network redesign, determines whether the programme progresses.

Why it matters: It matters because IAM, NHI, and human access controls all have to move together if Zero Trust is going to reduce standing privilege and exposure instead of adding friction.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Unosecur's blog on five Zero Trust rollout mistakes and identity fixes

Context

Zero Trust is an identity programme before it is a network programme. If teams cannot inventory users, service accounts, roles, tokens, and effective permissions, then micro-segmentation and policy tightening only obscure the real access picture. The result is stalled rollout, because the programme has no reliable baseline for who or what should be trusted.

In NHI terms, the failure mode is familiar: machine identities are left out of the same governance cycle as human accounts, so ownership, rotation, and privilege reduction lag behind deployment. In human IAM terms, partial MFA and broad exceptions create the same pattern, where verification exists in name but not in operational coverage.

Key questions

Q: How should security teams start a Zero Trust rollout without getting stuck in infrastructure work?

A: Start with an authoritative access baseline. Inventory users, groups, service accounts, roles, policies, and effective permissions before redesigning network controls. That lets teams scope policy, identify excess privilege, and measure whether the programme is actually reducing exposure instead of just adding enforcement layers.

Q: Why do service accounts and API keys make Zero Trust harder to run?

A: They often bypass human-centric controls such as MFA, persist for long periods, and carry broad rights. When those identities are not owned, rotated, and monitored, they become a quiet path around the controls Zero Trust depends on, especially in cloud and CI/CD environments.

Q: What breaks when organisations leave standing privilege in place?

A: Standing privilege keeps access alive long enough for a single compromise to become broad lateral movement. It also makes access reviews weak, because review cycles cannot meaningfully shrink exposure if the same over-permissioned roles remain in daily use between audits.

Q: Which frameworks should teams use when tying Zero Trust to identity governance?

A: NIST SP 800-207 is the core Zero Trust reference, but teams should map it to identity lifecycle and access governance controls in their own programme. The practical test is whether both human and non-human identities are continuously verified, right-sized, and monitored.

Technical breakdown

Identity baselines must come before network controls

Zero Trust depends on knowing the current access state, not just the intended policy state. An identity baseline is the living inventory of users, groups, service accounts, roles, and effective permissions across cloud and on-prem systems. Without it, teams cannot distinguish legitimate access from inherited privilege, orphaned access, or hidden machine accounts. That makes segmentation hard to scope and entitlement reduction impossible to prove. In practice, the programme stalls because the control plane is trying to govern access it has not yet discovered.

Practical implication: build and maintain an authoritative access inventory before expanding segmentation or policy enforcement.

Standing privilege turns RBAC into an exposure multiplier

Role-based access control becomes risky when broad roles are reused for daily work and never converted into task-scoped elevation. Standing privilege means the identity remains continuously empowered, which gives attackers a long dwell window after a single compromise. JIT access narrows that window by making privilege temporary and task-linked, but only if the role model has been cleaned up first. Otherwise, organisations simply move excessive access into a more complex wrapper. The technical issue is not RBAC itself, but RBAC left in a permanent privileged state.

Practical implication: identify the highest-risk standing roles and replace them with time-bound elevation paths tied to task completion.

Machine identities need the same governance depth as users

Service accounts, API keys, tokens, and workload identities often bypass MFA, rotate slowly, and retain broad permissions. In a Zero Trust design, that is a structural problem because machine identities can become the easiest route around human-focused controls. Their lifecycle is different from a person’s, but the governance requirements are the same: owner, purpose, scope, rotation, and monitoring. If those elements are missing, the environment accumulates non-human access that is hard to see and harder to revoke. The result is an identity estate with hidden persistence.

Practical implication: put machine identities into the same discovery, ownership, and rotation workflow as human entitlements.

Threat narrative

Attacker objective: The attacker aims to turn one neglected non-human identity into broad, durable access that can be used for lateral movement and compromise.

1. Entry occurs when an attacker abuses a poorly monitored service account or long-lived credential that sits outside normal identity oversight.
2. Escalation follows when the compromised identity has broader rights than needed, allowing access to customer support systems, cloud resources, or adjacent environments.
3. Impact is achieved through lateral movement and data exposure that persist because the account was not governed with the same monitoring and rotation applied to human identities.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust rollouts fail first at identity discovery, not at policy design. The article’s pattern is clear: teams try to secure what they have not yet fully inventoried. That is why access baselines, not segmentation diagrams, determine whether the programme can move from kickoff deck to enforcement. Practitioners should treat incomplete identity visibility as the root constraint on every downstream Zero Trust control.

Standing privilege is the persistence layer that keeps Zero Trust from becoming operational. When broad roles remain in daily use, a single compromised account still buys attackers time, lateral reach, and repeatability. That is not a policy nuance, it is a structural exposure pattern. Practitioners should read this as a reason to collapse permanent privilege windows, not merely tune review cadence.

Machine identities are not edge cases in Zero Trust, they are the main escape hatch. Service accounts, API keys, and tokens often sit outside MFA-centric thinking while carrying high-value permissions. Identity blast radius: the practical concept here is the amount of damage one unmanaged identity can create once it is granted persistent scope. Practitioners should treat every unowned NHI as a latent Zero Trust failure, not a future hygiene task.

NIST SP 800-207 only works when continuous verification includes non-human identities. The framework assumes all identities are part of the trust decision, but many programmes still validate humans more rigorously than machine accounts. That creates a two-tier Zero Trust model in which the easiest path in is through the least governed identity class. Practitioners should align governance coverage across human and non-human identities before claiming architectural maturity.

Zero Trust is really an entitlement reduction programme with identity controls attached. The article’s five mistakes all point to the same governance truth: programmes stall when teams measure deployment activity instead of access reduction. The discipline should be judged on coverage, privilege compression, and automated response, because those are the controls that actually change attack surface. Practitioners should use that lens to reset their Zero Trust scorecards.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why access baselines remain incomplete even in mature environments.
• For practitioners trying to close that gap, Ultimate Guide to NHIs , Standards shows how NIST and OWASP mappings anchor continuous verification and privilege reduction.

What this signals

Identity baseline debt is now the hidden blocker in many Zero Trust programmes. If you cannot see service accounts, role inheritance, and effective permissions together, you are not governing trust continuously, you are only redesigning control boundaries. The next maturity step is to treat discovery as an always-on function, not a project phase.

The programme signal is moving from coverage metrics to exposure metrics. Teams need to know how many identities still sit outside rotation, how much privilege remains standing, and how quickly anomalies are closed once detected. That is where identity programmes start to change attack economics rather than just reporting compliance.

For teams aligning to NIST SP 800-207, the practical shift is to extend continuous verification to every identity class, including machine accounts and service principals. The Zero Trust target state is not a policy framework with exceptions. It is a governed identity estate with shrinking blast radius and measurable remediation speed.

For practitioners

• Build the access baseline first Export identities, groups, service accounts, roles, policies, and effective permissions across the top business-critical systems. Assign each identity an owner and purpose so entitlement reduction can be measured against a current inventory.
• Replace permanent privilege with JIT elevation Identify the top over-permissioned roles, remove daily-use admin access, and convert privileged tasks into time-bound elevation flows that auto-revoke when work completes.
• Put machine identities into governance cycles Discover service accounts and API keys, tag them by owner and sensitivity, and enforce rotation, scope limits, and alerting on unusual use such as a build bot touching production data.
• Track Zero Trust as an access-reduction programme Use one executive view for coverage, entitlement reduction, and automated incident closure so the programme is judged by reduced exposure rather than by rollout milestones.

Key takeaways

• Zero Trust stalls when identity discovery is incomplete, because the programme cannot govern access it has not inventoried.
• Standing privilege and unmanaged machine identities are the two controls most likely to preserve attacker dwell time after a single compromise.
• Practitioners should judge Zero Trust by reduced entitlement, broader identity coverage, and faster automated response, not by rollout activity.

Key terms

• Identity baseline: A current inventory of identities, roles, entitlements, and effective permissions across environments. In Zero Trust, it is the starting point for deciding what should be trusted, reduced, or continuously verified, because controls cannot govern access that has not been discovered.
• Standing privilege: Persistent elevated access that remains available beyond the immediate task that required it. In identity programmes, standing privilege increases exposure because a single compromise can be reused for lateral movement, and review cycles often arrive too late to reduce the damage.
• Machine identity: A non-human identity used by software, workloads, integrations, or automation to authenticate and access resources. These identities need ownership, purpose, scope, and rotation just like human accounts, but they are often overlooked because they do not sign in interactively.
• Identity blast radius: The amount of damage a compromised identity can cause before it is detected and contained. The term is useful because it links privilege, duration, and monitoring into one operational measure of exposure, especially where service accounts or tokens have broad scope.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The five-mistake rollout checklist with concrete fixes for identity baseline, MFA coverage, RBAC cleanup, machine identity governance, and continuous response.
• The quick-start actions for each mistake, including what to inventory, what to tag, and what to automate in the first sprint.
• The Okta support-system example and how the service account oversight gap maps to Zero Trust control assumptions.
• The week-by-week rollout plan that turns the article’s guidance into an implementation sequence.

👉 The full Unosecur post covers the rollout sequence, quick-start actions, and Okta example in more implementation detail.

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.