Should organisations patch by severity score or by risk in this model?

Why risk beats severity for patch ordering

Severity scores are useful because they give a fast, repeatable first pass. The problem is that severity alone does not tell you whether a flaw is exploitable in your environment, whether the affected asset is exposed, or whether the blast radius is limited or wide. Risk-based patching turns a generic score into a prioritisation decision tied to actual business and technical exposure.

That matters most when the vulnerable component sits on a privileged path. A moderate issue in an identity platform, secret store, or admin service can outrank a higher-scoring bug in a low-value internal system because compromise would create far more downstream access. In practice, the question is not “how bad is the bug in theory?” but “what can this bug unlock here?”

Severity should therefore be treated as an input, not the ordering rule. Use it to sort large queues quickly, then adjust for exposure, exploitability, privilege, internet reachability, compensating controls, and the business function behind the asset. A patching model that ignores those factors is efficient on paper and brittle in operations.

How to apply a risk-based patching model

Risk-based ordering works best when teams define a few simple decision factors and apply them consistently. The most important are whether exploitation is known or likely, whether the asset is externally reachable, whether the flaw affects authentication or authorisation paths, and whether the system protects secrets, keys, tokens, or other high-value material. Those factors often change priority more than the raw CVSS number does.

For identity and access infrastructure, the ordering rule should be stricter than for ordinary application servers. A patch that closes a weakness in a service account workflow, a federation component, or a vault integration may deserve accelerated treatment even when the score is only moderate, because compromise can cascade into many other systems. That is why controls for privileged access and machine identity deserve the same attention as classic perimeter exposure.

Risk-based patching also depends on asset context. A vulnerability in a lab system, a quarantined build host, or a decommissioned service is not equal to the same issue on a production control plane. The model should reflect environment, exposure, and dependency, not just the CVE entry. If those inputs are not maintained well, severity scores end up carrying more weight than they should.

Where severity still helps, and where it misleads

Severity is still valuable for scale. When hundreds of findings land at once, a severity score gives a shared baseline and a consistent language between security, operations, and engineering. It is especially helpful for low-context triage, vulnerability scanning, and reporting to teams that need a simple starting point before deeper analysis.

It misleads when it becomes a substitute for judgement. CVSS and similar scales describe technical characteristics, but they do not fully account for exploit availability, asset exposure, control strength, or organisational impact. That is why two issues with the same score can require very different patch timelines. For practical prioritisation, the score should be combined with CVSS severity scoring, exploit intelligence, and the role of the asset.

When exploitation is already being observed, priority should move away from abstract scoring and toward active remediation. CISA’s Known Exploited Vulnerabilities Catalog is useful because it anchors patch urgency to confirmed attacker interest, not just theoretical weakness. For deciding which risks are likely to move first, EPSS adds a probability lens that severity alone cannot provide.

Practitioner Guidance

What to prioritise: Start with assets whose compromise would expand access or expose secrets, especially identity platforms, vaults, admin planes, and internet-facing services. Treat “moderate” findings on those systems as potentially urgent until you have confirmed exposure and blast radius.

Decision rule: If a vulnerability is exploitable, externally reachable, or sits on a privileged dependency chain, let risk override severity in the queue. If it is high severity but isolated, inaccessible, or well-compensated, it can usually wait behind lower-scoring but more exposed issues.

What to measure: Track time-to-patch by asset criticality, not just by severity band. If your median remediation time is low for critical exposed services but high for low-value assets, the model is working; if the reverse is true, severity is still driving behaviour.

Practitioner takeaway: The useful patching model is the one that most reduces real exposure, not the one that looks neat in a dashboard. Severity helps you sort; risk tells you what to fix first.

Related resources from NHI Mgmt Group

• What happens when organisations patch by severity score instead of exposure?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?