By NHI Mgmt Group Editorial TeamBased on JumpCloud: “Why Zero Trust Needs to Be Rolled Out in Phases” (August 28, 2025)

TL;DR: Zero Trust programmes often stall after MFA and admin hardening because only 16% of organisations cover most of their systems, users and infrastructure, according to JumpCloud citing Gartner; a phased rollout moves teams from foundational controls to contextual access and then to automation and scale. Zero Trust only scales when it is treated as an operating model, not a one-time project.


At a glance

What this is: This is a phased Zero Trust rollout framework that argues teams should sequence foundational controls, contextual access and operational automation instead of trying to scale everything at once.

Why it matters: It matters because IAM teams have to turn Zero Trust from a set of point fixes into a governance model that can extend across users, systems, cloud environments and future NHI or autonomous access patterns.

By the numbers:

  • Only 16% of organisations have Zero Trust protections covering most of their systems, users and infrastructure.
  • According to Gartner, 16% of organisations have Zero Trust protections covering most of their systems, users and infrastructure.

Context

Zero Trust is a security operating model that assumes access should be continuously verified, not granted once and trusted indefinitely. In this article, the core IAM problem is not whether organisations can turn on MFA, but whether they can extend access governance beyond the first control layer without creating fragmentation.

The article frames phased rollout as a response to implementation fatigue, uneven tool support and growing operational complexity. That is a familiar pattern in identity programmes: teams secure the obvious entry points first, then struggle to translate that initial progress into durable policy, telemetry and lifecycle control across the rest of the environment.

For IAM and security leads, the practical question is how to sequence adoption so that access control maturity increases without overwhelming operations. The answer here is not more ambition, but a clearer governance order for how identity controls expand over time.


Key questions

Q: What should teams do first when zero trust is still only partially deployed?

A: Start with the controls that remove the most obvious exposure: MFA, least privilege, shared credential protection and removal of default admin accounts. Then use a defined sequence to extend policy into contextual access, automation and reporting. The goal is to avoid building a patchwork programme that protects logins but leaves the rest of the environment inconsistent.

Q: Why do zero trust programmes often stall after MFA and admin hardening?

A: They stall because early wins are easier than extending policy across legacy systems, disconnected tools and unmanaged devices. Once the login layer is covered, organisations still have to solve visibility, enforcement consistency and lifecycle automation. Without that operating model, Zero Trust remains a set of controls rather than a scalable governance approach.

Q: What are the signs that a zero trust rollout is failing in practice?

A: Common warning signs include overlapping tools that do not integrate well, inconsistent policy enforcement across environments, weak visibility into asset and transaction flows, and users bypassing controls because processes are too cumbersome. If teams cannot tell who accessed what, when, and why, the program is not delivering the verification and control zero trust is supposed to provide.

Q: How should IAM teams decide when to extend zero trust to more systems?

A: Extend coverage when foundational controls are stable, access decisions can use reliable context, and lifecycle operations are automated enough to sustain change. If the organisation still depends on manual provisioning or inconsistent logging, widening scope will increase complexity faster than it reduces risk.


Technical breakdown

Why Zero Trust rollouts stall after early access controls

Zero Trust fails to scale when teams treat MFA and admin lockdown as the endpoint rather than the baseline. Once the obvious accounts are protected, the harder work begins: legacy systems, disconnected tools, unmanaged devices and uneven policy enforcement all create gaps that do not disappear just because the login layer was hardened. The real technical challenge is governance consistency across heterogeneous environments. Without a rollout sequence, organisations end up with pockets of strong control and large areas of unmanaged access, which creates false confidence and weak visibility.

Practical implication: map where your access controls stop at the login boundary and identify the systems that still sit outside consistent governance.

How contextual access extends zero trust beyond MFA

The second phase in the article moves from static authentication to contextual authorisation. That means access decisions use signals such as device health, location and behaviour, rather than only whether a user knows the right credential. Technically, this is where Zero Trust becomes an access policy system instead of an authentication upgrade. Conditional access, application-specific access paths and device posture checks widen the control surface and reduce dependence on blunt perimeter assumptions. The aim is not to block users, but to make trust decisions more specific and more observable.

Practical implication: build conditional access rules around context that can be measured and governed, not just around login success.

Why automation and logging determine whether zero trust can scale

The final phase is operationalisation. Provisioning, deprovisioning, logging, auditing and policy review are what stop Zero Trust from becoming a manual project with no stable operating rhythm. At scale, the bottleneck is usually not policy design but policy execution across teams and systems. Automating access lifecycle actions reduces drift, while centralised logging and reporting make it possible to prove that controls are holding. Without these elements, even a well-designed model becomes too labour-intensive to sustain as the environment grows.

Practical implication: align identity lifecycle automation and logging before expanding Zero Trust coverage to more systems or user groups.


NHI Mgmt Group analysis

