Zero Trust rollouts stall when identity baselines are incomplete

At a glance

What this is: This article argues that Zero Trust rollouts slow down when identity baselines are incomplete, especially when organisations start with network controls before mapping users, entitlements, and machine identities.

Why it matters: IAM, NHI, and PAM teams need a shared baseline because Zero Trust breaks down when access discovery, MFA coverage, privilege reduction, and machine-account governance are treated as separate workstreams.

👉 Read Unosecur's analysis of why Zero Trust rollouts stall without identity baselines

Context

Zero Trust is not a network-first project. In practice, it depends on knowing which identities exist, what they can access, and which of those identities are human, service, API, or workload accounts. When that baseline is missing, teams cannot measure entitlement reduction or continuous verification with any confidence.

The article frames the governance gap clearly: identity programmes stall when coverage is partial, privilege remains standing, and machine identities sit outside the control model. That is why the problem is not only technical configuration, but whether IAM, IGA, PAM, and NHI governance are treated as one operating model.

Unosecur also points to a real-world example involving Okta, where a poorly monitored service account sat outside the main governance model. The case is typical of the failure pattern described here, not an isolated edge case.

Key questions

Q: What breaks when Zero Trust is implemented without identity governance?

A: Zero Trust breaks when the policy engine is enforcing stale or incomplete identity data. If access approvals, ownership, and revocation are not governed, the organisation keeps validating entitlements that no longer match business intent. The result is technically strong enforcement built on weak identity records, which still leaves over-privileged accounts and hidden exceptions in place.

Q: Why do partial MFA deployments still leave Zero Trust programs exposed?

A: Because MFA only reduces risk when the highest-value identities are actually covered. If admins, legacy protocols, shared accounts, or machine identities are exempted, attackers can still reach durable access paths that sit outside the intended verification model.

Q: When should organisations replace standing privilege with just-in-time access?

A: Organisations should replace standing privilege with just-in-time access whenever elevated access is not required continuously. JIT reduces the time window in which credentials can be abused, especially for admin tasks, break-glass use, and sensitive automation. It works best when paired with approval, expiry, and logging so temporary access does not become another form of standing privilege.

Q: How should security teams govern machine identities in zero trust environments?

A: Security teams should govern machine identities with the same discipline used for privileged human access: inventory, ownership, policy-based approval, rotation, monitoring, and revocation. Zero trust only works when every non-human credential has a known purpose and a short, enforceable lifecycle. Without that, machine access becomes a hidden standing privilege layer inside the environment.

Technical breakdown

Why identity baselines come before network controls

Zero Trust depends on an accurate identity inventory before it can meaningfully narrow access. An identity baseline includes users, groups, service accounts, roles, policies, and the effective permissions those identities actually hold across SaaS and cloud. If teams start with segmentation or VPN changes before reconciling identity state, they end up protecting an unknown access surface. That is why entitlement reduction is impossible to measure until ownership, purpose, and sensitivity are assigned to each identity.

Practical implication: establish access discovery as the first control layer before redesigning network enforcement.

Why partial MFA coverage creates a false sense of verification

MFA only improves assurance when it covers the identities that matter, including administrators, legacy access paths, and non-human accounts where appropriate control alternatives are needed. If VIPs, shared admin accounts, and old protocols are left in exception paths, the organisation gets the appearance of verification without the substance. The article also shows the friction problem: when MFA is bolted on without user segmentation or fallback design, adoption drops and exceptions multiply.

Practical implication: treat MFA coverage as an identity inventory problem, not just an authentication setting.

How standing privilege turns Zero Trust into a lateral movement problem

Lift-and-shift RBAC often preserves broad cloud roles that were never designed for least privilege. Once standing privilege is copied into day-to-day access, a single compromised identity can retain broad movement across systems for far longer than the business intended. The article correctly ties this to Just-in-Time access, because the control failure is not the existence of roles but their persistence beyond task scope. That makes privilege duration as important as privilege level.

Practical implication: replace persistent elevation with time-bound access and continuously review over-permissioned roles.

Threat narrative

Attacker objective: The attacker objective is to exploit an identity blind spot to gain durable access and expand reach inside the environment without triggering normal governance checks.

