What breaks when risk software tracks apps but not the identities behind them?

Why This Matters for Security Teams

Risk software that inventories applications but not the identities behind them creates a false sense of control. The real exposure usually sits in service accounts, API keys, workload tokens, and delegated permissions that can outlive the app, move with the app, or be reused by something else entirely. That gap matters because application risk scores do not show who can act, what they can reach, or how fast privilege can spread.

Current guidance suggests this is not a visibility-only problem. NHI Management Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, yet only 5.7% of organisations report full visibility into their service accounts in the Ultimate Guide to NHIs. That is why app-centric dashboards often miss the assets that attackers actually abuse. The control failure is not the score itself, but the missing ownership, lifecycle, and revocation path for non-human identities. In practice, many security teams encounter the compromise after secrets are reused or delegated access has already expanded beyond the original application boundary.

How It Works in Practice

Effective risk tracking needs an identity layer that maps every application to the credentials, tokens, service accounts, and roles it depends on. Without that map, a scanner may show that an app is exposed, but it cannot tell whether the risk comes from a dormant API key, an overprivileged CI/CD token, or a workload identity that was never revoked. That is why app inventory alone is not enough for NHI governance.

Practitioners usually need to connect application telemetry with identity telemetry. In mature programmes, that means:

• Linking apps to owners, service accounts, and secret stores.
• Classifying each non-human identity by privilege scope, TTL, and business function.
• Tracking where a token is used, not just where the app is deployed.
• Reviewing delegated permissions separately from application risk ratings.
• Revoking orphaned identities when the application changes, not only when it is retired.

This approach aligns with the identity-first posture in the Top 10 NHI Issues and with the asset, risk, and access management focus in the NIST Cybersecurity Framework 2.0. It also fits the basic principle that risk should be tied to what can actually execute, not just to what is installed or catalogued. Where this breaks down is in distributed environments with shadow CI/CD, unmanaged integrations, and third-party automations, because identity ownership becomes fragmented across teams and tools.

Common Variations and Edge Cases

Tighter identity tracking often increases operational overhead, requiring organisations to balance better privilege control against the cost of maintaining accurate ownership data. That tradeoff is real, especially when legacy systems, shared service accounts, and vendor-managed workflows were never designed for per-identity accountability.

There is no universal standard for this yet, but current guidance suggests starting with the highest-risk identities first: keys with broad permissions, tokens used across multiple environments, and accounts that cannot be tied to a named owner. For agents, automation, or ephemeral workloads, the preferred model is to treat the workload identity as the unit of control and to attach context such as environment, task, and session duration. For older platforms, that may require compensating controls like stronger rotation, tighter vault policy, and more frequent access recertification.

Two NHIMG references are especially useful here: the Ultimate Guide to NHIs — Key Challenges and Risks and the Ultimate Guide to NHIs — Why NHI Security Matters Now. These help distinguish between a software asset that is merely exposed and an identity that can actually be abused. The main edge case is shared infrastructure, where multiple applications legitimately use the same service account; in those environments, the goal is not perfect one-to-one mapping, but enough attribution to revoke access without breaking production.

Related resources from NHI Mgmt Group

• What breaks when GRC software does not cover non-human identities?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?