Phased rollout is the only practical way to turn Zero Trust into an operating model. The article is right to reject the idea that Zero Trust can be deployed as a single project milestone. Access control maturity has to move from foundational authentication to contextual policy and then to automated operations, or it stalls at the first layer of defence. For practitioners, the important shift is to manage Zero Trust as a governed progression, not a destination.

The governance gap is not technical capability alone, but sequencing discipline. Many organisations already have enough tooling to reduce risk in isolated areas, yet they lack an order of operations that turns those controls into a coherent programme. That is why legacy systems, fragmented tools and competing priorities matter so much: they expose the absence of a rollout model. The programme failure is structural, which means the fix begins with governance design rather than another isolated control.

Zero Trust is becoming a lifecycle problem, not just an authentication problem. The article’s move from MFA to provisioning, deprovisioning, logging and policy review shows where mature programmes are heading. As identity environments span human users, service accounts and eventually autonomous access patterns, the control that matters is whether access can be governed consistently over time. Practitioners should treat lifecycle automation as part of Zero Trust maturity, not a separate IAM workstream.

Identity blast radius is the right concept for phased Zero Trust planning. The article implicitly describes a programme that shrinks blast radius in steps: first by reducing standing exposure, then by tightening context, then by making control sustainable. That framing is more useful than thinking only in terms of perimeter replacement. Teams should measure how much identity exposure each phase removes, because that tells them whether Zero Trust is actually reducing enterprise risk.

Zero Trust only scales when policy, telemetry and identity operations converge. The article’s emphasis on logging, auditing and reporting is a reminder that access decisions are only as good as the evidence behind them. If identity policy lives separately from operational visibility, teams cannot tell whether controls are working or merely configured. Practitioners should align access policy, detection and lifecycle operations as one governance plane.

From our research library:

What this signals

Identity programmes fail when rollout is treated as a feature checklist rather than a control sequence. Zero Trust maturity depends on sequencing, because access governance cannot scale if teams skip from login hardening straight to broad coverage. The useful question for practitioners is not whether they have Zero Trust, but which systems remain outside a consistent policy and telemetry model.

Zero Trust for identity is becoming an operating discipline that spans human and non-human access. Once provisioning, deprovisioning, auditing and conditional access are part of the same programme, the same governance logic can be extended to service accounts and future autonomous actors. That makes the phased model relevant well beyond user logins, because it defines how access should be introduced, observed and retired across the identity estate.

Identity blast radius: the amount of access exposure left after each rollout phase, becomes a more useful measure than implementation progress alone. Teams should ask whether each step meaningfully shrinks uncontrolled access, not just whether another control has been switched on. That is the difference between Zero Trust as a project and Zero Trust as a durable security posture.


For practitioners

  • Sequence Zero Trust by control maturity Start with MFA, least privilege, shared credential protection, default admin removal and protocol cleanup before expanding to contextual access and automation.
  • Expand conditional access using trusted signals Use device health, location and behavioural context to make access decisions more specific, and govern unmanaged devices before extending coverage further.
  • Automate identity lifecycle operations Connect provisioning, deprovisioning, logging and policy review so Zero Trust does not depend on manual follow-up as the environment grows.
  • Centralise evidence for access decisions Make logging, auditing and reporting part of the rollout plan so teams can prove whether policy is being enforced consistently across systems.
  • Review rollout priorities against environment complexity Check whether legacy systems, fragmented tooling and competing programmes are delaying coverage in places where the strongest access controls are still missing.

Key takeaways

  • The article argues that Zero Trust fails to scale when organisations stop at MFA and admin hardening instead of sequencing broader access controls.
  • Gartner's 16% figure shows that most organisations are still not covering the majority of their systems, users and infrastructure with Zero Trust.
  • A phased model works best when access policy, contextual signals, automation and logging are treated as one operating discipline.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about governing access scope as Zero Trust matures across systems.
Recommendation — Apply PR.AA-05 to standardise access decisions as you expand Zero Trust beyond initial authentication.
NIST Zero Trust (SP 800-207)3.4 — Policy decision and policy enforcementThe phased model depends on policy decisions and enforcement becoming operationally consistent.
Recommendation — Separate policy decision and enforcement functions so access rules can scale across environments.
CIS Controls v8CIS-5 — Account ManagementThe rollout relies on lifecycle controls for accounts, admins and shared credentials.
Recommendation — Use CIS-5 to tighten account governance before broadening Zero Trust coverage.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementMFA and credential handling are foundational to the article's first phase.
AC-6 — Least PrivilegeLeast privilege is central to the article's foundational control phase.
Recommendation — Apply IA-5 to govern authenticators before extending access decisions to richer context. Use AC-6 to reduce standing access before introducing more advanced Zero Trust controls.

Key terms

  • 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.
  • Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
  • Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
  • Identity lifecycle automation: The orchestration of joiner, mover, and leaver events so access is granted, adjusted, and removed without manual gaps. For mixed identity estates, it matters because revocation and review must keep pace with identities that do not follow human employment timelines.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org