CISA has been quietly recommending SSVC as the replacement for CVSS-driven prioritization for a couple of years. The framework is technically correct. It is the right shape. It is also, for most organizations, operationally unusable, and the reason it's unusable is the same reason CVSS won in the first place.
CVSS asks you nothing about your own organization. Severity is a property of the vulnerability. You apply a score, you sort by score, you patch in order, you tell the auditor the queue is ordered. SSVC asks you about your own exposure, your own assets, your own mission, and the impact a successful exploitation would have on the well-being of people downstream of your service. Then it asks you to apply a decision tree whose branches depend on the answers.
The decision tree is the easy part.
What SSVC actually requires you to know
The CISA Supplier and Deployer trees ask roughly five inputs per vulnerability. Stated plainly.
Whether the vulnerability is being exploited in the wild. This one is gettable. CISA's KEV catalog exists for exactly this reason, and the answer for most CVEs is no.
Whether exploitation is automatable. Whether a working exploit can be packaged into a worm-class capability that requires no operator. Gettable, for teams that know how to read exploit code. It is a judgment call, not a lookup.
Technical impact. Total compromise of the affected component, or partial. Mostly gettable from a careful read of the advisory.
Mission prevalence. How essential the affected technology is to the organization's mission. The answer requires you to have already mapped which assets support which business capabilities and what happens when those capabilities go down.
Public well-being impact. The harm to physical, financial, psychological, or environmental well-being of people if exploitation occurs. The answer requires you to have already modeled who depends on your service and what bad days look like for them.
The last two are where SSVC dies.
What it costs to answer the last two honestly
Most organizations have no asset-to-mission map. They have a spreadsheet of servers and a different spreadsheet of business processes and the line between them is in the heads of three senior engineers who don't have time to draw it.
Most organizations have no public well-being model. Even the ones whose service obviously affects people. A hospital network can tell you their EHR is critical. They cannot tell you which of three EHR modules is critical, which is convenient, and which is decorative, and they cannot tell you that without first reorganizing what "convenient" means in a clinical workflow, which is a year of meetings nobody is paid for.
These inputs are not security questions. They are organizational maturity questions disguised as security questions. SSVC's elegant decision tree assumes you walked into the room already knowing the answers. CVSS lets you skip the room.
The shortcut that defeats it
Watch what teams do when they're asked to use SSVC in practice.
They hardcode mission prevalence to one value across every asset. Usually "support," because "essential" feels overconfident and "minimal" feels wrong. The decision tree now has a fixed input on its most important branch. The output is no longer stakeholder-specific. The framework has reverted to ordering vulnerabilities by exploitation status and technical impact, which is what CVSS would have done, with extra steps.
They outsource public well-being to a vendor. The vendor sells a generic mapping from CVE to a generic harm score. The score is a constant per CVE. The output is, again, not stakeholder-specific. We have watched this transformation happen at three customers in the last year. The framework gets adopted. The decision tree gets implemented. The inputs get faked. The output is a more elaborate version of CVSS, with a more confident slide deck wrapped around it.
The conscientious teams notice and abandon SSVC inside a year. The less conscientious teams keep it on the slide deck and don't notice.
Why the framework can't fix this
The behavior is structural. SSVC was designed by people who assumed the inputs were obtainable and that the organizations adopting it would obtain them. The first assumption is mostly true. The second is mostly not. The framework has no graceful degradation. When it gets faked inputs it produces output the team trusts more than the inputs justify, because the output looks like the product of a careful tree walk rather than the product of one cell in a spreadsheet getting filled in identically across ten thousand rows.
CVSS has the opposite failure mode, and it is the failure mode that won. CVSS is wrong about your context, but it is wrong in a known, calibrated way that everyone in the industry has built a queue around. The community has years of practice cross-referencing CVSS to compensate for what CVSS doesn't know. SSVC's failure mode collapses the tree to a generic mapping, and the generic mapping is worse than CVSS because it pretends to be context-specific.
What we would have wanted, and what we don't think CISA can produce, is a defaulted version of the tree that admits which inputs were defaulted and degrades visibly. The current shape demands answers. When it gets fake ones it produces output that looks calibrated.
What we'd actually use
If we were running a vulnerability program right now, we'd take two SSVC inputs seriously and let the others default honestly.
Exploitation status, from KEV. Cheap, authoritative, moves the queue.
Technical impact, from the advisory. Cheap, mostly correct, moves the queue.
The other three inputs require organizational work that has to happen anyway for other reasons. Mission prevalence becomes answerable when the business has built an asset-to-capability map, which is a project that pays for itself the first time an outage hits and nobody can describe what's affected. Public well-being becomes answerable when the team has done the threat modeling exercise for the service as a whole, which is a project that pays for itself the first time legal asks who would be harmed by a specific class of breach. Until those exist, defaulting the inputs is honest. Pretending to fill them in is not.
This is not a recommendation against SSVC. It is a recommendation against the half-implementation, which is what most adopters are going to ship.
The honest one-liner
SSVC is the framework you get when you take CVSS's failure modes seriously. The reason it won't win is the same reason CVSS won. Most organizations have not done, and will not do, the work the framework presumes they did before opening the document. The shape that wins in vulnerability management is the shape that requires zero organizational maturity to apply. That shape is CVSS. The shape that produces correct prioritization is SSVC. Those two facts are not going to converge on their own.
What we will be doing about it is the boring thing. KEV for exploitation status. Advisory read for technical impact. Manual judgment, written down, on the inputs below the floor. The tree is fine. The inputs are the work. There is no version of this that doesn't cost what it costs.