How should security teams quantify identity risk in mature environments?

Why This Matters for Security Teams

Identity risk becomes meaningful only when it is measured against real exposure, not headcount or license counts. Mature environments often have thousands of service accounts, API keys, certificates, and workload identities that outnumber human users by orders of magnitude, so a small percentage of unmanaged identities can still create a large blast radius. NHI Management Group’s Ultimate Guide to NHIs notes that NHIs can outnumber human identities by 25x to 50x in modern enterprises, which is why inventory quality matters more than raw volume.

Security teams should treat identity risk as a composite of privilege, usage, lifecycle drift, and detection gaps. The right benchmark is not whether an identity exists, but whether it is still needed, how it is authenticated, what it can reach, and whether its activity is observable. This maps closely to the control logic in the NIST Cybersecurity Framework 2.0, where asset visibility and protective controls must be measurable before they can be improved. In practice, many security teams discover identity risk only after an audit finding, a secrets leak, or a compromise, rather than through intentional risk modelling.

How It Works in Practice

Quantifying identity risk starts with building a defensible inventory. Mature programmes separate human users from non-human identities, then assign each identity a record for owner, purpose, privilege scope, lifecycle state, and last observed use. That distinction matters because the same credential can be low-risk in a lab and high-risk in production, depending on where it is used and what it can access. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames the common failure mode: organisations know they have secrets, but not where those secrets are active.

A practical scoring model usually combines several factors:

• Privilege breadth: standing admin rights, cross-environment access, or access to production data increase risk.
• Exposure: identities embedded in code, CI/CD, third-party integrations, or shared vaults are easier to misuse.
• Age and rotation: long-lived credentials increase dwell time and reduce recovery speed.
• Usage confidence: identities that have not been seen recently may be dormant, orphaned, or shadow IT.
• Detection coverage: if auth logs, token issuance, or workload telemetry are missing, risk is undercounted.

Many teams then map this to a simple formula such as risk = privilege x exposure x uncertainty, with weighting adjusted for business criticality. This is not a universal standard yet, but current guidance suggests that repeatable weighting is better than ad hoc judgments because it forces consistency across business units. The Top 10 NHI Issues also helps when triaging which identity classes deserve immediate attention, especially when service accounts and API keys have no clear owner. These controls tend to break down when telemetry is fragmented across cloud, SaaS, and on-premises systems because the same identity may appear legitimate in one control plane and invisible in another.

Common Variations and Edge Cases

Tighter identity scoring often increases operational overhead, requiring organisations to balance measurement accuracy against the cost of collecting, normalising, and reviewing identity data. That tradeoff is especially visible in mature environments with multiple clouds, M&A inheritance, and outsourced development.

One common edge case is workload identity. A service account used by a Kubernetes workload, a CI job, and a legacy batch process may look like one identity on paper but behave like three separate risk profiles in practice. Another is shared credentials in automation pipelines, where owner assignment is unclear and usage patterns do not map neatly to a single business unit. Best practice is evolving toward context-sensitive scoring that updates when identities change privilege, location, or authentication method.

NHIMG research shows why this matters: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts. That combination means mature environments often have enough data to create a risk score, but not enough confidence to treat it as static. The right answer is to recalculate often, tie scores to remediation ownership, and treat orphaned or unobserved identities as elevated risk until proven otherwise.

Related resources from NHI Mgmt Group

• Why do ERP environments increase identity risk for security teams?
• How should security teams quantify identity risk for board reporting?
• How do security teams know whether identity governance is reducing risk?
• How should security teams use ISPM to reduce identity risk?