Cloud Provider Concentration Risk After the IDCF Cloud Ransomware

Concentration risk is what you carry when many of your services depend on one provider, region or control plane. The IDCF Cloud ransomware outage of 7 October 2026 hit 495 organisations at once. If you run on any cloud or hosting provider, map services to providers and regions, keep backups elsewhere, and test both restores and exits.

Our first post on the IDCF Cloud ransomware covers the timeline, who was affected and the disputed attacker claims. This one is the working guide: finding your concentration, backups and exit plans, contract terms, and what regulators in the EU, India, Japan and the US have written down.

Nothing here is legal advice. Where we describe a regulation, we summarise the text we fetched and name it.

What the IDCF notices teach about concentration

IDC Frontier, a SoftBank company, publishes numbered notices on idcf.jp. Times are Japan Standard Time.

On the customer side, Impress Watch reported on 8 October that Six Apart, with 31 Movable Type cloud servers affected, did not expect recovery on IDCF Cloud and was restoring in stages at another provider from its backup data. That is an exit plan in use.

BleepingComputer reported a message, seen by customers, claiming hundreds of hypervisors reached and over half a million snapshots wiped. IDC Frontier has not confirmed it, and its 5th report says snapshot users' backup data was safe. Treat those figures as unverified attacker claims.

What concentration actually means

Concentration shows up in layers, and each can fail on its own.

You can be multi-cloud on paper and still concentrated, because your email platform, your web agency and your payments partner all run on one host you never chose. That is fourth-party risk: your supplier's supplier.

Step 1: Map services to providers and regions

1. List business services, not servers. "Online ordering", "customer email". Give each an owner and a tier.
2. Record where each runs. Provider, region, zone, and whether it is your account or a supplier's.
3. Record where its data and backups live, and who holds those credentials.
4. Add suppliers that host for you. Ask them which provider and region they use.
5. Count. Critical services per provider region, and services that back up to the provider they run on.

Pull locations from your own accounts:

# AWS: instances in every region with a Service tag and Availability Zone
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws ec2 describe-instances --region "$r" \
    --query 'Reservations[].Instances[].[Tags[?Key==`Service`]|[0].Value, Placement.AvailabilityZone]' \
    --output text
done

# Google Cloud and Azure equivalents
gcloud compute instances list --format="table(name, zone.basename(), labels.service)"
az vm list --query "[].{name:name, location:location, zones:zones, service:tags.service}" -o table

For public endpoints and suppliers, DNS helps. The SPF record lists every service allowed to send mail as you:

dig +short CNAME shop.example.com
dig +noall +answer shop.example.com     # second column is the TTL in seconds
dig +short TXT example.com | grep -i spf
whois 203.0.113.10 | grep -iE 'netname|orgname|org-name'

Keep the map as a CSV and let the shell count:

# services.csv: service,owner,tier,provider,region,data_location,backup_location,backup_provider
awk -F, 'NR>1 && $3=="critical" {print $4" / "$5}' services.csv | sort | uniq -c | sort -rn
awk -F, 'NR>1 && $4==$8 {print $1": runs and backs up on "$4}' services.csv

The first command shows how many critical services sit in each provider region. The second lists services in the position IDCF customers were told about on 8 October.

Step 2: Backups that live outside the provider

A backup counts here only if it survives the provider being down, compromised or slow to respond. That means:

• Different provider or on premises, not another region of the same provider.
• Different credentials, so no identity at the primary provider can delete it.
• Immutable or offline: object lock, write once storage, or disconnected media.
• Readable without the primary, with open tools on a machine you control.

Japan's Financial Services Agency makes the ransomware point directly. Its Guidelines for Cybersecurity in the Financial Sector (4 October 2024) set as a basic expectation backup rules covering isolation and protection of backup data, integrity checks and restore tests. The guideline notes that some ransomware hunts for and deletes backups on the same network, and points to tamper resistant backup systems and copies kept in multiple environments cut off from the internal network.

# Example off-provider copy in S3 with Object Lock (enable it when creating the bucket).
aws s3api create-bucket --bucket acme-offsite-backups --region us-east-2 \
  --create-bucket-configuration LocationConstraint=us-east-2 \
  --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket acme-offsite-backups \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

# Portable nightly dump, then copy restic snapshots to the off-provider repository
pg_dump -Fc -d shop -f /srv/backups/shop-$(date +%F).dump
restic -r s3:s3.us-east-2.amazonaws.com/acme-offsite-backups \
  copy --from-repo /srv/restic-primary --from-password-file /etc/restic/primary.pass

If your primary is the provider offering S3, use another provider's immutability feature or on-premises storage. Also keep what you need to rebuild:

skopeo copy --all docker://registry.primary.example/shop-api:2026.10 \
  docker://registry.secondary.example/shop-api:2026.10
git remote add offsite git@git.secondary.example:ops/infrastructure.git
git push offsite --all && git push offsite --tags

Step 3: Restore testing that proves recovery

A green backup job proves the job ran. Only a restore proves recovery. The EU's Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, Article 12, requires financial entities to test backup and restoration procedures periodically, to restore onto systems physically and logically segregated from the source, and to set recovery time and recovery point objectives per function.

