Third-Party Concentration Risk Guide

When one supplier, platform or credential sits underneath many of your critical services at once, a single fault at that supplier becomes your outage, and often your whole sector's outage at the same moment. The CrowdStrike content update of 19 July 2024 crashed millions of Windows machines worldwide in about 78 minutes of exposure, and every affected organisation had to recover the same way at the same time. Concentration risk is not limited to cloud hosting: it lives in endpoint agents, identity providers, SaaS integrations, CI/CD platforms and the credentials that tie them together. This guide explains the forms concentration takes, how to find and measure it, what regulators now expect (DORA, the UK critical third parties regime and the FSB toolkit), and which controls reduce or absorb it. It is for risk, resilience, security architecture and third-party risk teams, and for executives who sign off risk appetite.

Key takeaways

Concentration is a dependency pattern, not a vendor list. Count how many critical business services fail if one provider, one update channel or one credential store fails, not how many contracts you hold with that provider.
Privileged software with automatic updates is the sharpest form. The CrowdStrike outage came from configuration content pushed to kernel-level agents on every online host within minutes, bypassing the customer's own change control.
Identity and credential concentration is the security twin of the availability problem. Breaches at Snowflake, Salesloft Drift and CircleCI turned one provider's weakness into hundreds of customers' incidents.
Regulators now oversee the concentrators directly. The EU designated critical ICT third-party providers under DORA on 18 November 2025, and the UK has a critical third parties regime, but oversight of the provider does not move accountability away from the customer.
The cheapest control is often absorption, not diversification. Staged update rings, tested manual fallbacks, offline recovery keys and pre-agreed exit plans cost less than running two of everything.

What concentration risk looks like

Concentration risk exists at three levels. Entity level: your own organisation depends on one provider for several critical services. Supply chain level: different providers you use all depend on the same fourth party, such as one hyperscaler or one payment network. Systemic level: many organisations in a sector depend on the same provider, so a failure hits everyone at once and shared recovery resources (support staff, engineers, spare hardware) run out. The FSB toolkit of 4 December 2023 treats this last level as "systemic third-party dependencies", a concern for authorities as well as firms.

Form	Typical example	Failure mode	Signal that you are exposed
Cloud and infrastructure	Single cloud region or provider for core workloads	Regional outage, control-plane failure, account suspension	Recovery site is in the same provider and depends on the same identity and DNS
Software and agent	Endpoint security agent, monitoring agent, backup agent on every host	Faulty update crashes or disables all hosts at once	Vendor pushes content without customer staging control
Identity and authentication	One identity provider for workforce, admin and application SSO	IdP outage locks everyone out; IdP compromise grants access everywhere	Break-glass accounts also authenticate through the IdP
Credential	Secrets stored in one CI/CD or SaaS platform	Provider breach forces rotation of every secret at once	No inventory of which credentials sit in which third-party platform
Shared SaaS and integrations	CRM, data warehouse or chatbot connected by OAuth to many tenants	One integration's tokens unlock many customers' data	Third-party OAuth grants with broad scopes and no expiry
Control plane	Device management, remote management or orchestration tools	Compromise or fault reaches every managed asset	Tool can push code or scripts to all endpoints without approval
Workflow and process	One clearing house, payment processor or managed service provider	Business process stops even though your own systems are fine	No manual or alternate route for the process

For the cloud-specific view, including exit strategies, see the Cloud Concentration Risk and Exit Strategy Guide.

What the July 2024 CrowdStrike outage showed

The facts come from CrowdStrike's preliminary post-incident review and its root cause analysis of 6 August 2024.