1. Entry occurs through a service account that is not covered by the main governance model and is only weakly monitored.
2. Credential access or abuse follows because the account can be used without the same visibility, rotation, or review applied to human identities.
3. Escalation becomes possible when broad standing access remains attached to cloud roles or machine accounts.
4. Impact is broader environment exposure, because a compromised identity can move laterally or persist undetected inside the Zero Trust perimeter.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust fails first as an identity baseline problem, not a perimeter problem. The article shows that programmes stall when teams can describe network controls but cannot yet name every identity, entitlement, and owner in scope. That is a governance failure because the control model starts from incomplete identity truth. Practitioners should treat identity discovery as the prerequisite for any credible Zero Trust operating model.

Partial verification creates a programme that looks controlled but is still porous. MFA coverage that leaves admins, legacy protocols, and service accounts in exception paths does not establish continuous verification. It creates a split-brain model where the highest-risk identities sit outside the intended trust boundary. The implication is that verification must be designed at the cohort level, not applied as a generic policy toggle.

Standing privilege is the main reason Zero Trust drift becomes operationally dangerous. When broad cloud roles are copied from legacy RBAC into modern environments, the programme inherits the same blast radius it was meant to shrink. JIT access changes the security equation because it limits privilege duration, not just privilege scope. That is the difference between a Zero Trust label and a Zero Trust control model.

Machine identity governance is the hidden dependency in most stalled rollouts. Service accounts, tokens, and API credentials behave like durable access paths unless they are explicitly inventoried, owned, and rotated. This is where NHI governance becomes inseparable from Zero Trust because the programme cannot continuously verify what it does not continuously govern. Practitioners should assume every unmanaged machine account is a standing exception until proven otherwise.

Continuous monitoring is what turns Zero Trust from a project into an operating state. Once identity baselines are set, the programme still needs drift detection for new roles, token misuse, and unexpected privilege growth. That aligns with NIST SP 800-207 and the broader CSF logic of continuous measurement and response. The field lesson is simple: Zero Trust degrades as soon as identity telemetry goes quiet.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Workforce Identity Security Guide

What this signals

Identity baseline drift is the real Zero Trust failure mode. Once an organisation cannot reconcile users, service accounts, and effective permissions, every downstream control becomes harder to prove and easier to bypass. The programme should be measured by how quickly it detects entitlement drift, not by how many perimeter changes it has deployed.

Machine identities need to be treated as part of the same verification chain as human users. Service accounts and API keys do not disappear from the trust model just because they are operationally convenient. In practice, Zero Trust only remains credible when those identities are owned, rotated, and continuously validated.

90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs. That is a strong signal that NHI governance is no longer a specialist concern at the edge of the programme; it is part of the core architecture.

For practitioners

• Build a full identity baseline first Inventory users, groups, service accounts, roles, policies, and effective permissions across cloud and on-prem. Assign each identity an owner, purpose, and sensitivity before changing segmentation or access policy.
• Eliminate MFA exceptions by cohort Target admins, contractors, finance users, and shared elevated accounts for full MFA or passwordless coverage. Remove exception paths for legacy protocols wherever technically feasible and document any remaining fallback controls.
• Convert standing privilege into JIT access Replace persistent cloud elevation with time-bound access workflows. Tie elevation to stronger authentication and auto-revoke it when the task completes, especially for production and break-glass use cases.
• Bring machine accounts into governance Discover service accounts, API keys, tokens, and workload identities, then assign owners and rotation responsibilities. Treat any unmanaged machine credential as a control gap until it is reviewed and scoped.
• Operationalise drift detection Deploy automated checks for new admin grants, token misuse, and identity changes that widen access beyond the approved baseline. Feed those signals into response workflows that can revoke, disable, or re-certify access quickly.

Key takeaways

• Zero Trust rollouts stall when teams cannot establish a complete identity baseline across users, groups, service accounts, roles, and effective permissions.
• Partial MFA, standing privilege, and unmanaged machine identities all preserve the kind of exposure Zero Trust is supposed to shrink.
• The programme becomes credible only when discovery, verification, privilege reduction, and response are designed as one identity operating model.

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: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.

What's in the full article

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

• Step-by-step guidance for building an identity baseline across cloud, SaaS, and on-prem systems
• Practical examples of how to remove MFA exemptions and reduce friction for high-risk cohorts
• Implementation detail on converting standing privilege into JIT access for production tasks
• Operational handling for service accounts, API keys, and workload identities that need rotation and ownership

👉 Unosecur's full post covers the five rollout mistakes, the quick-start fixes, and the Okta example in more operational 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 building or maturing an IAM programme, it is worth exploring.