1. Pick one critical service and rotate through them over the year.
2. Restore into a clean environment at a different provider.
3. Time it from start until the service answers a real request.
4. Measure data age: the newest restored record is your real recovery point.
5. Check integrity with row counts and a query whose answer you know.
6. Log it and fix one thing.

START=$(date +%s)
restic -r s3:s3.us-east-2.amazonaws.com/acme-offsite-backups \
  restore latest --target /srv/restore-drill
createdb shop_drill
pg_restore -d shop_drill /srv/restore-drill/srv/backups/shop-2026-10-20.dump
psql -d shop_drill -c "select max(created_at) as newest_order, count(*) from orders;"
END=$(date +%s); echo "restore took $(( (END-START)/60 )) minutes"

Restores usually fail outside the data: secrets, DNS, licences, images that exist only in the primary registry.

Step 4: Exit plans you have rehearsed

An exit plan answers: if this provider is gone for weeks, how do we run elsewhere, and how long does it take? IDCF customers in the four zones had to answer that at short notice.

DORA Article 28(8) requires exit strategies for ICT services supporting critical or important functions. Per the regulation text, they must be documented, sufficiently tested and reviewed periodically, with alternative solutions and transition plans identified. The Reserve Bank of India's 2023 Master Direction on outsourcing of IT services requires a clear exit strategy in the outsourcing policy (paragraph 22(1)); its cloud annex adds turnaround times for returning data, data portability and secure purging of data at the provider.

Step 5: Contract and notification terms

Contracts will not stop ransomware, but they decide what you get on the bad day. Clauses worth checking, with where the fetched texts mention them:

Two fetched texts put numbers on notification. RBI paragraph 17(8) says providers must report cyber incidents to the regulated entity without undue delay, so the entity can report to RBI within six hours of the provider's detection. In the US, the FDIC's summary of the Computer-Security Incident Notification Rule says a bank service provider must notify affected bank customers as soon as possible after an incident that disrupted or degraded covered services, or is reasonably likely to, for four or more hours; banks notify their regulator within 36 hours of determining a notification incident occurred.

Unregulated teams can still ask: if a region fails at 03:40, who calls us, by when, and how?

What regulators expect

A summary of primary texts fetched on 21 October 2026. Applicability depends on who you are; read the source and take advice.

European Union, DORA. EIOPA says DORA entered into application on 17 January 2025 and sets up EU wide oversight of critical ICT third-party providers to address concentration risk from reliance on a limited number of providers. Article 28(3) requires a register of all ICT service contracts, flagging those that support critical or important functions. Article 28(4) requires assessing, before contracting, whether an arrangement adds to ICT concentration risk. Article 29 asks whether a provider is "not easily substitutable", whether several arrangements sit with the same or closely connected providers, and how subcontracting chains, insolvency law and urgent data recovery constraints affect the picture.

India, RBI. The Master Direction was issued 10 April 2023 and took effect 1 October 2023 for material IT outsourcing by commercial banks, certain cooperative banks, larger NBFCs, credit information companies and all India financial institutions. Paragraph 17(10) requires assessing concentration risk from many outsourcings to one provider or reliance on a few providers for critical functions. Paragraph 18(2) asks contingency planning to consider alternative providers or bringing work in house, and the cloud annex expects critical operations to continue with minimal disruption if the cloud provider fails.

Japan, FSA. The October 2024 guideline applies to banks, insurers, securities firms, crypto asset exchanges and other listed financial businesses. Section 2.6 sets as basic expectations a third-party ledger recording what data each holds or processes and where (item 5), and contract or SLA terms covering incident reporting, data location and disposal, and termination (item 8). It lists as desirable, not basic, considering concentration risk and fourth parties (item b) and preparing tested contingency plans and exit strategies for important third parties (item d).

United States, banking agencies. The Federal Reserve, FDIC and OCC issued Interagency Guidance on Third-Party Relationships on 7 June 2023; the Fed's cover letter says it "does not impose any new requirements". The guidance names dependency on a single provider for multiple activities as a resilience consideration, and says contracts often require recovery time and recovery point objectives, joint continuity tests, and the ability to move data to another third party without penalty if the provider fails.

What would have helped

None of this comments on any named organisation. These practices reduce the damage when any shared provider has a serious incident.

Practices any team can use

• A living service map and a concentration number reviewed each quarter, with a ceiling for critical services per provider region.
• One immutable copy outside the provider for every critical service, under separate credentials, plus mirrored images and infrastructure code.
• Timed restore drills and rehearsed exits at a second provider, logged, with an account there already open.
• Contract reviews at renewal against the clause table, especially notification channel, data return format and transition periods.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It concerns open source packages, not a provider's infrastructure, and has no bearing on how the IDCF intrusion happened, which IDC Frontier has not disclosed.

Gold Open Source at gold.safeguard.sh is free with no login: CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is paid: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3+, Sigstore-signed, with evidence pages; an artifact loses its badge on regression.

