Which security updates should you install first?

A patch queue rarely arrives at a convenient time. There are workstations waiting for a restart, a server with a limited maintenance window, and a new advisory marked critical. Deciding what goes first takes more than sorting by severity.

Start by checking whether the vulnerable product and component are actually present. Then look at how the system is exposed and what a compromise would affect. The severity score helps explain the bug; your environment determines how urgently you need to act.

Match the advisory to what you run

The CVE identifies the issue; the CWE describes its weakness class. To assess exposure, you still need to match the advisory to the installed edition, version, architecture and enabled component. Treat an unmatched scanner result as something to investigate before turning it into a maintenance decision.

CVSS describes technical severity through metrics such as attack vector, required privileges, user interaction and impact. FIRST’s specification distinguishes base characteristics from threat and environmental considerations. Preserve the scoring version and vector when importing a score; a bare “9.8” removes much of the information needed to understand it.

FIRST: CVSS 4.0 specification

What CVSS, EPSS and KEV each tell you

FIRST’s EPSS estimates the probability that a published CVE will be exploited in the wild during the next 30 days. It is a forecast about the vulnerability, not the probability that your particular server will be breached. Record the score’s observation date if you use it because predictions change as the underlying information changes.

FIRST: what EPSS estimates

CISA’s Known Exploited Vulnerabilities catalog, or KEV, records issues that meet its criteria for known exploitation. A high-severity bug may have no known exploitation, while a lower-scoring bug may already be in use. Read those signals alongside the system’s reachability, the data it holds and the business processes that depend on it.

An exposed service can outrank a higher score

Suppose a remote-access service exposed to the internet has a confirmed applicable vulnerability with known exploitation. An isolated test application has a higher base score. The remote-access service is a strong candidate for emergency maintenance, while the test application gets its own assessment. But check that isolation: production credentials or access to critical infrastructure could change the second system’s priority.

Record why you made the decision: the affected version, exploitation evidence, confirmed reachability and responsible business owner. For a vendor workaround, record what it protects and when it needs review. A firewall rule or disabled feature may reduce exposure without fully correcting the bug; describe it according to the vendor’s guidance for your configuration.

Check what is running before closing the ticket

A patch ticket should connect the advisory to the asset and package, show the running version after any required restart, and include component or database-upgrade status and an application check. Account for failed installs and offline devices too. “Sent,” “installed” and “running the corrected code” are three different stages in a deployment.

If an update remains deferred, name the approving owner, compensating controls and next review date. Keep the original finding and the evidence used to resolve it. That way, a later reviewer can tell a false positive from an unsupported system, an accepted delay or a completed fix.

Know what you need to maintain

Keep an inventory of operating systems, browsers, business applications, network equipment, remote-access tools, and website software. Record the owner, supported version, and official update source for each important system. Include devices that sit quietly in a corner; they still need maintenance.

Check support lifetimes. Software that no longer receives security updates needs a replacement or risk-reduction plan. Repeatedly pressing “check for updates” will not make an unsupported product supported again.

Keep an emergency maintenance route open

Review official vendor security notices for affected versions and required action. CISA’s Known Exploited Vulnerabilities Catalog can help identify vulnerabilities known to have been exploited. Its inclusion is a useful signal; its absence is not evidence that a weakness is safe to ignore.

Someone needs authority to move an exposed or critical system out of the routine queue. Make that route clear before an urgent advisory arrives, and bring the affected-system details and exploitation evidence to the person responsible for the service.

Plan the change and verify it

• Confirm the affected product and installed version.

• Read the vendor’s prerequisites, compatibility notes, and recovery options.

• Arrange appropriate backups and a maintenance window where needed.

• Install through the vendor’s supported process.

• Check the resulting version, required restarts, and a representative business workflow.

Automatic updates can handle much of the routine work on suitable devices. They still leave failed installations, pending restarts and exceptions for someone to follow up. On critical systems, plan testing and recovery around what a failed change would interrupt.

Sources & further reading

CISA: Known Exploited Vulnerabilities Catalog

CISA: Software Updates Tip Sheet

Technical review: September 8, 2026. This is Short Circuit LLC’s original guidance, with primary sources linked beside the relevant explanations. Examples are illustrative.