CVSS can understate or overstate risk when the affected asset is not exposed, when controls already reduce attack paths, or when threat actors are actively exploiting a lower scored issue. Organisations should treat CVSS as a starting point, then adjust priorities using asset context, threat intelligence, and whether the vulnerable component is reachable.
Why This Matters for Security Teams
CVSS is useful for describing technical severity, but it does not tell a security team whether a flaw is reachable, actively exploited, or already neutralised by compensating controls. That is why a medium score can become a top priority in one environment and a high score can remain low risk in another. NIST’s Cybersecurity Framework 2.0 and NHI-focused guidance from Top 10 NHI Issues both reinforce the same operational truth: risk must be assessed in context, not from score alone.
This matters because exploitability changes with exposure, identity paths, and the surrounding control plane. A vulnerability in an internet-facing service, a secrets store, or an API-backed workload identity can become materially worse than its score suggests. A flaw buried behind segmentation, strong PAM, and tight allowlists may be far less urgent. In practice, many security teams encounter the mismatch only after attackers have already selected the easiest reachable path, rather than through intentional prioritisation.
How It Works in Practice
Teams should treat CVSS as one input in a broader triage workflow. The score describes characteristics of the vulnerability, but operational risk depends on whether the asset is exposed, whether an attacker can chain it with other weaknesses, and whether the issue sits on a path to secrets, tokens, or privileged actions. That is why mature programmes combine CVSS with asset criticality, reachability, exploit intelligence, and identity posture. CISA cyber threat advisories help determine whether a lower-scored issue is being weaponised in the wild.
For NHIs, the same flaw can vary dramatically in risk depending on how credentials are issued and where they are stored. A service account with broad standing permissions is more dangerous than the same service account constrained by JIT access, short-lived tokens, and workload identity controls. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks shows why secrets sprawl and over-permissioning amplify ordinary weaknesses into real incidents. Pair that with NIST SP 800-53 Rev 5 Security and Privacy Controls to map compensating controls such as segmentation, monitoring, and least privilege.
- Check whether the vulnerable component is reachable from an attacker-controlled path.
- Validate whether compensating controls block exploitation or reduce blast radius.
- Adjust priority if threat intelligence shows active exploitation or mass scanning.
- Escalate issues that expose secrets, tokens, or privileged identity workflows.
This guidance tends to break down in highly dynamic cloud and CI/CD environments because reachability, permissions, and exposed secrets can change faster than the vulnerability queue is refreshed.
Common Variations and Edge Cases
Tighter scoring often increases process overhead, requiring organisations to balance speed against the cost of manual context gathering. Current guidance suggests that this tradeoff is unavoidable in environments with many ephemeral assets, but there is no universal standard for how much contextual adjustment should override CVSS.
One common edge case is a low-scored issue on a system that indirectly protects high-value identities. For example, a flaw in a developer tool, pipeline plugin, or secrets broker may look minor until it is used to steal credentials or modify deployment logic. NHIMG’s JetBrains GitHub plugin token exposure and DeepSeek breach illustrate how exposed secrets and adjacent infrastructure can turn a technical weakness into an identity compromise.
Another edge case is when runtime protection reduces practical risk even though the score remains high. Network isolation, mTLS, policy enforcement, and rapid token revocation can shrink exposure materially, but only if they are actually enforced on the relevant path. In mature programmes, the question is not “what is the CVSS score?” but “what is the shortest exploit path from here to a meaningful outcome?”
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 | Risk prioritization must use exposure and threat context, not score alone. |
| NIST SP 800-63 | Identity assurance affects how vulnerable assets can be reached and abused. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets and overprivileged NHIs can make low CVSS issues high impact. |
| CSA MAESTRO | GOV-1 | Governance should evaluate runtime risk in agentic or automated workflows. |
| NIST AI RMF | Risk management requires contextual evaluation, not a single technical score. |
Assess reachability, privilege, and blast radius inside automated execution paths before escalating tickets.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