The link to concentration risk is the rebuild. When you stand a service up at a new provider in a hurry, pull patched, signed components from a curated source and rebuild, rather than reviving whatever old image you last had.

Where Safeguard fits

Plainly: Safeguard does not stop a provider's ransomware, back up your data, run failover, or watch a provider's hypervisors. It would not have kept workloads in the affected zones online. What it does touch:

• A home for the vendor map. Third-Party Risk Manager (generally available) onboards vendors, requests SBOMs, projects or products from them, scores and monitors supplier risk, and applies policies and gates. Its scoring rests on what vendors share; it would not have predicted a provider breach. The compliance suite's Vendors and Risks views can hold "four critical services on one region" as a risk with an owner, with drill logs attached as evidence.
• Knowing what you would rebuild. safeguard scan --dir ., --image <name> and --sbom <file> produce SBOMs with JSON results under ./output. The platform shows which projects contain a given component and version, with vulnerability matching and reachability analysis. See SBOM incident response: finding affected products fast.
• Checking rebuilt images at the new registry before go-live, with platform policies and gates holding back known vulnerable ones.
• Drill work with approval. The CLI's assistant can edit code and run commands with your approval, for example writing the Step 3 drill script or porting a Terraform module. /permissions offers Ask, Accept edits, Plan, Auto (the default) and Strict; safeguard exec runs in CI; the desktop and phone apps send work to a computer running the CLI and approve each command.

To try it, download Safeguard and read the CLI documentation. For the wider month, see October 2026 security incidents and what would have helped, and for another continuity call made under pressure, why governments took websites offline over PHP2Shell.

Common mistakes and troubleshooting

• Treating a second region as a second provider. IDCF paused consoles in every region.
• Backups the primary provider's admin can delete. One identity reaching both means one copy.
• Mapping servers, not services, and skipping suppliers who host for you.
• Drill stalls on secrets. Keep an encrypted escrow of critical secrets off-provider and include it in drills.
• docker pull fails at the new provider. Images lived only in the primary registry; mirror them as in Step 2.
• Failover takes a day. Day-long DNS TTLs; lower them in advance.

FAQ

What is cloud concentration risk?

The risk that one provider, region or shared component fails and takes many services, or many organisations, down at once. IDC Frontier says the IDCF outage affected 495 companies and local governments through one region.

Did IDCF customers who used snapshots get data back?

IDC Frontier's 5th report (14 October) said backup data for 194 snapshot users was safe and being returned case by case. On 18 October it resumed its backup service for restores to other clouds or on premises; snapshots stayed suspended.

Do we need a second provider for everything?

Usually not. Critical services need an off-provider backup and a tested path to run elsewhere; others may only need off-provider backups and a documented rebuild.

How often should we test restores?

Enough that every critical service is restored at least once per planning cycle and after major changes. DORA Article 12 and the FSA guideline call for periodic testing without fixing a frequency in the passages we read.

Does DORA apply outside EU finance?

DORA applies to the financial entities it lists. Providers usually meet it through customer contracts, and EIOPA describes separate oversight of critical ICT third-party providers. Ask counsel how it applies to you.

Would Safeguard have prevented this?

No. Safeguard does not protect a provider's infrastructure. It can hold your vendor map, record concentration risk with evidence, and show what software you would rebuild elsewhere.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

This real CLI session fixes a lodash CVE: the assistant asks before each command, edits package.json, runs npm install and npm test with approval, and pushes nothing. It is not IDCF. For a move to a second provider, you would ask it to update deployment manifests for the new target, approve each command, then run /scan ..

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For a restore drill, you would pick your scripts folder, ask for the Step 3 drill, and approve each restic and pg_restore command yourself.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It shows no IDCF data. Once connected, you could ask Claude about the vendor and project records you keep in Safeguard, within the tool access you allowed.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IDC Frontier: 2nd report on unauthorised access (7 Oct 2026, Japanese)
• IDC Frontier: 3rd report on the outage (8 Oct 2026, Japanese)
• IDC Frontier: 5th report on investigation progress (14 Oct 2026, Japanese)
• IDC Frontier: 6th report on resuming the backup service (18 Oct 2026, Japanese)
• Financial Services Agency of Japan: Guidelines for Cybersecurity in the Financial Sector (4 Oct 2024, Japanese PDF)
• Reserve Bank of India: Master Direction on Outsourcing of IT Services (10 Apr 2023)
• EIOPA: Digital Operational Resilience Act (DORA)
• DORA Article 12 (Springlex reproduction of Regulation (EU) 2022/2554)
• DORA Article 28 (Springlex reproduction)
• DORA Article 29 (Springlex reproduction)
• DORA Article 30 (Springlex reproduction)
• Federal Reserve: SR 23-4 cover letter (7 Jun 2023)
• Interagency Guidance on Third-Party Relationships: Risk Management (PDF)
• FDIC FIL-74-2021: Computer-Security Incident Notification Rule
• Impress Watch: IDCF Cloud outage caused by ransomware (Japanese)
• BleepingComputer: Ransomware attack disrupts Japan's IDCF Cloud used by govt clients

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.