What is the difference between counting identity violations and prioritising exploitable risk?

Why This Matters for Security Teams

Counting identity violations is a useful inventory exercise, but it does not tell a defender which identities are most likely to be abused next. Prioritising exploitable risk shifts the focus to reach, privilege, exposure, and recent change, which is closer to how attackers actually operate. That distinction matters because large identity estates often contain many low-value misconfigurations alongside a few pathways that can lead directly to data access, lateral movement, or privilege escalation.

This is why NHIMG research repeatedly emphasizes that raw counts can hide the identities that matter most. In the Ultimate Guide to NHIs, NHIMG notes that 97% of NHIs carry excessive privileges, which shows how common a high-risk posture can be even when a control tally looks manageable. Security teams that only count violations often optimise reporting, not reduction of compromise likelihood. The better question is which identity failure creates a realistic path to misuse today, not how many findings appear in the backlog.

NIST Cybersecurity Framework 2.0 and 52 NHI Breaches Analysis both reinforce the same operational lesson: exposure, not volume, is what drives incident potential. In practice, many security teams discover the difference only after a low-count but high-privilege identity becomes the shortest path to compromise.

How It Works in Practice

A risk-based queue starts by scoring each identity issue against exploitability signals, not just policy violations. For non-human identities, that usually means asking four practical questions: does the identity have meaningful reach, is the credential still live, has the behaviour changed recently, and can the identity chain into other systems? This is where simple compliance scoring breaks down, because the same violation can be harmless in one service account and critical in another.

Operationally, teams should combine static facts with runtime context. Static facts include privilege scope, secret age, number of attached resources, and whether the identity is internet-facing. Runtime context includes recent authentication anomalies, tool usage, failed access attempts, and whether the identity sits on a path to production data. NIST guidance on control assessment and prioritisation supports this kind of layered view, especially when paired with the NIST SP 800-53 Rev. 5 Security and Privacy Controls approach to selecting controls proportional to impact.

• Rank identities by blast radius, not by finding count alone.
• Give higher priority to secrets that are long-lived, exposed, or reused across systems.
• Escalate issues where privilege has expanded faster than ownership or review processes.
• Separate hygiene debt from active exploitation paths so remediation teams do not treat them the same.

That operational model aligns with the kind of evidence-based visibility described in Top 10 NHI Issues and with the governance emphasis in the Ultimate Guide to NHIs. These controls tend to break down when identity ownership is unclear and telemetry is fragmented across SaaS, CI/CD, and cloud accounts because the scoring engine cannot see the full attack path.

Common Variations and Edge Cases

Tighter risk ranking often increases operational overhead, requiring organisations to balance better prioritisation against data quality and analyst capacity. That tradeoff becomes visible in environments with thousands of ephemeral workloads, shared service accounts, or delegated admin models, where a simple count is easy to generate but a trustworthy exploitability score is harder to maintain.

There is no universal standard for this yet, so current guidance suggests using risk ranking as a decision aid rather than a replacement for control reporting. Some teams still need violation counts for audit, trend analysis, and governance dashboards. The practical mistake is to make count the only metric. A low-count queue can still hide a high-risk identity if the asset is internet-facing, has privileged tokens, or can reach sensitive APIs through automation.

Edge cases matter most where identities are short-lived, externally integrated, or shared across pipelines. In those environments, a single stale secret or overbroad token may be less visible in aggregate reporting but far more exploitable in practice. NHIMG’s research on breach patterns in the 52 NHI Breaches Analysis shows why prioritisation should follow the attack path, not the spreadsheet row. The best practice is to treat counts as inventory and exploitable risk as the remediation queue.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• When does secret exposure become a broader identity risk?