Who should use identity risk scores in an enterprise programme?

CISOs, IAM leads, SOC teams, PAM owners, and NHI practitioners should all use the same identity risk view because the attack surface now includes human accounts, service identities, API keys, and AI agents. Shared measurement makes the programme consistent across governance, detection, and enforcement.

Why This Matters for Security Teams

Identity risk scores are useful only if the programme treats identity as the control plane, not as a narrow IAM inventory. In modern enterprises, the same decision can affect a human user, a service account, an API key, a machine workload, or an AI agent, so a fragmented view creates inconsistent prioritisation. NIST’s Cybersecurity Framework 2.0 reinforces that governance, protection, detection, and response need shared measurement.

NHIMG research shows why this matters: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and that NHIs outnumber human identities by 25x to 50x in modern enterprises. That scale means risk scoring is not a reporting convenience, it is how teams decide what to fix first. In practice, many security teams discover identity sprawl only after a secrets leak or privilege misuse has already created business impact, rather than through intentional governance.

How It Works in Practice

A shared identity risk score should combine exposure, privilege, hygiene, and behaviour into one operating view. The score is then used differently by each team, but it should be calculated from the same facts. CISOs use it for programme prioritisation, IAM leads use it to drive lifecycle and access remediation, SOC teams use it to enrich detections, PAM owners use it to identify standing privilege, and NHI practitioners use it to track secrets rotation, ownership, and offboarding.

Good scoring models usually include:

• Privilege depth and breadth, especially where standing access exceeds job need.
• Secrets age, rotation status, and whether credentials are stored in unsafe locations.
• Exposure signals such as internet reachability, third-party use, or shared ownership.
• Activity anomalies, including unusual API use or dormant identities with sudden activation.
• Control coverage, for example whether the identity is governed by PAM, vaulting, or workload identity.

The strongest programmes pair scoring with a concrete response path. For example, a high-risk service identity should trigger an owner review, TTL reduction, or JIT access change, while a high-risk human account may trigger step-up authentication or access recertification. Current guidance suggests the score should be explainable, otherwise teams will not trust it enough to act. For broader NHI governance context, see the Ultimate Guide to NHIs — Key Challenges and Risks and the incident patterns in 52 NHI Breaches Analysis.

These controls tend to break down when identity data is split across IAM, CI/CD, cloud, and SaaS tools because no single team can verify whether the score reflects current reality.

Common Variations and Edge Cases

Tighter scoring often increases operational overhead, requiring organisations to balance better prioritisation against data quality and workflow friction. That tradeoff is especially visible where identity types are mixed together but not normalised.

Best practice is evolving for federated and agentic environments. There is no universal standard for weighting machine identities versus human identities yet, so organisations should define local criteria based on blast radius, privilege, and recoverability. A service account with production write access may deserve a higher score than a human account with no standing access, even if the human account has more login events. Likewise, an AI agent with tool execution authority should be treated as a governed workload identity, not as a simple user analogue.

Edge cases include shared break-glass accounts, third-party access, and ephemeral JIT credentials. Shared accounts often need separate risk treatment because ownership is indirect. Third-party identities may require supplier context in the score. Ephemeral credentials should not be judged only on lifetime, because high-frequency issuance can still represent high operational risk if approval is weak. The practical rule is simple: score the identity based on its real potential for misuse, not just on whether it belongs to a person or a system.

Related resources from NHI Mgmt Group

• When does secret exposure become a broader identity risk?
• How should security teams use risk scores in identity governance?
• How should teams start an identity governance programme without overwhelming reviewers?
• Why do non-human identities create more audit risk than human accounts?