Why do identity programmes stall even when organisations buy modern tools?

Why This Matters for Security Teams

Identity programmes stall when organisations confuse procurement with progress. A modern platform can improve provisioning, policy enforcement, and reporting, but it cannot invent ownership, data quality, or a consistent access model. That is why maturity often looks better in dashboards than in operations. The same gap appears in NHI environments, where Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, while 68% of organisations do not know how to fully address NHI risks.

The practical problem is that identity spans people, service accounts, secrets, API keys, and now autonomous workloads. When those domains are managed through separate teams and inconsistent rules, every new tool becomes another layer on top of fragmented process. Standards such as the NIST Cybersecurity Framework 2.0 still depend on clear governance, defined roles, and repeatable control execution. In practice, many security teams encounter stalled identity programmes only after a breach, audit failure, or cloud sprawl has already exposed the lack of operating discipline.

How It Works in Practice

Tooling helps only when the programme has a working baseline. That means a defined owner for each identity type, a current inventory, a common request and approval model, and an enforcement path that matches how access is actually used. Without that foundation, IGA, PAM, secrets managers, and directory tools all end up automating different versions of the same manual mess.

For NHI-heavy environments, the baseline needs to include secrets lifecycle controls, rotation, offboarding, and visibility into service accounts and machine credentials. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and only 5.7% have full visibility into their service accounts. Those gaps explain why many programmes appear to modernise while still leaving dormant credentials, stale privileges, and unmanaged access paths in place.

• Start with identity classification: human, service, workload, API, and privileged access should not share the same control model.
• Assign one accountable owner per identity class so remediation is not lost between platform, app, and infrastructure teams.
• Normalise access requests around business function, not tool-specific workflows, so approvals can be repeated and audited.
• Use the platform to enforce decisions already defined in policy, rather than hoping the platform will define policy for you.

That operating model aligns with Top 10 NHI Issues, which highlights the recurring failure modes behind machine identity sprawl, and with NIST guidance that ties cyber outcomes to governance and continuous improvement. Where identity data is incomplete, ownership is disputed, or applications issue credentials outside central controls, even a strong platform cannot produce reliable outcomes.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance automation gains against the friction of change management. That tradeoff becomes especially visible in hybrid estates, acquired businesses, and software delivery pipelines where teams have historically managed access locally. Best practice is evolving, but there is no universal standard for how fast every identity domain should be converged.

Some programmes stall because they over-focus on employees and ignore NHIs, while others buy secrets tooling but never address policy ownership or revocation discipline. In high-change environments, short-lived credentials and just-in-time access can reduce standing exposure, but only if applications can tolerate ephemeral tokens and teams can actually rotate dependencies. Where legacy systems require hard-coded credentials, the programme often needs a staged migration plan rather than a full platform switch.

Another common edge case is agentic AI access. Autonomous agents create action at runtime, so static role design can lag behind actual behaviour. In those environments, the right question is not whether the tool supports a checkbox feature, but whether the organisation can make runtime decisions, monitor tool use, and revoke access quickly when intent changes. If that operating model is missing, modern tooling mainly accelerates existing fragmentation.

Related resources from NHI Mgmt Group

• Why do identity programmes struggle even when they have strong visibility tools?
• Why do identity security programmes stall in large organisations?
• How should organisations keep identity security training current as their environment changes?
• How do organisations prove identity governance is improving business agility?