What breaks when identity posture findings are ranked only by policy severity instead of real attack susceptibility?

Why This Matters for Security Teams

Ranking identity posture findings by policy severity alone creates a false sense of urgency. A control that looks severe on paper can be low-risk if the identity is unused, tightly segmented, or effectively dead, while a lower-severity finding on a live service account, CI/CD token, or admin-capable API key may be immediately exploitable. That gap is why attack susceptibility has to sit beside policy severity in prioritisation.

This matters most for NHIs because exposure is often invisible until adversaries probe for it. NHIMG research shows that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside secret managers in code, config files, or CI/CD tools, which makes “severity-only” triage especially misleading. The same pattern appears in breach analysis and lifecycle guidance on the 52 NHI Breaches Analysis and the Ultimate Guide to NHIs.

Current guidance from the NIST Cybersecurity Framework 2.0 favours risk-based action over raw control labels, because exploitability depends on reach, privilege, and exposure, not only on policy language. In practice, many security teams discover their most dangerous identity gaps only after an attacker has already used them to pivot, rather than during a routine severity review.

How It Works in Practice

Attack susceptibility changes the unit of prioritisation from “what policy is violated” to “what an attacker can use next.” That means evaluating whether an identity is active, reachable, privileged, externally exposed, or connected to sensitive tools. A dormant account with a severe policy miss may be a lower priority than a low-severity finding on a token that can authenticate to production, read secrets, or invoke deployment workflows.

A practical ranking model usually combines several signals:

• Exposure: internet-facing, partner-facing, or internal-only
• Privilege: read-only, write, admin, or delegated escalation paths
• Usage: active, infrequent, dormant, or orphaned
• Secret quality: long-lived static credentials versus short-lived, rotated secrets
• Blast radius: which systems, data, or pipelines the identity can reach
• Exploit path: whether chaining from that identity is feasible using known attacker tradecraft

That is why frameworks such as MITRE ATT&CK Enterprise Matrix are useful alongside NHI governance, because they help teams think in terms of attacker behaviour rather than policy abstractions. For NHI-specific context, the OWASP NHI Top 10 and the Top 10 NHI Issues both reinforce that privilege, lifecycle gaps, and secret sprawl create more immediate exposure than severity labels alone suggest.

In practice, teams should route findings into an exposure score, then validate it against telemetry such as last use, reachable assets, token TTL, and privilege pathways. These controls tend to break down in sprawling CI/CD environments where service accounts are reused across projects and the real access path is hidden in pipelines, not in the identity record itself.

Common Variations and Edge Cases

Tighter ranking by attack susceptibility often increases analyst effort, requiring organisations to balance speed of triage against the cost of collecting better context. That tradeoff is worth making, but current guidance suggests it should be implemented selectively first, especially for high-value identities and externally reachable systems.

Some environments distort the signal. In highly regulated environments, a severe policy finding may still need to stay elevated even when exploitability looks low, because audit impact and control failure matter. In contrast, mature engineering organisations often find that low-severity secrets leakage on a deployment bot outranks many policy-heavy findings because the bot can touch production directly.

There is no universal standard for this yet, but best practice is evolving toward context-aware prioritisation that blends policy severity, exploitability, and business impact. If the team cannot answer “can an attacker actually use this identity today?”, severity scoring alone is not enough. The safest assumption is that stale or over-privileged NHIs will be targeted first, especially where incident response is slow or offboarding is incomplete, as described in the Ultimate Guide to NHIs — Key Challenges and Risks and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

Related resources from NHI Mgmt Group

• What breaks when identity posture findings are not correlated across the stack?
• What breaks when vulnerability findings are treated as isolated issues instead of attack paths?
• What is the difference between attack surface management and NHI governance?
• When does a machine identity become a compliance problem?