How do organisations know their IAM operating model is no longer scaling?

Why This Matters for Security Teams

When an IAM operating model stops scaling, the issue is usually not a single broken control. It is structural: the organisation has more identities, more applications, more exceptions, and more review work than its current governance model can absorb. That is especially visible in non-human identity environments, where service accounts, API keys, and automation tokens often grow faster than oversight. NHIMG research notes that only 5.7% of organisations have full visibility into their service accounts, which explains why scaling failures often show up first as blind spots rather than outages. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity governance as a continuous operating capability, not a one-time project.

The practical signal is not simply that teams are busy. It is that work is being spent repeatedly reconciling entitlements, proving compliance, and chasing exceptions instead of improving control quality. As fragmentation grows, the IAM function becomes a manual coordination layer rather than a policy engine. In practice, many security teams encounter this only after access review queues, break-glass requests, and secrets sprawl have already become normalised.

How It Works in Practice

An IAM model is usually reaching its limit when the same control must be implemented differently across too many systems, clouds, and application patterns. At that point, policy decisions depend on human intervention instead of consistent automation. The failure is often not the policy itself, but the operating model around it: duplicated approval chains, disconnected identity stores, and inconsistent lifecycle ownership.

For non-human identities, scaling pressure appears when static credentials and long-lived access no longer match the pace of workloads. NHIMG data shows that 97% of NHIs carry excessive privileges, which is a strong indicator that access provisioning is drifting away from actual usage. A healthier model shifts toward central policy definition, automated entitlement assignment, and time-bound access that can be issued and revoked without manual handoffs.

Teams should look for these operational signals:

• Access reviews are taking longer each cycle, even after adding more reviewers.
• Exception volumes are rising faster than the underlying control framework is changing.
• Admin work is dominated by reconciliation across directories, vaults, and ticketing systems.
• Policy owners cannot explain which systems enforce the authoritative source of truth.
• Secrets and service accounts are being managed as isolated assets rather than lifecycle-governed identities.

These patterns align with current guidance from NIST CSF 2.0 and with NHIMG’s broader NHI governance guidance in Ultimate Guide to NHIs, both of which emphasise repeatable control ownership, visibility, and lifecycle discipline. These controls tend to break down when identity sprawl is spread across legacy apps, cloud-native services, and ad hoc automation, because each environment creates its own exceptions and none of them share a common operating rhythm.

Common Variations and Edge Cases

Tighter IAM governance often increases short-term operational overhead, so organisations have to balance control centralisation against delivery speed. That tradeoff becomes more obvious in platform engineering, M&A integration, and hybrid cloud estates where teams have inherited different access models. Best practice is evolving, and there is no universal standard for exactly when a model is “too fragmented,” but sustained exception growth and review backlog are reliable warning signs.

One common edge case is that teams believe the model is scaling because tooling coverage has expanded, while the real bottleneck is human approval flow. Another is that service accounts are treated as low-risk because they are non-interactive, even though NHIMG research links secrets exposure to privilege escalation risk, including Azure Key Vault privilege escalation exposure. That is why maturity assessments should look at operational load, not just policy count.

Org changes can also distort the signal. A temporary spike after a cloud migration or acquisition does not always mean the model is failing. The stronger indicator is whether the organisation can absorb change without permanently increasing manual reconciliation. If every new system requires a bespoke exception path, the operating model has already outgrown its design.

Related resources from NHI Mgmt Group

• How do organisations know whether their SSO operating model is working?
• Why do AI assistants change IAM and IGA operating models?
• How do organisations know whether access request automation is working properly?
• How should organisations govern model selection for AI agents?