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

Start with the controls that collapse obvious exposure

The right first move is to remove the easiest ways for an attacker or careless user to reach high-value systems before the zero trust design is fully mature. In practice, that means enforcing MFA, shrinking standing access, protecting shared credentials, and retiring default admin accounts wherever they still exist. NIST SP 800-207 Zero Trust Architecture supports that sequencing because zero trust begins with strong identity assurance and least privilege, not with a full platform refresh.

That first wave should be chosen by exposure, not by organisational neatness. A partially deployed programme often has some protected entry points and many unprotected ones, so the first win is to reduce the number of accounts and pathways that can still authenticate broadly or impersonate privileged users. Zero Trust Identity Guide and IAM and IGA Basics both reflect that the immediate job is to tighten identity and entitlement hygiene before expanding policy depth.

Sequence the rollout so each step reduces blast radius

After the initial exposure-reduction work, extend policy in a deliberate order: first to contextual access, then to automation, then to reporting and assurance. That sequence matters because teams need a stable base of authenticated users, devices, and workloads before they can evaluate location, posture, sensitivity, or session risk in a reliable way. If you try to start with reporting or policy nuance, you often end up measuring inconsistency instead of controlling it.

A sensible phased model is to move from “can this principal log in?” to “should this principal get this action under these conditions?” and only then to “can we evidence that the control is being enforced consistently?” Zero Trust for AI Agents is about a different subject, but the same control logic applies here: policy should be enforced per action, with standing privilege removed and decisions made as close as possible to the request.

For workload and service access, the same sequencing usually means introducing stronger service authentication and narrower trust boundaries before attempting full micro-segmentation or automated policy orchestration. Guide to SPIFFE and SPIRE is useful here because it shows how workload identity can become a practical next step once the obvious human access gaps are under control.

What good looks like in a partial deployment

A partially deployed zero trust programme is healthy when it has a clear order of operations and visible coverage gaps, not when it claims to be “mostly zero trust.” The target state is consistent enforcement of the same access rule at every important entry point, with exceptions tracked and deliberately retired. That means you should be able to name which systems still rely on legacy trust, which accounts still have standing privilege, and which controls are waiting for the next deployment wave.

It also means the team can prove progress without pretending the rollout is complete. Ultimate Guide to NHIs is not the first stop for every zero trust programme, but it is a useful reminder that credentials, service accounts, and workload access become part of the same trust fabric once the environment moves beyond simple login hardening. The operational goal is consistency, not branding.

Risk and Threat Considerations

Partial deployment creates a split security model, where some paths are strongly gated and others still behave like the old perimeter. Attackers and internal abusers gravitate to the weakest remaining path, which is often the shared credential, the default admin account, or the legacy exception that bypasses contextual policy. That is why the first phase should compress blast radius before the programme tries to optimise decision quality.

Failure mechanism: Inconsistent enforcement leaves privileged or widely reused access in place while giving the organisation a false sense of progress, so one compromised account or unmanaged path can still reach far more than intended.

Impact: Compromise can expand laterally through the least-controlled segment, making remediation harder and turning a local authentication weakness into broad environment exposure.

Practitioner Guidance

What to prioritise: Start with the access paths that combine high privilege and high reach, especially shared admin credentials, default accounts, and any login that still bypasses MFA or device checks. Those are the fastest ways to shrink real exposure before broader policy work begins.

Decision rule: If a control can remove direct administrative reach or eliminate a reusable credential, do it before investing time in advanced conditional logic or reporting. If the environment cannot yet enforce the same rule everywhere, treat the gaps as an interim risk to be contained, not as proof that the rollout is finished.

Practitioner takeaway: The first job in a partial zero trust rollout is to make the remaining trust boundaries obvious and narrow, because consistency across a smaller set of controlled paths is more valuable than sophistication spread across an inconsistent estate.

Related resources from NHI Mgmt Group

• Should teams prioritise zero trust design or access cleanup first?
• What controls should teams prioritise first in a Zero Trust rollout?
• How should security teams reduce blast radius in identity-first Zero Trust programmes?
• How should security teams implement zero trust when workforce authentication still depends on passwords?