The earliest zero trust stage, where controls are mostly manual, static, and isolated by pillar. Security decisions depend on fixed policies, external system dependencies, and provisioning-time privilege assumptions. This stage typically reflects limited visibility, slow response, and weak coordination across the environment.
How Traditional Maturity Works
Traditional maturity is the earliest zero trust stage because security still behaves like a collection of separate controls rather than a coordinated trust model. In practice, that means decisions are made from fixed rules, manual checks, and assumptions made at provisioning time instead of from continuous context.
The defining feature is not simply that controls exist, but that they are mostly static and siloed by pillar. An access decision may be strong on paper, yet still depend on a separate system remaining trustworthy, a ticket being handled correctly, or a privilege assignment never drifting out of date.
This stage often shows up in environments where policy is documented but enforcement is inconsistent, visibility is partial, and response is slow. The gap between intended control and actual control is what makes traditional maturity a useful baseline for zero trust discussions.
What Makes It Different From Higher Maturity Stages
Traditional maturity is characterized by dependency on external systems and by the expectation that trust can be granted early and reused later. That is very different from later zero trust stages, where trust is re-evaluated more often and control decisions are more tightly integrated.
Because the model is still mostly manual, organisations at this stage usually rely on human process to compensate for technical gaps. A policy may exist for privileged access, for example, but if approval, review, revocation, and monitoring are not connected, the control behaves like a set of loose promises rather than a closed loop.
The maturity label is therefore a signal about operating style, not just tooling. It tells you that security is present, but not yet unified, adaptive, or deeply instrumented across the environment.
Why Traditional Maturity Matters
Traditional maturity matters because it exposes where a zero trust programme is still fragile. Manual administration, static assumptions, and isolated controls can leave organisations with slower containment, weaker assurance, and poor coordination when something changes quickly.
It is also the stage where false confidence is common. Teams may believe that a policy exists, but if enforcement depends on provisioning-time decisions or external dependencies that are not continuously verified, the environment can still drift into unsafe states.
In zero trust planning, this stage is useful as a diagnostic baseline. It helps identify whether the organisation is still relying on inherited trust, broad standing access, or disconnected control pillars that need to be brought into a more coherent security model.
How to Interpret the Stage in Practice
Traditional maturity should be read as a maturity indicator, not as a failure verdict. Many organisations start here because it reflects the real-world state of mixed legacy systems, manual approvals, and partial visibility.
For practitioners, the important question is whether the current control design can survive change. If access remains valid long after the business need has changed, or if one control pillar cannot inform another, the organisation is still operating in a traditional maturity pattern even if individual safeguards are strong.
A useful reference point for improving this stage is to compare current practice with a maturity framework that shows how to add visibility, policy consistency, and continuous control verification, such as OWASP SAMM for maturity-driven security improvement. For control baselines, NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls help anchor the move from isolated safeguards toward governed, repeatable control outcomes.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organizational Context | Traditional maturity reflects how security is still organized by siloed control pillars. |
| PR.AC — Identity Management, Authentication and Access Control | Static, provisioning-time privilege assumptions are central to this maturity stage. | |
| DE.CM — Continuous Monitoring | Limited visibility and slow response are defining characteristics of traditional maturity. | |
| Recommendation — Define the current trust model and align control maturity to the organisation's operating context. Tighten access decisions so they are governed by current context, not only initial provisioning. Expand monitoring so trust assumptions are continuously checked instead of periodically assumed. | ||
| CIS Controls v8 | 6 — Access Control Management | Traditional maturity often leaves access decisions manual and loosely coordinated. |
| 8 — Audit Log Management | Weak visibility is a core limitation of traditional maturity. | |
| Recommendation — Centralize access reviews and privilege changes so standing access is reduced and controlled. Collect and review logs to detect when siloed controls fail to reflect actual access state. | ||
Related resources from NHI Mgmt Group
- What is the difference between traditional security and Zero Trust maturity models?
- What is the difference between a traditional AppSec maturity model and a short-iteration assessment approach?
- Why are identity-based attacks growing faster than traditional network attacks?
- What is Agentic AI and how does it differ from traditional generative AI?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
