The attacker says it took seven minutes. 495 organisations are now learning if their backups lived in the same cloud.

At about 03:40 Japan time on Wednesday 7 October, IDC Frontier detected unauthorised access in "East Japan Region 1" of its IDCF Cloud platform, a data-center region in Shirakawa, Fukushima Prefecture. IDC Frontier is a subsidiary of SoftBank Group, and IDCF Cloud is its infrastructure-as-a-service offering: virtual servers, storage and networking rented by companies and public bodies across Japan.

The company confirmed it was ransomware. It cut the region off the network, shut its systems down, and, as of 9 October, the region was still isolated with no restoration timeline.

This was not one customer's breach. Every reported detail points to the platform underneath them. If your recovery plan lives inside the same provider as your production servers, this article is about you.

WHAT ACTUALLY HAPPENED

IDC Frontier said "a disruption in East Japan Region 1 was caused by a ransomware attack by a third party". An automatic shutdown activated, the region was isolated to stop the damage spreading and to prevent data leaks, and the company began checking its other regions.

As a precaution, customer access to management consoles was disabled for every region, not only the affected one, until the company confirms it is safe. IDC Frontier operates three regions in eastern Japan and one in western Japan.

495 companies and local governments hold contracts tied to East Japan Region 1. IDC Frontier has not published the client list and is contacting customers individually. Among those reported publicly: the websites of Ibaraki Prefecture and the Tokyo city of Kodaira could no longer be viewed or updated, along with sites run by Tobu Zoo and the news agency Jiji Press.

At least one prefecture reported that it could not access its backup data after the provider's systems went down.

IDC Frontier's own FAQ says some customer data in "certain zones of East Japan Region 1" has been difficult to retrieve, and some affected organisations were told restoring their data could be difficult. The company says it is building an alternative environment while the investigation continues.

WHAT THE ATTACKER CLAIMS

Customers who could reach their consoles saw a message from the attacker. According to that message, the intrusion took seven minutes, reached 239 hypervisors, sealed 16,000 virtual machine disks, encrypted 225 databases holding 3.6 petabytes of data, and wiped 554,153 snapshots.

None of these figures has been confirmed by IDC Frontier. The group has not been named, and there is no public information yet on the initial intrusion route, a ransom demand, or whether data was stolen as well as encrypted.

But the shape of the claim matters even if the numbers are inflated. The attacker is not describing one company's file server. It is describing the virtualisation layer of a whole cloud region: the hypervisors, the disks attached to them, and the snapshots taken of them.

WHY SNAPSHOTS ARE NOT BACKUPS

A snapshot is a point-in-time copy of a virtual disk. It is fast, cheap and extremely useful. It is also stored on the same storage platform, managed by the same hypervisor, and controlled from the same administrative plane as the virtual machine it protects.

That is fine when the failure is a bad patch or a deleted file. It is useless when the failure is the platform itself. Whoever controls the hypervisor layer controls the snapshots, and can delete them as easily as the virtual machines.

Many IaaS customers do exactly what the console makes easy: scheduled snapshots, the provider's own backup service, perhaps a copy in a second zone of the same region. On a diagram that looks like three layers of protection. In reality all three sit under one operator, one control plane and one set of privileged credentials. When that layer is lost, they are lost together.

A backup that shares a failure domain with production is not a backup. It is a second copy of the same risk.

THE SHARED RESPONSIBILITY GAP

Every cloud provider publishes a shared responsibility model. In infrastructure-as-a-service, the provider secures the physical data center, the network and the hypervisor. The customer secures the operating system, the applications and the data.

Read it carefully and there is a gap. The model says who is responsible for securing the hypervisor. It says much less about who gets your data back when the hypervisor layer is compromised. Provider SLAs measure availability and typically compensate in service credits. They do not rebuild your servers.

So the customer remains responsible for recovery, even from a failure it could not prevent and could not see. The only way to meet that responsibility is a copy the provider's failure cannot reach.

WHY MUNICIPALITIES FEEL IT FIRST

Local governments moved to shared cloud platforms for good reasons: cost, staff shortages, and the difficulty of running small data centers securely. Many smaller organisations, in Japan and elsewhere, rent virtual servers from a regional provider rather than building their own resilience.

The trade-off is concentration. One region, one operator, hundreds of tenants. When the region goes down, every tenant loses its public website, its internal systems and, too often, the backup it planned to restore from, all at the same time.

For a prefecture or a city, "the cloud is down" now means the services it is legally required to run are down. And the copy that was supposed to bring them back is down too.

NOT A ONE-OFF

Japan is going through an exceptional year. Security firm Macnica has logged 119 cybersecurity incidents involving the theft or exposure of personal information in Japan so far in 2026, 83 of them between 1 July and 6 October. Using the same criteria, it counted 84 in all of 2025 and 62 in 2024.

The same week, Nissui Logistics, the logistics arm of seafood group Nissui, reported a system outage caused by suspected unauthorised access at a third-party data center it uses, halting shipments. No link to the IDCF incident has been confirmed.

And the attack pattern is not new. Ransomware groups have targeted hypervisors directly for years, because one compromised management layer can encrypt hundreds of virtual machines at once. What changes with a shared cloud region is the blast radius: the same move now hits hundreds of organisations instead of one.

WHAT TO DO NOW

KEEP ONE COPY OUTSIDE THE PROVIDER — at least one backup must live with a different operator, under different credentials, in immutable or offline storage that nobody in your production environment can delete.

TREAT SNAPSHOTS AS CONVENIENCE — use them for quick rollbacks after a bad change, never count them as your recovery plan, and never list them as a backup in a continuity document.

REHEARSE REBUILDING ELSEWHERE — test standing up your critical services with another provider or on-premises from that external copy, and measure the time it takes in hours rather than assuming it.

SEPARATE THE KEYS — the credentials that manage your backups must not be the same as the credentials that manage your cloud tenancy, and must not be reachable from it.

ASK YOUR PROVIDER HARD QUESTIONS — how is the hypervisor administration plane protected, how quickly will you be told about a compromise, and what will you still be able to access when they isolate a region?

WRITE DOWN THE CONCENTRATION RISK — list every critical service that depends on a single provider region, including its backup, and present that list to management as a business risk, not an IT detail.

WHAT TO READ WITH CARE

The start time, the region, the number of affected contracts and the containment steps come from IDC Frontier's statements as reported by BleepingComputer, Jiji Press and ITmedia. The seven minutes, 239 hypervisors, 16,000 disks, 3.6 PB and 554,153 snapshots are the attacker's own claims, displayed to customers, and are not verified. The report that one prefecture could not access its backups comes from MLex, which does not name the prefecture. Some outlets report that several zones were damaged badly enough that customers will have to rebuild elsewhere; IDC Frontier's FAQ confirms only that data in some zones has been difficult to retrieve. The attacker's identity, the intrusion route and any data theft remain unknown, and the situation may have changed since 9 October.

THE UNCOMFORTABLE PART

Most organisations that lost their servers on 7 October did nothing wrong by the usual checklist. They had snapshots. Many had backups. They used a reputable provider owned by one of Japan's largest technology groups.

What they did not have was a copy that could survive the loss of whoever runs their servers. That is the question this incident puts to every organisation in the cloud, in Japan or anywhere else.

Your backup is only a backup if it survives the loss of whoever runs your servers.

If your cloud region went dark tonight, where is the copy you would restore from?