Stop patching by score – and start patching by authority

COMMENTARY: Vendors and security communities have spent years debating what CVSS gets wrong.  AI-assisted vulnerability detection will very soon make that argument urgent.

More findings, at machine speed, all needing triage – and the score alone does not give us the right measurement for deciding what to patch first.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

As I’ve argued before, a CVE with a CVSS of 10 that does not land on a privilege boundary is operationally ineffective. Not all CVEs are created equally. It’s the privilege state that matters – and CVSS doesn’t capture it.

Entry state and exit state

The privilege state of a CVE matters. That means two things:

Contextualize both and defenders can make informed decisions about what to patch, when to patch it, and what compensating or mitigating controls belong in place until the patch gets deployed. Severity and urgency alone don't tell us what happens after exploitation. The real question here: What authority does the threat actor gain if this CVE gets exploited?

What CVE records miss

Look at CVE-2026-76460, a bug in the API of Cisco’s Identity Service Engine that Cisco recently patched. The structured data tells defenders that a threat actor starts with no privileges required (PR:N), and through a Scope: Changed vector, that impact reaches beyond the vulnerable component's security authority. CVSS captures much of the entry state well.

What it does not convey: which authority boundary was crossed, or what authority the threat actor holds after exploitation.

The most consequential fact about this CVE – that successful exploitation can result in command execution with root privileges – gets buried in a forensic note under Indicators of Compromise. Root is not a footnote. It belongs in the summary, where tools can actually consume it. It’s a gap in the requirements.

The chaining problem

Privilege states also reveal something individual records never show: how one CVE sets up the next.

Cisco CVE-2023-20198 and CVE-2023-20273 illustrate this directly. The first gave an unauthenticated threat actor a local account at privilege level 15. That exit state became the entry state for the second, which escalated to root and installed a persistent implant. The CVE that completed the transition to root was scored 7.2. The score was accurate, but what the number did not tell the defender was that this vulnerability completed an authority transition from the newly-created local user to root. 

A more recent example: PaperCut CVE-2026-81578 and CVE-2026-82078. The first is an authentication bypass. The second, an unsafe dynamic class loading. Neither achieves campaign objectives alone. Chained, they yield pre-authentication remote code execution in the PaperCut application server. The individual scores are accurate. The individual records are correct. A defender reading both still cannot see the blast radius they create together.

Privilege debt determines reach

Exploit-derived authority doesn’t operate in isolation. It combines with what’s already in the environment: existing privilege, trust relationships, standing credentials, accessible secrets, and network reachability.

That combination produces operational leverage – how threat actors pre-position, establish persistence, and move laterally. The vulnerability creates the initial authority. Privilege debt, the privilege in an environment that exceeds operational need and sits accumulated and waiting, determines the reach and scope that authority carries.

What defenders actually need

I raised this in my response to the NIST RFI on NVD modernization. The fix is conceptually straightforward: state entry authority, vulnerability, and exit authority as typed, structured fields in the record, so the details that drive decisions stop living in advisory footnotes.

Three questions every defender and security tool should answer directly from the record:

Weakness classification has the same blind spot. When a record names only the terminal weakness, defenders mitigate the symptom. The enabling condition stays, and so does the exposure.

The authority decides – not the score

For CVE-2026-76460, Cisco assigns CWE-648, Incorrect Use of Privileged APIs, while describing insufficient authentication control on an API endpoint. That steers toward CWE-306 or CWE-287 depending on whether authentication was missing or can be bypassed. I spent part of my career supporting the CWE program at MITRE, and that distinction matters for how fixes and mitigation strategies get devised. When the record names only the terminal weakness, defenders mitigate the symptom instead of the enabling condition. The enabling condition stays, and so does the exposure.

So we don’t want to look at which vulnerability has the highest score. The questions are: Which one produces the most leverage? Which one crosses privilege boundaries? Which one lands on infrastructure carrying significant privilege? Which one composes with credentials, trust, or reachability already present in the environment?

The score does not matter if the hackers wind up owning the organization. What really matters: the authority exploitation gives a threat actor – and what that authority allows them to do next. That’s why we drop everything and patch. Not because of the score, but because the authority says so.

Kevin E. Greene, public sector chief cybersecurity technologist,  BeyondTrust

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.