Everyone agrees that faster vulnerability patching saves lives. It's the comfortable consensus. Security teams nod. Regulators cite it. Vendors promise it. But this shared assumption obscures a harder truth: mandating disclosure speed doesn't fix what's actually breaking down in modern vulnerability management.
We've watched the evidence accumulate. Zero-days get exploited faster. Patch windows shrink. Organizations struggle to deploy fixes before attackers weaponize flaws. The industry response? Stricter timelines. Mandatory reporting requirements. Public shaming for slow vendors. Regulators love this playbook because it looks decisive.
But mandatory disclosure speed treats the symptom, not the disease.
The real problem isn't that vendors wait too long to patch. It's that organizations can't patch fast enough even when they have the patches. And that gap is widening.
Consider the operational reality. A typical enterprise runs thousands of systems across hybrid infrastructure. Not all of them can be patched immediately. Legacy applications break under updates. Supply chains have dependencies that don't align with security urgency. EDR tools and detection systems have to recalibrate. Testing takes time. Some systems simply can't go down during business hours.
When regulators force vendors to disclose vulnerabilities within 30 days, they're really creating a hard deadline for enterprises to solve a logistics problem they don't control. The vendor releases the patch on day 28. You have two days to validate, test, and deploy across your environment. When that fails, you're the one who gets breached.
Faster disclosure also accelerates weaponization. This isn't theoretical. The KEV catalog has shown us what happens: vulnerabilities move from public disclosure to active exploitation in hours, not weeks. Threat actors have industrialized the process. AI-driven exploitation tools are making this worse. When you collapse the patching window to match the disclosure window, you're not buying security. You're just moving the panic earlier in the cycle.
The uncomfortable opinion: some vulnerabilities shouldn't be disclosed as fast as we're requiring.
Hear me out. Not all flaws are created equal. A memory corruption bug in a niche industrial control system affects fewer victims than a flaw in widely deployed cloud infrastructure. A vulnerability in an obscure legacy application patch matters less than one in actively maintained consumer software. Yet our current framework treats them identically.
What we actually need is differentiated disclosure timelines based on exploitability, impact, and deployment complexity. A vulnerability that requires credentials, specific configurations, and affects five thousand users worldwide should have a different timeline than a wormable flaw in software running on a billion devices.
This means regulators should stop asking "how fast can you patch?" and start asking "can your customers actually patch this?" The first question feels like governance. The second feels like work. But only the second fixes the problem.
It also means organizations need to stop pretending that compliance with disclosure mandates equals security. Publishing patches fast feels like progress. But if your average enterprise takes ninety days to deploy them, you've just created a predictable window where every adversary knows your inventory of flaws.
The vendor community will hate this take because faster disclosure timelines are now regulatory baseline. Compliance equals safety, or so the logic goes. But safety requires synchronized capability. You can't mandate patches faster than customers can deploy them without creating the exact conditions that favor attackers.
The better question than "how do we force faster disclosure?" is "what breaks if we do?" The answer: your ability to actually patch securely.
That's worth getting uncomfortable about.