Who Owns the MSP Deadline?

# Who Owns the MSP Deadline? CISA has a peculiar method for telling everyone it's time to worry. No dramatic language. No urgent prose. They simply add an entry to their Known Exploited Vulnerabilities (KEV) catalogue and attach a federal patch deadline; for CVE-2026-84869, that deadline is today, Monday, September 14. If you work for the US government, your compliance officer is currently breathing down your neck, and if you run a Managed Service Provider (MSP) using ConnectWise ScreenConnect, this is simply the day the attackers were waiting for. Think of ScreenConnect as a digital master key. It's an RMM tool, Remote Monitoring and Management, that lets IT providers slide into a client's server without knocking. The utility is obvious: you can fix a printer in Osaka from a desk in Ohio. But that convenience creates a single point of failure for every customer on your books. The flaw here involves improper privilege management and missing authorization. Put simply, the software fails to check if the person asking for admin power actually has it. An attacker who gets a foothold can escalate their status, effectively promoted from guest to landlord. Exploiting this doesn't require a PhD in cryptanalysis, and it needs an entry point and knowledge that the gate is unlocked. Once an attacker controls the ScreenConnect console, they aren't just inside one company, and they are inside every company that MSP manages. This "force multiplier" effect keeps regulators awake at night, though usually for the wrong reasons. The regulatory machinery aims to punish the victim or the vendor who wrote the bad code, and it is far less adept at handling the intermediary. When an MSP gets compromised via a tool like ScreenConnect, we see cascade failure, and first, the MSP loses control. Second, attackers use the RMM's own legitimate channels to push ransomware to dozens of downstream clients simultaneously. Third, those clients, a small law firm or regional medical clinic, discover the breach and call their IT provider for help, only to find the provider let the wolf in through the back door. Patching this isn't technically complex. It's a software update. But for an MSP, updating core infrastructure across diverse client environments is never "just" an update. There is always fear that a version jump will break a legacy accounting app used by a client refusing to upgrade their OS from 2016. Providers usually object that they cannot patch every system instantly without risking operational downtime. They argue stability is its own form of security. That is a convenient fiction; in the current environment, there is no "operational stability" while running an exploited RMM tool with admin privileges. The risk of total wipeout far outweighs the risk of a few broken legacy apps, and suggesting otherwise miscalculates the cost of downtime. The regulatory response remains toothless. CISA's KEV list is an excellent ledger, but it lacks jurisdiction over the private sector. It tells us CVE-2026-84869 is being used in the wild and sets a date for the US government to be clean. But there is no fine for a private MSP who misses today's deadline; there is only the eventual invoice from a ransomware gang. We have seen this rhythm before. It rhymes with the various Ivanti flaws of previous years, where the gap between disclosure and patching created a gold rush for attackers; the difference here is the nature of the trust. You don't just trust your own security; you outsource that trust to a third party who may not be following the KEV list in real-time. The noise around AI often obscures these boring, structural failures. While we spend mornings reading about OpenAI agents pushing 2,000 malicious packages into RubyGems or wondering why Anthropic struggles with CAPTCHAs, the actual plumbing of the internet is leaking. We are distracted by "AI-powered attacks" while criminals use a missing authorization check in a management tool to walk through the front door. Even the scale of recent breaches suggests we are failing at basics. Mathspace recently admitted that north of 1 million records were caught in a breach, and Microsoft has been churning out patches for nearly 1,000 flaws, 974 to be precise, in a single cycle. These aren't anomalies; they are the baseline. The downstream exposure is the real story; if you are a business owner, you likely don't know if your IT provider uses ScreenConnect. You certainly don't know if they've patched it, and you have handed over the keys to your kingdom to a third party and hoped their paperwork is in order. One might wonder why we continue to rely on RMM tools that provide such an expansive attack surface without mandatory, audited patching cycles for providers. In Oslo or Brussels, one might find a more aggressive approach to supply chain liability, where the provider is held legally accountable for the hygiene of the tools they use. In the US and UK, we largely rely on the "best effort" of the MSP and occasional CISA warnings. The question now is whether the industry will wait for a catastrophic event, something that makes the 2026 GitLab path traversal bug look like a minor glitch, before moving toward verified patching. Until then, we have the KEV list. It is a very tidy piece of paperwork. It's just a shame that by the time the deadline arrives on a Monday morning, the attackers have already been inside for a week.