Lesson 4.3

4.3: Concentration Risk

9 minutes

Concentration Risk

Lesson 1.6 gave you the pattern in two incidents. Kaseya, July 2021: roughly 1,500 organizations ransomed through a management tool their MSPs used — a vendor they didn’t buy and didn’t know existed. CrowdStrike, July 2024: about 8.5 million Windows hosts down worldwide from one bad content update, pushed by a vendor every affected org had individually, rationally chosen. This lesson is the promised deep-dive: how to actually find and handle this in your own portfolio.

Add a third incident to the set, because it shows the access version rather than the availability version. Okta, October 2023: attackers compromised Okta’s support system and harvested session tokens from HAR files customers had uploaded for troubleshooting. Downstream, Cloudflare, 1Password, and BeyondTrust each detected attempted intrusions traced to that access. Their identity vendor — the thing that guards everything else — briefly became a way in. All three caught it because they were watching their identity provider as a threat surface, not just as a utility.

The portfolio pass

You cannot analyze 150 vendors deeply, and you don’t need to. Run this pass on your top ten by dependency weight — an afternoon of work, honestly:

1. Sort your vendors into blast-radius tiers. Tier 1: if this vendor fails, we stop operating or our customers are exposed — identity provider, cloud, EDR, payment processor, email. Tier 2: painful degradation — CRM, support desk, CI/CD. Tier 3: annoyance. Most orgs have five to eight Tier 1 vendors and have never written the list down. Writing it down is most of the value.

2. For each Tier 1 vendor, ask the two questions. What happens if they’re down for six hours, twenty-four hours, a week? And: what happens if they’re compromised — if the vendor itself is the attacker’s way in? These produce different answers. CrowdStrike was a down-scenario. Okta was a compromised-scenario. Kaseya was both at once.

3. Find the vendors of your vendors. Kaseya’s victims didn’t buy Kaseya. Ask your MSP, your payroll provider, your critical SaaS: what do they run on? You’re looking for surprises — the sub-processor list in their privacy docs and the carve-outs in their SOC 2 (lesson 4.1) are where these hide.

Mitigations that are real vs. theater

The reflexive answer — “multi-vendor everything” — is mostly theater. Running two EDRs or two identity providers doubles cost and integration surface while halving the attention each gets. Almost nobody does it, and the ones who try usually end up with one real vendor and one decaying one.

What’s real, and affordable:

  • Break-glass access. Documented, tested accounts that work when SSO is down. If your identity provider failing locks your admins out of the consoles needed to respond, you’ve built a trap. Test it quarterly; an untested break-glass account is a password in a drawer that expired last year.
  • A degraded-mode decision, made in advance. When EDR or the WAF is down, do you keep operating or stop? Whatever the answer, deciding it calmly in a document beats deciding it at 2 AM by whoever is awake.
  • Staged rollouts where the vendor allows it. Post-CrowdStrike, most agent vendors expose update rings. Put a canary group in front of your fleet. This converts “global vendor pushes bad update” from a fleet-wide event into a Tuesday.
  • Watch your Tier 1 vendors like threat surface. Alert on your identity provider’s admin actions, on new OAuth grants, on EDR console logins. This is exactly what saved Cloudflare and 1Password in the Okta incident — they treated vendor-originated sessions as something to verify, not something to trust.
  • Exit-viability check. Not an exit plan — just an honest answer to “could we leave in 90 days if we had to?” For some vendors the answer is legitimately no. Knowing which ones converts an unknown risk into a priced one, and it changes how hard you negotiate the contract terms in lesson 4.4.

The sentence to keep

The risk you evaluated is per-vendor. The risk that gets you is portfolio-level — the dependency you inherited, the sub-processor you never met, the single point of failure everyone stopped seeing because it never failed before. Once a year, look at the portfolio, not the logos.