Because a score can ignore the context that makes identity risky in practice. Standing privilege, poor rotation, shared credentials, and weak offboarding all change the true exposure of an account or secret. Without that context, the score may look precise while missing the conditions that actually let an attacker persist or move laterally.
Why This Matters for Security Teams
Risk scores are useful for triage, but they are not a substitute for identity context. An account with a low score can still be highly exposed if it has standing privilege, long-lived secrets, weak offboarding, or cross-system reuse. That gap matters because identity compromise often becomes the fastest route to persistence and lateral movement, especially when controls look compliant on paper but are weak in practice. The NIST Cybersecurity Framework 2.0 places clear emphasis on governance, access control, and resilience, which is the right lens for identity risk rather than relying on a single numerical score.
Security teams often get misled when scoring models treat every account as if it had the same blast radius. A helpdesk account with broad reset rights, a service account with no rotation, and a shared admin login may all score differently, yet the real exposure may be the reverse of what the score implies. In practice, many security teams encounter identity risk only after an abuse path has already been used, rather than through intentional exposure modelling.
How It Works in Practice
Effective identity risk assessment starts by combining static attributes with operational context. Static attributes include account type, privilege level, MFA status, password age, and whether a secret is managed centrally. Operational context includes where the identity can be used, what systems it can reach, whether it is shared, whether it is tied to automation, and whether offboarding actually revokes access everywhere it matters. This is why score-only approaches often miss the difference between an account that is merely active and one that is operationally dangerous.
Current guidance suggests aligning score inputs to the ways attackers actually abuse identity. For example, valid credentials, excessive privileges, and poor lifecycle controls are repeatedly present in real intrusions, including AI-assisted operations described in the Anthropic — first AI-orchestrated cyber espionage campaign report. That does not mean every environment needs the same scoring model, but it does mean the model should distinguish between exposure and mere presence.
- Weight standing privilege higher than routine access, especially for admin, break-glass, and automation identities.
- Track secret hygiene, including rotation cadence, storage location, and whether the secret is reused elsewhere.
- Include lifecycle signals such as termination lag, dormant accounts, and orphaned access paths.
- Measure actual reach, not just assigned role, because inherited permissions and token delegation often expand exposure.
In practice, the best results come from feeding scoring engines with identity governance data, PAM telemetry, and cloud or SaaS entitlement context, then validating the score against known abuse paths. These controls tend to break down when identity data is fragmented across directories, PAM, SaaS apps, and cloud platforms because the scoring model cannot see the full privilege chain.
Common Variations and Edge Cases
Tighter identity scoring often increases operational overhead, requiring organisations to balance signal quality against the cost of collecting and normalising identity data. That tradeoff becomes visible when teams try to score every account the same way, even though human users, service accounts, AI agents, and shared integrations behave very differently.
Best practice is evolving for agentic and machine identities. There is no universal standard for this yet, but current guidance suggests treating autonomous software identities as high-consequence entities when they can call tools, move data, or create new credentials. A low numerical score may be misleading if the agent can trigger privileged workflows, even when the account itself appears limited.
Edge cases also appear during mergers, temporary vendor access, and emergency access programs. A vendor account may look low risk because it is time-bound, but if it has broad access during a sensitive integration window, the practical exposure may be high. Likewise, an account can score safely until an unreviewed trust relationship, API token, or delegated refresh credential expands its reach. That is why identity exposure should be scored alongside control effectiveness, not instead of it.
For teams building a more defensible model, the right question is not whether the score is high or low, but whether it reflects privilege, reach, and revocation reality. When those factors are missing, the score becomes a reporting metric rather than a security control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.AM-01 | Asset and identity visibility is needed before exposure can be scored accurately. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Non-human identities often have hidden exposure through tokens, secrets, and delegation. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems can turn a low-risk account into a high-impact execution path. |
Inventory identities and access paths so scores reflect actual exposure, not just directory records.
