What actually needs patching urgently

"Patch promptly" is not a policy. It's the sentence that goes in the policy document so the policy document exists.

The real situation is a vendor bulletin with forty entries in it, or a scanner report with three hundred findings and a column of red, and one person who also has a business to run. Everything cannot be urgent. So the useful question isn't whether to patch — it's what gets done tonight and what waits for the monthly window.

Severity scores describe the flaw, not your exposure

A CVSS score is calculated by someone who has never seen your network. It rates the vulnerability in the abstract: how hard it is to exploit, what it gets you, whether it needs credentials. There are environmental metrics in the standard meant to adjust for your situation, and almost nobody fills them in, so what you actually receive is a context-free number.

Which means a 9.8 on a database that only listens on the loopback interface of one internal server is genuinely less urgent than a 7.5 on the remote-access appliance your whole staff logs into from home. Ranking by score sends you to the wrong one first.

The rule: exposure, then authentication

Sort by two questions. Can something on the internet reach it? And does it handle logins, sessions, or credentials?

Tier one — tonight, or this weekend at the latest. Anything internet-reachable that terminates authentication. VPN concentrators, firewalls with a management or portal interface exposed, remote-desktop gateways, mail servers, your identity provider or directory, and public web applications along with the frameworks and plugins underneath them. A flaw in this tier is reachable before anyone has proven who they are, and it sits one hop from everything else you own.

Tier two — this week. Internet-facing things that don't handle authentication, like a static marketing site's web server. Internal systems holding real data: file servers, databases, the accounting box. And — this is the one people misfile — browsers and email clients on staff laptops. Your browser is an internet-facing service. It just happens to sit on a desk.

Tier three — the monthly window. Everything else. Internal tools, utilities, workstation software that doesn't open hostile content, firmware on devices with no route in or out.

Two things jump the queue regardless of tier. If a vulnerability appears in CISA's Known Exploited Vulnerabilities catalog, it is being used against real organizations right now — treat it as tier one whatever the score says. And when a vendor ships an out-of-band release, off their normal cadence, that's the vendor telling you plainly that it's bad.

The half of the job the advisory doesn't mention

Here's the part that gets missed, and it's specific to that tier-one list.

For an appliance that handles authentication, applying the update closes the hole. It does not undo what the hole allowed. If the flaw let an attacker read configuration or lift session tokens before you patched, the freshly patched box will keep honoring those tokens and those credentials, because from its point of view they're valid. You've locked the door on someone who already copied the key.

So on any internet-facing authentication device, patching is step one of three. Step two: rotate what it held — local administrator credentials, API keys, service accounts, and the shared secrets in its configuration, which typically means directory bind passwords, RADIUS secrets, and VPN pre-shared keys. Step three: invalidate every active session so everyone has to sign in again. Then read the advisory once more and check whether it says configuration or credentials could be read, because that determines how far the rotation has to go.

The other quiet failure is simpler. Installing an updated package doesn't fix a process that's still running the old code in memory. On Debian and Ubuntu, needrestart will tell you which services need restarting; on RHEL and its relatives, dnf needs-restarting. Kernel and core library updates need a reboot, and "we patched but never rebooted" is a real state that looks patched to every report you'll run.

What to do

Write down what of yours answers on the internet. You can't triage exposure you haven't inventoried — and the surprises are usually a forgotten test site or a management interface someone opened for an afternoon in 2023.
Subscribe to the security advisory mailing list for every product in tier one. Not a newsletter. The vendor's own list.
Run two cadences: an emergency path that can go out the same day for tier one, and a scheduled monthly window for the rest. One process trying to serve both ends up serving neither.
After a tier-one patch, rotate credentials and kill sessions.
Restart the services, and reboot when the kernel changed.
Retire anything past end of support. A device the vendor no longer patches is a tier-one finding you can never close, and no amount of diligence elsewhere makes up for it.

If you'd rather someone else read the advisories and decide what's urgent, that's the Systems side of what I do.