Should teams prioritise zero trust design or access cleanup first?

Why This Matters for Security Teams

The choice between zero trust design and access cleanup is really a sequencing problem. Zero trust only works when the organisation can see who and what is being trusted, while access cleanup determines whether that trust boundary is already full of stale roles, forgotten service accounts, and overexposed secrets. NHI Management Group’s Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts, which is why many zero trust efforts start from incomplete inventory.

That matters because ZTA assumes continuous verification, but it cannot continuously verify identities that have never been fully discovered or cleaned up. The better starting point is usually to reduce entitlement sprawl, revoke what is no longer needed, and then apply zero trust controls to the remaining identity surface. This aligns with NIST SP 800-207 Zero Trust Architecture, which treats trust as contextual and continuously evaluated rather than permanently granted.

In practice, many security teams discover the real problem only after an old key, stale token, or forgotten workload has already been used to move laterally.

How It Works in Practice

Access cleanup should usually begin with a complete inventory of human and non-human identities, followed by entitlement review, ownership assignment, and revocation of unused access. That does not mean waiting to design zero trust. It means using cleanup to make zero trust deployable. A workable sequence is: discover identities, classify critical systems, remove orphaned access, then apply policy checks, segmentation, and step-up controls around what remains. The OWASP Non-Human Identity Top 10 is useful here because it highlights the risk of excessive privileges, weak lifecycle control, and secret exposure across service accounts and automation.

For NHI-heavy environments, the cleanup phase should include secrets rotation, offboarding automation, and validation that every machine identity has an owner and a purpose. If the environment uses workload identities, pairing cleanup with cryptographic identity standards such as the Guide to SPIFFE and SPIRE can reduce reliance on long-lived static credentials. That gives zero trust something durable to evaluate at runtime.

• Use inventory to find service accounts, API keys, and certificates that no longer have an active business owner.
• Revoke standing access before redesigning policy boundaries that would otherwise preserve bad entitlements.
• Apply zero trust policies to the cleaned identity set, not to an assumed baseline.

Current guidance suggests that zero trust and cleanup should be treated as a coupled programme, but cleanup usually has the higher immediate risk-reduction value. These controls tend to break down in legacy environments with shared accounts and undocumented automation because ownership and dependency chains are too opaque to clean safely.

Common Variations and Edge Cases

Tighter access cleanup often increases operational overhead, requiring organisations to balance faster risk reduction against service disruption and approval fatigue. That tradeoff becomes sharper in environments with 24x7 pipelines, brittle integrations, or embedded credentials in code and configuration. In those cases, a full revocation-first approach can break business workflows unless it is staged carefully.

There is no universal standard for this yet, but best practice is evolving toward risk-based cleanup: start with high-privilege identities, expired credentials, unknown applications, and offboarded owners, then move into broader zero trust policy design. The Ultimate Guide to NHIs — Key Challenges and Risks is especially relevant where teams need to explain why excess privilege and poor visibility make zero trust look stronger on paper than it is in production.

Where cleanup is already mature, teams can prioritise zero trust design earlier, especially for high-risk internet-facing systems. But if visibility is weak, the architecture will inherit the same blind spots. In that scenario, the zero trust programme usually stalls because policy cannot be enforced consistently across identities that were never fully governed.

Related resources from NHI Mgmt Group

• What is the difference between JIT access and Zero Trust for NHIs?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• When should organisations prioritise Zero Standing Privilege for non-human identities?