TL;DR: Traditional identity programmes cannot keep pace with rapid change, according to READI, and an Agile Identity approach is meant to deliver incremental automation and better outcomes. The governance challenge is not speed alone but whether identity teams can modernise access and operational control without losing consistency or oversight.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on READI's blog post: Identity programmes that rely on waterfall delivery struggle to keep pace with change, while incremental automation shifts the debate to governance, consistency and measurable outcomes.
Why it matters: This matters because IAM, IGA and PAM teams need delivery models that can absorb change without weakening access governance across human, non-human and machine-driven workflows.
Context
Identity programmes often fail when delivery methods assume stable requirements, long projects and predictable change windows. In practice, access requests, onboarding, remediation and connector work move faster than that model allows, especially where human identities, service accounts and application estates change at different speeds.
Agile Identity is best understood as an operating approach, not a product category. It shifts the focus from big-bang transformation to smaller governance increments, which can help teams reduce backlog drag and modernise controls without waiting for a complete programme reset.
Key questions
Q: How can identity teams modernise governance without a big-bang programme?
A: Identity teams can modernise governance by moving in governed increments, such as onboarding one application, one entitlement cluster, or one access review cycle at a time. That keeps joiner-mover-leaver controls, role models, certifications, and privileged access reviews working while legacy integrations are replaced or refined. It also reduces cutover risk and makes ownership, exceptions, and remediation visible early.
Q: Why do waterfall identity programmes struggle with changing applications?
A: Waterfall identity programmes struggle because applications, entitlements, owners, connectors, and data sources change faster than a fixed design can absorb. By the time the target state is delivered, account structures or access models have often shifted, so provisioning rules and certification scopes no longer match reality. That creates rework, missed entitlements, and brittle integrations.
A: Security teams should connect nonstandard applications to their identity provider through automation, then standardise access workflows around onboarding, password handling, offboarding, and multifactor enrollment. The goal is to reduce manual compensating controls, improve visibility, and keep identity governance consistent across legacy, on-premises, OT, and cloud systems that do not natively support SAML or SCIM.
Q: How should teams govern authorization for service accounts and other machine identities?
A: Treat machine identities as governed actors that still need explicit access decisions, logging, and review. The credential may come from the identity provider, but the allowed action set must be defined in a separate policy model that applies consistently across workloads and tenants.
Technical breakdown
Why waterfall identity delivery breaks down
Waterfall delivery assumes requirements can be fixed early, then executed through a long build-and-release cycle. Identity work rarely behaves that way because connectors, entitlements, access exceptions and application owners change continuously. The result is a governance gap between policy intent and the current state of access. In identity programmes, that gap shows up as stale integrations, delayed onboarding and remediation backlogs that grow faster than teams can absorb them. See the Entitlement Catalogue and Application Onboarding Guide.
Practical implication: Treat identity delivery as a continuous governance stream, not a one-time implementation project.
Incremental automation changes the governance model
Automation in identity is not just about reducing manual effort. It changes how control is delivered, because small automations can close narrow operational gaps without waiting for an enterprise-wide replatform. That matters where identity governance spans humans, service accounts and disconnected systems. When automation is deployed incrementally, teams can validate control coverage, refine rules and reduce operational risk in smaller steps rather than betting everything on a single release. See the Identity Security Programme Guide.
Practical implication: Prioritise automations that close the highest-friction access workflows first, then expand coverage in governed increments.
Agile identity depends on application onboarding discipline
Agile delivery only works when the governance model can absorb new systems quickly and consistently. That means entitlement definitions, ownership, connector quality and baseline access models must be captured early enough to support repeatable onboarding. Without that discipline, speed creates inconsistency instead of control. The central question is not whether applications can be connected, but whether they can be brought under a durable governance pattern as the environment changes. See the IGA Buyer's Guide.
Practical implication: Standardise onboarding inputs so new applications enter governance with usable ownership, entitlement and baseline data.
NHI Mgmt Group analysis
Agile identity is a governance operating model, not a delivery slogan. Identity teams do not need more movement for its own sake. They need a way to turn fragmented access work into governed increments that can be measured, reviewed and improved. That is especially relevant where human IAM, NHI controls and application onboarding overlap, because each domain changes on a different cycle and fails in a different way. Practitioners should treat agility as a control delivery method, not a replacement for control design.
The real constraint is backlog, not intent. Most identity programmes already know what they need to improve. What slows them down is the volume of connector work, entitlement cleanup, access exceptions and remediation tasks that never fit neatly into a waterfall plan. Incremental delivery can reduce this drag, but only if teams keep ownership, scope and acceptance criteria explicit. The practical outcome is faster governance throughput without sacrificing auditability or accountability.
Agile methods expose weak identity operating discipline faster. If ownership, entitlement data and onboarding standards are unclear, a faster delivery model simply amplifies the mess. That makes agile identity useful as a governance stress test: it reveals where programme design depends on heroics rather than repeatable controls. The organisations that benefit most are the ones prepared to standardise governance inputs before accelerating delivery.
Machine and service identities make the case for continuous identity delivery stronger. Human access reviews are already difficult to keep current, but NHI estates add more volume, more automation and more change. That is why service accounts, API keys, OAuth tokens, certificates need governed lifecycle handling rather than ad hoc remediation. Teams that can incrementally extend governance to these assets will be better positioned to control scope, ownership and drift as environments keep changing.
What this signals
Agile identity will increasingly be judged by control consistency, not delivery velocity. Faster change is only useful if access governance stays legible to auditors, operators and application owners. Teams that use agile methods to shorten remediation cycles and standardise onboarding will gain more resilience than teams that simply move faster.
The next governance gap is cross-domain consistency. Identity teams will need to align human access, NHI lifecycle controls and application onboarding so that the programme does not fragment into separate delivery lanes. That is where identity programme discipline matters most: it gives agile delivery a structure that can survive changing application estates and rising machine identity volume.
For practitioners
- Define a phased identity delivery roadmap Break the programme into small governance releases that target the most painful access, onboarding and remediation gaps first.
- Standardise onboarding data before automating Require ownership, entitlement and baseline access fields before new applications enter the onboarding queue.
- Measure backlog reduction as a control outcome Track how automation changes queue length, remediation time and access consistency, not just how many tasks were automated.
- Extend governance to non-human identities Apply the same lifecycle discipline used for human access to service accounts, API keys, certificates and other machine credentials.
- Use IGA as the control backbone Anchor agile delivery in identity governance so changes still follow approval, entitlement and review discipline.
Key takeaways
- Identity programmes lose effectiveness when they are built for stable requirements but operated in environments that change continuously.
- Incremental automation can improve governance, but only when ownership, entitlement data and onboarding discipline stay explicit.
- Agile delivery helps most when it is used to standardise identity controls rather than to simply increase output.
Related NHI Mgmt Group resources: Identity Security Programme Guide · IGA Buyer's Guide · Entitlement Catalogue and Application Onboarding Guide · Ultimate Guide to NHIs: What are Non-Human Identities
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 addresses the attack and risk surface, while 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.PO-01 — Policy Establishment | Agile identity depends on an operating policy that governs how controls are delivered incrementally. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post centres on access governance and entitlement control across changing application estates. | |
| Recommendation — Define identity delivery policy so governance changes remain consistent across iterative releases. Use entitlement governance to keep identity changes aligned with current access needs. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity modernisation still depends on disciplined account lifecycle and ownership control. |
| Recommendation — Apply account management discipline to every identity workflow you automate. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article touches NHI lifecycle governance, where stale identities are a recurring control gap. |
| NHI-05 — Overprivileged NHI | Incremental governance is meant to reduce excessive access that accumulates during slow delivery. | |
| Recommendation — Track non-human offboarding as a governed lifecycle step, not an ad hoc cleanup task. Audit NHI privilege scope whenever agile releases change application access patterns. | ||
Key terms
- Agile Identity: Agile Identity is an iterative approach to identity and access management delivery. It breaks governance, provisioning, access review, and role design into small, tested increments so teams can adapt to changing applications, owners, and access models without waiting for a single large release.
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
- Application Onboarding: Application onboarding is the process of bringing an application into an organization’s identity, security, and governance controls before it is put into use. It typically includes inventory, ownership assignment, access model design, credential setup, logging, policy mapping, and approval workflows so the application can be managed securely throughout its lifecycle.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and identity lifecycle controls. It gives identity and security practitioners a common foundation for governing access across human and non-human estates.
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org