Common signs include manual lifecycle management, partial automation, siloed policy enforcement, and least privilege that changes only after provisioning. Another indicator is limited visibility across internal systems, with cross-pillar integration still emerging. At this stage, organisations may have some responsive controls, but they have not yet achieved centralized identity control or coordinated enforcement at scale.
What “initial” zero trust looks like in practice
At an initial level, zero trust is usually present as a design intent or a limited control set, not as a consistently enforced operating model. You tend to see a few high-value controls, such as stronger authentication or segmented access in one environment, but not the continuous policy evaluation and lifecycle discipline that would make zero trust dependable across the estate.
The clearest clue is inconsistency. Some users, systems, or requests are treated with zero trust assumptions, while others still rely on legacy trust zones, static entitlements, or manual exceptions. That gap matters because zero trust is not just a perimeter replacement, it is an operating model for how trust, access, and verification are applied over time.
Where this is still early, organisations often have control islands rather than a joined-up architecture. Identity, device, application, and network decisions are made in separate places, so enforcement can exist without producing a coordinated security outcome. A useful reference point is NIST SP 800-207 Zero Trust Architecture, which frames the model around policy-driven enforcement rather than isolated hardening.
What changes when zero trust becomes advanced
Advanced zero trust is less about adding more controls and more about making controls work together continuously. Policies are enforced centrally, access is conditioned on context, and privilege is actively reduced as the environment changes. That usually shows up as faster revocation, tighter scoping of access, and fewer manual handoffs between teams when conditions change.
Visibility is also materially different. At an advanced stage, teams can trace who or what requested access, what policy was applied, what changed the decision, and whether enforcement happened consistently across systems. Without that traceability, organisations may believe they have zero trust because a control exists somewhere, while in reality they cannot prove how access decisions are made end to end.
For identity-bearing workloads and services, advanced posture also depends on reliable identity evidence for the workload itself. Guide to SPIFFE and SPIRE is a useful way to think about that layer because workload identity, attestation, and trust bundles are what let policy decisions scale beyond human login flows. For broader zero trust alignment across NHI and governance practices, see Ultimate Guide to NHIs, Standards.
Research also suggests that the maturity gap is real. In the 2026 Infrastructure Identity Survey, 70% of organisations said AI systems receive more access than a human employee doing the same job, which is a good example of how “control in place” can still fall short of consistent least privilege.
What to verify before calling a zero trust programme mature
What to verify: Check whether policy decisions are driven from a central control plane, whether exceptions are time-bound, and whether access changes propagate quickly enough to match risk. If access still depends on ticket queues, manual recertification, or environment-specific workarounds, the programme is still operating at an early stage.
What good looks like: Mature zero trust shows up as consistent enforcement across pillars, with identity, device, application, and network signals contributing to the same decision. It also produces operational evidence, such as reduced standing access, fewer stale permissions, and auditable reasons for access grants and denials. The NIST model remains a useful anchor here, while Cloud Compliance Pulse 2025 is a practical companion for organisations trying to measure whether access governance and posture controls are actually converging.
Practitioner takeaway: The maturity test is not whether zero trust exists somewhere in the stack, but whether it changes decisions consistently, at speed, and across control domains without relying on human exception handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | 0 — Zero Trust Architecture | Defines the zero trust operating model and policy-driven enforcement this question measures. |
| Recommendation — Assess whether access decisions are centrally policy-driven and continuously verified across pillars. | ||
| CIS Controls v8 | 6 — Access Control Management | Supports the shift from manual access handling to consistent privilege enforcement and review. |
| Recommendation — Automate access assignment, review, and revocation to reduce standing privilege and exceptions. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Covers the identity and access controls that must become consistent for zero trust maturity. |
| DE.CM — Security Continuous Monitoring | Matches the visibility and continuous verification expected in advanced zero trust. | |
| Recommendation — Align identity and access enforcement so access is conditioned on verified context and least privilege. Instrument continuous monitoring to confirm policy enforcement and detect drift across systems. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Zero trust maturity depends on reducing long-lived credentials and uncontrolled access material. |
| Recommendation — Replace long-lived secrets with bounded credentials and enforce rotation, revocation, and discovery. | ||
Related resources from NHI Mgmt Group
- Why do network-centric controls create risk for zero trust access between internal services?
- What are the signs that a traditional perimeter model is failing in a Zero Trust migration?
- Why do non-human identities complicate zero trust architecture?
- Why do non-human identities increase zero trust risk?
