Most SLED ransomware incidents start with a vendor, not an email

State, local, and education environments are being compromised through their managed service providers and software supply chain more often than through phishing. Three third-party control patterns that matter — and the CISA guidance that backs them.

February 27, 2026 By Rohit Khirapate

Most SLED ransomware incidents start with a vendor, not an email

The public storyline for most ransomware incidents at a state agency, a county, or a school district is "a user clicked a link." That storyline is increasingly wrong. Across the incidents we've consulted on in the last eighteen months, the more common root cause is the managed service provider, the remote-monitoring tool, or the software supplier. The phishing email is the cover story. The MSP credential is the door.

CISA's own advisories through 2025 are explicit about this: the trendline in SLED incidents is third-party-initiated, not end-user-initiated. That changes where the investment should go.

1. Your MSP is a privileged identity. Treat it like one.

What we see. An MSP provisions a local admin service account on every endpoint, tied to a single shared credential. The credential is stored in the MSP's password vault, which is protected by its own MFA — and one re-used admin password from 2022.

What works. MSP access runs through your identity provider, not theirs. Just-in-time elevation, session recording, and a quarterly named-user review of every active MSP credential. If the MSP objects, the MSP is the risk.

Maps to: NIST 800-53 AC-2, AC-17, AC-6 · CISA ZT Maturity Model — Identity Pillar

2. RMM tools are a monoculture. Assume compromise is not if, but when.

Remote monitoring and management tools are concentrated in a handful of platforms. When one of them is compromised — and it will be again — the blast radius is every customer.

What works. Every RMM action runs through your change-management system, not as an out-of-band admin channel. Egress controls on the RMM agent itself. A documented trigger for RMM isolation the moment the platform publishes an advisory.

Maps to: NIST 800-53 CM-3, SI-4, IR-4 · CISA Secure-by-Design Principles

3. Software supply chain is not only SBOMs. It is also update paths.

The last three SLED incidents we looked at involved a vendor-pushed update that shipped a malicious payload or that opened an unintended path. SBOMs are necessary and not sufficient.

What works. Every vendor update path is an inventoried control surface. Staged rollouts (one environment, one week, one tenant). Anomaly detection on post-update network behaviour. A documented rollback procedure per product, tested.

Maps to: NIST 800-53 SR-3, SR-4, SR-11 · CISA SBOM + Secure Software Development Framework

The uncomfortable truth for a small-to-mid-size agency: the cyber budget has been going the wrong direction. Most of the spend is on endpoint and email — which matter — while the MSP, RMM, and vendor-update paths are operated on trust. Rebalancing does not require more budget. It requires moving controls to where the real entry points are.

One more thing, specifically for the CIOs and CTOs of smaller SLED entities: if your MSP cannot produce a current SOC 2 Type II report, a tabletop AAR, and a list of every privileged account they hold in your environment, your MSP is part of your risk register. They are not the mitigation.

Next step. Our Government Cybersecurity Readiness Playbook includes a third-party control grid for MSP, RMM, and software-supplier oversight. If you're triaging an active incident with MSP involvement, our incident response practice line responds within four hours.