Exposure window: a Rapid Response Content update (Channel File 291) was released at 04:09 UTC on 19 July 2024 and reverted at 05:27 UTC. Windows hosts running sensor 7.11 or later that were online in that window and received the update crashed. Mac and Linux hosts were not affected.
Scale: Microsoft estimated 8.5 million Windows devices were affected, which it described as less than one percent of all Windows machines.
Root cause: the IPC Template Type, introduced in sensor 7.11 in February 2024, defined 21 input fields but the integration code supplied 20. The Content Validator passed the new template instances, which for the first time used a non-wildcard match on the 21st field. The Content Interpreter had no runtime bounds check, so the out-of-bounds read crashed the system.
Recovery: CrowdStrike reported about 99% of Windows sensors back online by 29 July 2024. Many machines needed hands-on remediation, and BitLocker-protected devices needed recovery keys, which turned a software fault into a logistics and key management problem.
Vendor changes: CrowdStrike committed to compile-time and runtime input checks, staged deployment of content in rings with bake time and rollback, customer control over where and when Rapid Response Content is deployed, and independent reviews of sensor code and its release process.

The lesson for customers is that "content" or "configuration" updates from a privileged agent are changes to production, even when the vendor does not call them software. Your own change control, staging and rollback must reach them. For the broader incident lessons see the Major IT Outage Lessons Guide.

What regulators expect

Regime	Who it targets	Concentration-relevant requirements
EU DORA (Regulation 2022/2554), Articles 28 to 44	Financial entities and critical ICT third-party providers (CTPPs)	Register of information for all ICT arrangements (templates in ITS 2024/2956); assessment of ICT concentration risk before contracting for critical or important functions; exit strategies; mandatory contract terms; direct oversight of CTPPs by the European Supervisory Authorities
EU CTPP designation	Providers designated by the ESAs	The ESAs published the list of designated CTPPs on 18 November 2025, using data from financial entities' registers of information; oversight proceeds through examination activities
UK critical third parties regime (Bank of England, PRA and FCA, PS16/24 and PS24/16)	Third parties designated by HM Treasury under FSMA s312L	Six Fundamental Rules; eight Operational Risk and Resilience Requirements covering governance, risk management, dependency and supply chain risk, technology and cyber resilience, change management, mapping, incident management and termination; incident reporting; self-assessment; scenario testing and annual incident exercises with firms. Rules took effect on 1 January 2025 but apply to a provider only once designated
FSB toolkit (4 December 2023)	Financial institutions and authorities globally	Common terminology; identifying critical services; lifecycle third-party risk management; supervisory tools; identifying and managing systemic third-party dependencies

Two points are often missed. First, designation of a provider as a CTPP or CTP adds supervisory oversight of the provider; it does not reduce the customer firm's own obligations. Second, the register of information is the data source supervisors use to see concentration across the sector, so poor register data hides your exposure from you and misstates it to them. Check the current list of designated providers on the ESAs and Bank of England pages before relying on any provider's status. See the DORA Guide and the DORA and NIS2 Overlap Mapping Guide.

Finding and measuring concentration

Start from business services, not from the supplier list. For each important service, map the chain of technology, providers and credentials it needs to run, then look for the points that appear in many chains.

List important business services and their impact tolerances (maximum tolerable outage, data loss). Use your business impact analysis. See the Business Impact Analysis Template.
Map each service to its dependencies: hosting, identity provider, DNS, endpoint and server agents, SaaS platforms, integration tokens, managed service providers, and their key subcontractors.
Record privilege and update path for each dependency: does it run at kernel or administrator level, can it push changes without your approval, and can it reach all hosts at once.
Score concentration using the indicators below and rank the dependencies by how many important services share them.
Test the top five with a scenario exercise: provider down for 72 hours, provider compromised, provider update bricks every host.

Indicator	How to measure	Why it matters
Service fan-out	Number of important business services that fail if this provider fails	Core measure of entity-level concentration
Host coverage of privileged agents	Percentage of endpoints and servers running the agent with kernel or administrator rights	Shows the blast radius of a faulty update
Update control	Whether you can stage, delay or pin vendor content and code updates	Determines whether a faulty update reaches 100% of hosts
Credential concentration	Number of production secrets and OAuth grants held in each third-party platform	Shows how much must be rotated after that provider is breached
Substitutability	Time and cost to move the service to an alternative, from the exit plan	Low substitutability raises the stakes of every other indicator
Fourth-party overlap	Number of your critical providers that rely on the same hosting or identity provider	Reveals hidden supply chain concentration

