The vendor answered within a day. Yes, they had seen the KEV. Yes, they were patched. The ticket closed with a polite email.
What nobody asked was who manages that vendor’s endpoints. Which remote-support tool does their MSP use to reach the servers holding your data? Did that get patched, and did anyone get in before it did?
That is fourth-party risk after a KEV week. The exposure doesn’t sit with the company on your contract. It sits one hop out, in a console, an agent, or an integration your questionnaire never reached.
September was a remote-management month
Two of September 2026’s most-watched KEV listings were in tools MSPs use to run other companies’ environments.
On September 8, CISA added a flaw in N-able’s N-central, a remote monitoring and management (RMM) platform MSPs use to patch, script, and remotely control customer fleets. Huntress, which tracked attacks on the platform from early August, called a compromised RMM “a force multiplier against every downstream client.” Microsoft Threat Intelligence, as reported by BankInfoSecurity, linked ransomware by a group it tracks as Storm-1175 to likely exploitation of an N-central authentication bypass, starting the same day the flaw was disclosed.
On September 11, CISA added ConnectWise ScreenConnect, a remote-support control plane used by many MSPs and IT teams.
Most TPRM owners never bought either product. Their vendors’ MSPs did.
“Patched” has more than one meaning
The hosted side was fixed. The self-hosted side had to fix itself. Huntress reported that N-able patched its hosted N-central instances, while on-premises operators had to apply successive hotfixes themselves. In Huntress’s own telemetry on August 3, 28.6% of reachable self-hosted servers were still unpatched.
The server was fine. The client wasn’t. The ScreenConnect flaw sat in client and session handling, and servers were not affected. As Security.io noted, “teams that check only server patch status may misunderstand the exposure.”
Patched doesn’t mean clean. Huntress opened one investigation on September 4 after a fully patched N-central environment was compromised. Appliance logs had already rotated, so it couldn’t say which flaw was used.
No CVE required. On September 29, Microsoft described phishing that delivered a legitimate, signed MSP360 RMM installer, which then installed ScreenConnect as a second access channel. Microsoft saw no exploitation of ScreenConnect itself. Trusted admin software, wrong operator. No KEV listing will ever flag that.
Why the questionnaire doesn’t reach
Questionnaires go to the counterparty. They rarely ask:
- Which MSPs manage systems that hold or touch our data?
- Which RMM and remote-support tools do they run, and are those tools self-hosted or vendor-hosted?
- Which marketplace apps, embedded scripts, or connected-app tokens can reach our data through the vendor’s platform?
When they do ask, the answer is a snapshot. As Green questionnaires, live exposure argued, completeness and live exposure are different jobs. One hop out, you’re relying on your vendor’s months-old view of their vendor.
What fourth-party practice looks like after a KEV week
You can’t assess every vendor’s vendor. You can make the ones that matter visible.
- Map the management plane. For critical vendors, record who administers their environment and which remote-management tools are in play. Treat RMM as a dependency class, like identity.
- Ask the hop-two question on day one. When a KEV hits remote-access or integration tooling, ask: do you, or any provider managing your systems, run this product? Hosted or self-hosted? Who confirmed the version, and when?
- Separate version proof from compromise review. “Patched” and “not breached before the patch” are two different answers that need two different kinds of evidence.
- Inventory trusted tools, not only vulnerable ones. Microsoft advises governing approved RMM tools and blocking the rest. Ask critical vendors whether they keep that allow-list.
- Make fourth-party findings re-openable. Link a provider finding to every vendor that depends on that provider. That’s the dependency-graph point from Remediation theater, one hop out.
- Include former vendors. Post-engagement risk doesn’t stop at the first hop either.
Who feels it
Security sees a coverage gap. We monitored the vendor, not the console reaching into the vendor.
Legal and GRC see an evidence gap. We have the vendor’s attestation and no record of what their provider did before the due date.
Procurement sees a contract gap. MSP notification terms rarely mention remote-management tooling.
A one-week fourth-party check
For your five most critical vendors:
- Who manages their infrastructure: in-house, an MSP, or both?
- Which RMM or remote-support tools reach systems holding your data?
- During September’s N-central and ScreenConnect listings, did anyone ask, and is the answer on file?
- Which of your other vendors depend on the same provider?
- What counts as “patched and reviewed” one hop out, and who checks it?
If those answers are mostly blank, you’re not missing a template. You’re missing a hop.
Where this fits
This is the layer Rescana’s Prism works on in supply chain security and risk. It finds third and fourth parties through identity, procurement, IT-asset, and OSINT signal, checks vendor answers against live exposure, and keeps following up until there’s evidence, while people approve the residual-risk calls. For technical detail on September’s listings, see Rescana’s Security Watchtower advisories on N-able N-central and ConnectWise ScreenConnect.
Soft next step
If your security, legal, and risk teams want a clearer view of the MSPs and tools behind your critical vendors, without turning every KEV week into a fire drill, we’re glad to compare notes on how regulated teams are mapping the next hop.
