The crawl, walk, run maturity model is a phased rollout approach that starts with limited, manageable use cases and expands as confidence grows. It helps teams build momentum, validate architecture, and reduce resistance to change. In access control programmes, it is often used to introduce new capabilities without overwhelming application owners.
Crawl, Walk, Run as a rollout pattern
The crawl, walk, run maturity model is not a security control itself, but a delivery pattern for introducing new capability in stages. Teams use it to start with a narrow scope, learn from early adoption, and expand only after the process is stable enough to support wider use.
The model is especially useful when a programme needs to change behaviour across many owners or systems. A staged rollout lowers the chance of disruption, makes issues easier to isolate, and gives stakeholders evidence that the new approach is workable before it becomes the default.
Why it is used in security programmes
In cybersecurity, the model is often chosen when the control touches business workflows, application ownership, or operational routines. That is why it appears often in access control and identity-related programmes: the challenge is rarely only technical, it is also adoption, policy clarity, and change management.
Crawl usually means a tightly bounded pilot with manual oversight. Walk expands coverage and begins to test repeatability. Run is the point where the capability is operating as a normal part of the control environment, with the process, ownership, and measurement mature enough for broader enforcement.
The value of the model is that it recognises maturity as earned. A team that tries to jump straight to full enforcement may create exceptions, delays, or workarounds that undermine the control before it is trusted.
How the maturity stages differ
Each stage should be understood as a deliberate increase in scope and reliability, not as a marketing label. Crawl is about proving the concept. Walk is about proving the process. Run is about proving the control can sustain itself at scale.
- Crawl: Limited use cases, close support, and frequent review.
- Walk: Broader adoption, repeatable process steps, and fewer manual interventions.
- Run: Operational normalisation, clearer governance, and routine monitoring.
The model works best when each phase has a clear exit condition. Without that discipline, “crawl” can become permanent pilot mode, or “run” can be claimed before the underlying process is dependable.
What this means for control design
For security and governance teams, the model helps align control ambition with organisational readiness. It is useful when a new control affects access decisions, approvals, ownership, or user experience and therefore needs measured introduction rather than abrupt enforcement.
OWASP SAMM is a strong adjacent reference because it treats maturity as progressive capability building, which matches the practical purpose of crawl, walk, run. For a control-centric perspective on staged adoption and baseline discipline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the kind of control structure that teams often phase in using this model.
Risk and Threat Considerations
The main risk is treating a phased rollout as a substitute for a real operating model. If the early stage lacks ownership, measurement, or an exit criterion, the programme can stall, drift into exception handling, or create inconsistent enforcement across teams.
Failure mechanism: Weak scoping or unclear stage gates can leave control coverage partial for too long, while stakeholders assume the programme is already mature. That creates exposure through uneven adoption, control bypass, and delayed remediation of issues discovered in pilot.
Impact: The organisation may end up with a control that looks deployed but does not reliably change behaviour at scale, which weakens security outcomes and can reduce confidence in future change programmes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP SAMM | Software Assurance Maturity Model | Defines staged maturity progression for security capability building. |
| Recommendation — Use staged maturity targets to expand security capability only after each phase is stable. | ||
| NIST SP 800-53 Rev 5 | AC-1 — Access Control Policy and Procedures | Phased rollout of access control needs policy, roles, and governance structure. |
| AC-2 — Account Management | Maturity rollouts often introduce account controls gradually across systems and owners. | |
| Recommendation — Phase access-control changes under documented policy and procedures before broad enforcement. Roll out account-management controls in stages and verify ownership before scaling. | ||
Practitioner Guidance
Governance implication: Define what must be true before moving from crawl to walk, and from walk to run, so the model governs change rather than simply describing it. The most useful stage criteria are usually operational, for example ownership, repeatability, and evidence of stable usage.
Practitioner takeaway: Use crawl, walk, run to reduce change friction, but keep the end state explicit. A maturity model only adds value when each stage meaningfully improves control reliability and adoption.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
