Your perimeter can be clean and it will not save you if the intrusion starts somewhere you do not own. Ransomware crews have figured out that hitting one organization at a time is slow and that hitting the vendor behind a thousand organizations is not. The remote monitoring tool your MSP installed on every endpoint, the SaaS platform that holds your customer data, the open source package your build pipeline pulls without a second thought, the API integration your finance team signed up for last quarter. Any one of those is now a plausible way in, and none of them show up on the asset inventory you built around your own network.
This is not a theoretical shift. It is a change in where attackers spend their time, because it pays better. A security program built around hardening its own perimeter is defending a door the attacker has stopped trying to open.
Why this is the economical move now
The math behind supply chain intrusion is simple and it has not changed, attackers have just gotten better at acting on it. One vulnerability in one widely deployed piece of software reaches every customer running it. One compromised MSP reaches every client whose network that MSP manages. One poisoned open source package reaches every build that pulls it. Compromise is a one-to-many event instead of a one-to-one event, and ransomware operators who sell access or run affiliate programs have every incentive to find that lever instead of grinding through individual targets.
Cyble's threat landscape research gives a sense of the trend line even if the exact monthly counts move around. Cyble's January 2026 report described ransomware activity running more than 30 percent above the 2025 monthly average and tied part of that surge to supply chain targeting, and Cyble separately reported 297 supply chain attacks claimed by threat groups across 2025, up 93 percent from 154 in 2024, with October 2025 standing out as a record month. Those are vendor-reported counts built from dark web leak site claims, not an audited census, but the direction is consistent across their reporting.
The other half of the problem is speed. NTT DATA's Cyber Threat Intelligence Trends 2026 report, as covered in press summaries, describes critical vulnerabilities being weaponized within 24 hours of disclosure and some intrusions moving from initial access to data exfiltration in as little as 72 minutes, with ransomware present in roughly 48 percent of the breaches it analyzed. Whatever the exact figures, the operational point holds. The gap between a vendor disclosing a flaw and an attacker using it against that vendor's customers has collapsed, and a lot of organizations still run vendor risk reviews on an annual cycle built for a slower world.
The clearest illustration of the mechanism is still the 2021 Kaseya VSA incident. REvil affiliates exploited a flaw in Kaseya's remote monitoring software, the tool dozens of managed service providers used to administer client networks, and rode it downstream. Kaseya's own count put the number of affected end customers as high as 1,500, most of them small businesses that had never heard of Kaseya and had no idea their MSP's management platform was the thing standing open. None of those businesses had a vulnerability of their own. They had a vendor with one.
Why the questionnaire does not catch this
Most vendor risk programs still run on an annual or onboarding questionnaire, and the structural problems with that approach are not news to anyone who has filled one out. RiskRecon's State of Third Party Risk Management research found that only 4 percent of organizations were highly confident their questionnaire responses actually reflected a vendor's real security posture. A questionnaire is a point in time snapshot that a vendor fills in about itself, and it goes stale the moment anything in that vendor's environment changes.
The deeper issue is scope. A questionnaire asks about the vendor you have a contract with. It almost never reaches the subcontractor that vendor depends on, the open source library its engineering team pulled in, or the fourth party hosting its own infrastructure. A vendor can answer every question honestly and still be one dependency away from the actual exposure. Industry research on vendor sprawl, cited in coverage of a recent Vanta study, puts more than half of a typical organization's vendor footprint in shadow IT territory that never gets a formal review at all.
| What a questionnaire checks | What actually determines blast radius |
|---|---|
| Does the vendor have a written incident response plan | How fast is the vendor contractually required to tell you once they know |
| Does the vendor encrypt data at rest | What standing access does the vendor's tooling have inside your network right now |
| Has the vendor passed a SOC 2 audit | How many other customers share the same build pipeline, update channel, or support tool |
| Does the vendor have cyber insurance | Can you detect and contain an intrusion that starts in the vendor's environment, not yours |
The 2026 Verizon Data Breach Investigations Report reinforces how far this has drifted from a compliance exercise. Coverage of the report puts third party involvement in confirmed breaches at roughly 48 percent, a jump of about 60 percent year over year across a dataset of more than 22,000 confirmed breaches. Verizon's own definition of third party now spans software supply chain vendors, data hosting vendors, and anything connected into the environment, which is a wider net than most procurement teams are scoring against.
What changes operationally
Three things actually move when you take this seriously.
Detection has to stop treating vendor and MSP traffic as automatically trusted. The remote access tool your MSP uses, the integration account your SaaS vendor was granted, and the service account behind an API connection all need the same behavioral monitoring you would apply to a privileged internal account, because to the network they effectively are one. If that traffic cannot be distinguished from normal administrative activity in your logs, you have no way to notice when it is the attacker driving it instead of the vendor.
Incident response planning has to account for an intrusion that starts outside your walls and outside your control. Your playbook needs a path for the scenario where you learn about a compromise from a vendor's disclosure, not your own SIEM, and where containment means cutting a trusted integration rather than isolating a host you own. Tabletop exercises that only simulate an internally discovered breach are rehearsing the easier version of the problem.
Vendor and architecture decisions move from "did they pass the questionnaire" to "what happens to us if they get hit." That means scoping MSP and SaaS access by least privilege instead of the broad administrative reach vendors default to, segmenting any tool with standing access across your fleet so one compromised agent cannot reach everything at once, and asking for an SBOM rather than a compliance attestation. CISA, NSA, and FBI released an updated 2026 minimum elements baseline for SBOMs this year that explicitly extends to SaaS and AI software, not just packaged code, which gives procurement teams a concrete artifact to request instead of a self-graded form.
The sharpest operational risk is the remote management tool itself. Every MSP and most SaaS platforms need some standing, often highly privileged, access into your environment to do their job. That access is usually scoped for convenience rather than blast radius, and it is rarely segmented, rarely monitored at the same level as internal privileged accounts, and almost never included in tabletop exercises. If that tool is compromised upstream, the attacker inherits whatever access you gave it, all at once, across every system it touches.
Where teams get this wrong
The most common mistake is treating vendor risk as a procurement milestone instead of an ongoing operational dependency. The questionnaire gets filled out once, filed, and revisited a year later if anyone remembers. Nobody owns the question of what standing access that vendor still has or whether it has grown since onboarding.
The second mistake is assuming that because the intrusion started outside your network, it is not your incident to lead. It is. Your customers, your regulators, and your board do not care that the initial foothold was in someone else's environment. Your IR plan needs to say explicitly who leads when the first signal comes from a vendor's breach notification instead of your own detection stack, because that ambiguity costs hours you do not have.
The third is sizing vendor risk by the sensitivity of the data a vendor holds and ignoring the access it has. A vendor with no data but broad administrative reach into your network is a bigger exposure than a vendor holding sensitive data behind a narrow, monitored connection.
Where this leaves a security program
None of this means you can vet your way out of the problem. You cannot audit every dependency your vendors depend on, and you should stop pretending a questionnaire gets you there. What you can do is assume a trusted connection will eventually be the one an attacker rides in on, and build detection, response, and architecture decisions around that assumption instead of around the fiction that your vendors are an extension of your own hardened perimeter. The organizations that get hurt worst by supply chain ransomware are not the ones with the weakest vendors. They are the ones that never asked what would happen if a trusted vendor had a bad day.
Related Service
Learn more about how we can help with Security Architecture & Advisory.
Explore Security Architecture & Advisory Services →