Options to reduce or absorb concentration

Option	What it involves	Best when	Trade-off
Diversify providers	Two providers for the same function (dual cloud, two DNS providers, mixed endpoint agents on critical clusters)	Function is simple to duplicate and failure is intolerable (DNS, payments routing)	Double the skills, integration and security surface; can create new single points in the integration layer
Stage and control updates	Use vendor ring and policy controls so content and code reach a test group first; pin versions on critical systems	Privileged agents and SaaS platforms with automatic updates	Slower protection updates on later rings; needs monitoring of canary hosts
Segment the blast radius	Different agent policies, tenants or accounts per business unit or tier	Large estates where one policy currently covers everything	More configuration to manage
Manual and degraded-mode fallback	Paper processes, offline lists, alternate communication channels	Workflow concentration (clearing houses, booking systems)	Must be exercised or it decays
Recovery readiness	Offline access to recovery keys, local admin access, bootable recovery media, staffed playbooks	Every estate with full-disk encryption and central agents	Recovery keys and local admin credentials become high-value secrets to protect
Contract and exit	Notification, audit, testing and exit terms; transition assistance; data portability	Any critical provider, and required under DORA for critical or important functions	Leverage depends on your size relative to the provider

Decision guidance

Small organisations: full diversification is rarely affordable. Focus on update staging, offline recovery, a written fallback for the two or three most important processes, and contract terms that give notice of incidents.
Large organisations: diversify where function is simple and impact is high (DNS, internet connectivity, critical clusters), and use segmentation and staged updates elsewhere. Run sector-level exercises where your regulator offers them.
Security tools: resist the instinct to remove protection after an outage. Faster recovery and staged rollout reduce risk without leaving hosts unprotected. See the EDR Guide.

Identity and credential concentration

Concentration also shapes how attacks spread. An identity provider, secrets platform or integration hub is a single place where many credentials meet, so a breach there scales in the same way an outage does.

Identity provider: one IdP for workforce, administrator and application SSO is efficient but makes the IdP both an availability and a compromise single point. Keep break-glass accounts that do not depend on the IdP, store their credentials offline, and alert on every use. See the Identity Provider and SSO Security Guide.
Recovery credentials: BitLocker recovery keys and local administrator passwords became the bottleneck in July 2024. If they are only retrievable from a system that is itself down, recovery stalls. Store them where a degraded estate can still reach them, with access logged.
Secrets held by third parties: keep an inventory of which API keys, deployment credentials and OAuth grants sit in which SaaS or CI/CD platform, so a provider breach becomes a scripted rotation, not a search. See the Secrets Management Guide.
Integration tokens: scope OAuth grants narrowly, set expiry and review unused integrations. See the SaaS Security Guide.

Implementation roadmap

Weeks 1 to 4, inventory: extend the third-party register with business service mapping, privilege level, update path and credentials held. Use DORA register of information fields as the template even outside the EU.
Weeks 4 to 8, rank: score every critical provider on the six indicators and agree a risk appetite statement with the executive committee, such as "no single provider failure may stop more than one important business service beyond its impact tolerance".
Weeks 8 to 12, quick wins: enable update rings or staging for privileged agents, starting in audit or test groups; move recovery keys and break-glass credentials to an offline-reachable store; write fallback procedures for the top three workflows.
Quarter 2, test: run a tabletop for a mass-endpoint failure and one for a provider breach that requires rotating all stored secrets. See the Tabletop Exercise Scenario Pack.
Quarter 3, contracts and exit: renegotiate terms at renewal (incident notice, staged release commitments, audit and exit assistance) and write exit plans for each critical provider.
Ongoing, rollback discipline: every staging or diversification change keeps a documented rollback, for example returning a ring policy to its previous setting if canary hosts show protection gaps.

