Why do security leaders struggle to quantify risk across modern identity and threat environments?

Why This Matters for Security Teams

Quantifying risk across identity and threat environments is difficult because the evidence needed to justify priority is rarely held in one place. Access logs, privileged activity, cloud events, application telemetry, and third-party or agent activity often live in separate systems with different owners and different retention rules. That creates a reporting gap: leaders may know there is exposure, but not whether it is concentrated, persistent, or actively exploited.

This becomes more serious when non-human identities, service accounts, API keys, and AI agents are part of the environment. Those identities can move faster than human review cycles and may be invisible to traditional access recertification. Current guidance from the NIST Cybersecurity Framework 2.0 supports a more outcome-based view of governance, but the practical challenge is that most organisations still measure controls in silos rather than measuring risk as a connected system.

Security leaders also struggle because “risk” is often discussed as a board metric while the underlying data is operational. Without a consistent method for linking identities, privileges, assets, and threat activity, the numbers can look precise while the interpretation remains weak. In practice, many security teams only discover how fragmented their risk picture is after a privileged account, token, or AI-enabled workflow has already widened the blast radius.

How It Works in Practice

The most reliable approach is to build a shared risk model that connects identity posture to threat signals and business impact. That means correlating who or what the identity is, what it can access, how that access is used, and whether the surrounding environment shows signs of abuse. For modern environments, the model should include human users, privileged administrators, service accounts, machine identities, and AI agents with execution authority.

A practical workflow usually includes:

• Normalising identity inventory across IAM, PAM, cloud, and application systems.
• Mapping privileges to critical assets and sensitive data paths.
• Adding detection context from SIEM, EDR, XDR, and cloud telemetry.
• Tracking high-risk patterns such as standing privilege, stale access, anomalous token use, and unusual API activity.
• Using qualitative severity bands where quantitative confidence is weak, rather than pretending precision exists.

For AI-related environments, the risk picture must also account for model and agent behaviour. The MITRE ATLAS adversarial AI threat matrix is useful when mapping prompt injection, model manipulation, and tool abuse to observable control failures. Likewise, reports such as the Anthropic — first AI-orchestrated cyber espionage campaign report show why AI-enabled attack paths cannot be assessed with legacy identity metrics alone.

Teams that want a defensible risk narrative often anchor the operating model in control families from NIST Cybersecurity Framework 2.0 and then map supporting technical controls from NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down in highly federated environments with multiple tenants, inconsistent logging, and unmanaged machine identities because the attribution chain is incomplete.

Common Variations and Edge Cases

Tighter risk quantification often increases integration and governance overhead, requiring organisations to balance decision quality against reporting speed. That tradeoff becomes more visible in environments with frequent mergers, partner access, or rapid adoption of AI tooling.

There is no universal standard for turning identity telemetry into a single risk score. Some teams use control effectiveness scoring, while others weight risk by asset criticality, attack likelihood, and exploitability. Current guidance suggests that the best answer is not one metric, but a small set of linked measures that explain exposure, detection confidence, and response readiness.

Edge cases matter. A cloud workload with broad API permissions may represent more risk than a named employee with the same nominal role, especially if the workload is tied to automation or an agentic process. Likewise, a dormant account may look harmless until it is used in a supply chain compromise or credential replay event. When incidents are unfolding quickly, teams should pull authoritative context from sources such as CISA cyber threat advisories rather than relying only on internal dashboards.

For organisations that operate AI-enabled controls, governance is still evolving. Risk quantification should include model provenance, approval boundaries, and tool-use restrictions, but the industry has not reached consensus on a single measurement standard yet. The practical objective is to make uncertainty visible, not to hide it behind a polished score.

Related resources from NHI Mgmt Group

• How should security teams quantify identity risk in mature environments?
• How should security teams unify identity across cloud and data center environments?
• Why do hybrid identity environments create more audit and security risk than single-directory setups?
• How should security teams reduce insider threat risk in cloud environments?