Why do identity tools struggle when they only see access state?

Why This Matters for Security Teams

State-only identity decisions tell you whether an account is provisioned, entitled, or certified. They do not tell you whether the account is actively chaining tools, using stale secrets, or behaving in a way that was never intended at design time. That gap is especially dangerous for NHIs and autonomous agents, where access can persist long after the original business need has changed.

NHIMG research shows the scale of the problem: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges. Those numbers help explain why tools built around static access state keep missing the real risk surface. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both emphasise that visibility, rotation, and lifecycle control matter more than static inventory alone.

In practice, many security teams discover the problem only after a leaked token, over-entitled service account, or agentic workflow has already been used to move laterally, rather than through intentional governance review.

How It Works in Practice

When identity tools only see access state, they are evaluating a snapshot. A certification platform may show that a service account belongs to the right group, but not whether its secret is still valid, whether it was copied into CI/CD, or whether the workload using it is making requests outside its normal purpose. For NHI governance, that is why visibility and lifecycle risk have to sit beside entitlements.

Modern controls shift the focus from static access state to runtime trust signals:

• Workload identity proves what the software is, not just what it can reach. Standards such as SPIFFE and short-lived OIDC tokens are often used for this purpose.
• Just-in-time credentials reduce exposure by issuing ephemeral access per task and revoking it on completion.
• Real-time policy evaluation checks the request context, target system, and workload posture before access is granted.
• Secret TTL and automatic rotation matter because a valid secret can be more dangerous than a misconfigured role.

That model aligns with current guidance in the OWASP Non-Human Identity Top 10, which treats secret hygiene, over-privilege, and lifecycle failures as primary control failures. For implementation patterns, practitioners often combine policy-as-code with workload identity federation so a tool can be trusted for a narrow action at a specific moment, rather than broadly trusted because an account exists. These controls tend to break down in legacy environments with long-lived shared credentials and no request-level telemetry because there is no reliable runtime signal to evaluate.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance security gains against deployment complexity and developer friction. That tradeoff becomes especially visible in hybrid estates, third-party integrations, and emergency access flows, where static state is easy to record but hard to keep current.

There is no universal standard for this yet, but current guidance suggests that state-only tooling should be treated as a coarse control, not a final decision engine. In agentic workflows, for example, an account may look compliant while the agent is dynamically chaining tools in a way that expands effective privilege. That is why Top 10 NHI Issues and 52 NHI Breaches Analysis both stress runtime visibility, rotation discipline, and offboarding as the controls that close the gap between entitlement and actual risk.

Edge cases also include break-glass accounts, shared automation identities, and disconnected systems that cannot support short-lived tokens. In those environments, best practice is evolving toward compensating controls such as tighter monitoring, narrower scopes, and explicit expiry enforcement, but the guidance is not fully settled. The practical rule is simple: if a tool only knows who is allowed, it will miss when the identity is no longer trustworthy.

Related resources from NHI Mgmt Group

• Why do startups struggle with identity security as they grow?
• How should growing companies reduce identity risk as they add more tools and teams?
• Why do identity programmes struggle even when they have strong visibility tools?
• How should security teams reduce the impact of DNS hijacking on identity and access paths?