Detection and metrics

Monitor provider status feeds and your own canary hosts in the first update ring, alert on sudden loss of heartbeats from agents across many hosts, and log every retrieval of recovery keys and break-glass credentials. Track:

Percentage of critical providers with a mapped service dependency and a tested exit or fallback plan.
Percentage of privileged agents under customer-controlled staged updates.
Time to restore a representative endpoint from a failed boot in exercises.
Number of important services that share a single provider with no tested fallback (target: falling).
Time to rotate all secrets held by a given third-party platform, measured in an exercise.

Framework mapping

Topic	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A
Supplier criticality and inventory	GV.SC-04, ID.AM-04	SR-2, RA-9, SA-9	5.19, 5.22
Supplier risk assessment and contracts	GV.SC-05, GV.SC-06, GV.SC-07	SR-3, SR-5, SR-6	5.20, 5.21
Suppliers in incident response and recovery	GV.SC-08, RS.MA-01	IR-8, CP-2	5.24, 5.29
Exit and end of relationship	GV.SC-10	SR-2, CP-2	5.23
Resilience and alternate capability	PR.IR-03, PR.IR-04	CP-7, CP-8, CP-10	5.30, 8.14
Change and update control	ID.IM-02	CM-3, CM-4	8.32
Monitoring of external providers	DE.CM-06	SA-9	5.22

Common failure patterns

Counting contracts, not dependencies. A provider with one small contract can still sit under every critical service, as the endpoint agent did in July 2024.
Exempting vendor content from change control. Detection content, policy files and feature flags pushed by a vendor are production changes; without staging they reach every host at once.
Recovery that depends on the failed layer. Recovery keys held only in a system that cannot be reached, or break-glass access through the IdP that is down.
One SaaS platform holding many tenants' credentials without strong authentication. In the Snowflake Breach 2024, infostealer credentials without MFA opened about 165 customer environments at one provider.
Integration tokens that unlock many customers. In the Salesloft Drift Breach 2025, stolen OAuth tokens for one chatbot integration were used against hundreds of Salesforce tenants.
No fallback for a workflow provider. The Change Healthcare Breach 2024 stopped claims and pharmacy processing for providers across the US for weeks, though their own systems were intact.

Lessons from incidents

The availability and security incidents share one pattern: a provider sits in the path of many customers, and its failure mode is copied to all of them. In the CircleCI Breach 2023, a stolen engineer session led the provider to tell every customer to rotate all secrets stored on the platform. How fast a customer could respond depended on whether it already knew which secrets lived there. In July 2024 the equivalent question was whether recovery keys and hands-on staff were reachable while the estate was down. In both cases the controls that mattered were inventory, rehearsed recovery and the ability to act without the provider. For more cases see the Top 10 Supply Chain Attacks.

Practitioner checklist

Map every important business service to its providers, agents, identity dependencies and credentials, and record fourth-party hosting.
Score critical providers on fan-out, privilege, update control, credentials held, substitutability and fourth-party overlap.
Enable staged or ring-based updates for every privileged agent, and treat vendor content as a production change.
Keep recovery keys, local admin and break-glass credentials retrievable when the IdP and central tools are down, with every retrieval logged.
Maintain an inventory of secrets and OAuth grants held by each third-party platform, with a rotation runbook.
Write and test fallback procedures for the top three workflow dependencies.
Add incident notice, staged release, audit and exit assistance terms at contract renewal.
Run at least one mass-outage and one provider-breach exercise a year, and track time to recover.
For regulated firms, keep the DORA register of information or equivalent accurate, and check the current CTPP and CTP designation lists.

Third-Party Concentration Risk Guide: Lessons from the July 2024 CrowdStrike Outage