On 7 October 2026, a ransomware attack on one cloud region in Japan disrupted customers in that region, including companies and local governments. They were not breached one by one. They shared a provider, IDC Frontier, and the provider was the event. If you run on a single cloud, this is the scenario your continuity plan has to answer.
What happened at IDCF Cloud
IDC Frontier, a SoftBank company, reported a ransomware attack by a third party against its East Japan Region 1, beginning at about 03:40 JST on 7 October. The region was cut off and shut down, and management consoles in the provider’s other regions were paused.
On 8 October, IDC Frontier named four zones — tesla, henry, pascal and joule — where, as of 8 Oct, the provider said data would likely be impossible to retrieve. Customers in those zones were initially told to rebuild elsewhere using backups they held themselves. On 14 October, the provider said it had found no evidence to date that customer data in the four zones was viewed or taken, and said snapshot backup data for 194 snapshot-using customers would be delivered case by case. Provision of backup data by the provider resumed on 18 October — for restores to other clouds or on premises — while the snapshot function remained suspended. Recovery belonged to whoever held a copy somewhere else.
Check 1: Is your second region just the same provider?
What it looks like. Your failover plan points at a second region of the same cloud. IDCF paused management consoles in other regions, healthy ones included.
The test. If this provider’s console and identity service were down for a week, what could you still operate, restore or rebuild? If the answer is “nothing,” your second region is a second room in the same house.
What good looks like. A named alternative provider or site for critical services, an account already open there, and one restore actually rehearsed in it.
Check 2: Can one admin identity delete your backups?
What it looks like. Your backups live on the same platform as production, under the same credentials — one compromised or unavailable account takes both. At IDCF, the provider’s backup tooling was paused eleven days, and snapshot users recovered on the provider’s timeline, case by case.
The test. Trace the copy you would restore your most critical service from. Who holds it, which credentials protect it, and could the identity that runs production delete it?
What good looks like. One copy of every critical backup outside the provider, under separate credentials, immutable or offline so it cannot be deleted from the primary side.
Check 3: Did you map services, or just servers?
What it looks like. Your inventory is a list of machines. Nobody can say which business services sit in which region — or which suppliers host theirs on your provider, making their outage yours.
The test. Take your five most critical services. For each: provider, region, where its data and backups live, and whether a supplier runs it for you.
What good looks like. A service map with an owner and tier per service, and one number reviewed regularly: critical services per provider region. That is your concentration number.
Check 4: Would your restore drill stall on secrets?
What it looks like. The data restores fine — then the rebuilt service cannot start, because the keys and passwords it needs live in the primary provider’s vault, which is the thing that is down. Restores usually fail outside the data itself.
The test. Restore one critical service, timed, into a clean environment elsewhere, and list everything the rebuild had to fetch from the primary provider. Each item is a stall.
What good looks like. An encrypted escrow of critical secrets held off the provider and used in drills, so a rebuild never waits on the platform it is fleeing.
Check 5: Do your container images exist anywhere else?
What it looks like. Your pipeline pulls images from one registry — the primary provider’s. On rebuild day elsewhere, the pull fails: the only copies of what you run lived inside the thing that failed.
The test. Obtain one production image with the primary registry unreachable. Do the same for your infrastructure code.
What good looks like. Images mirrored to a second registry and infrastructure code held off the primary provider, as a routine build step.
Check 6: How long are your DNS TTLs?
What it looks like. The service is rebuilt and healthy elsewhere, and traffic keeps going to the dead address for a day, because its DNS records carry a 24-hour TTL set years ago.
The test. Look up the TTL on your critical public records. That number is the floor on your failover time, however fast the rebuild.
What good looks like. Low TTLs on critical records, set in advance, with DNS you can change while your main provider is down.
The doctrine
None of this requires a second provider for everything. Critical services need an off-provider copy and a tested path to run elsewhere; the rest need the copy and a documented rebuild. What none of it survives is the assumption underneath all six failures — that redundancy inside one provider is the same as independence from it. It is not. Redundancy inside one provider is one provider.
Sources: Safeguard, “Cloud Provider Concentration Risk After the IDCF Cloud Ransomware,” safeguard.sh; Safeguard summary of IDC Frontier incident notices and BleepingComputer coverage.
Updated 2026-10-31: citation-QC refresh — unsupported claims tightened to sources.