When the Cloud Goes Dark

INDEPENDENT EVIDENCE

October 7, 2026. Around 3:40 a.m. in Japan.

Ransomware hits IDCF Cloud. It is run by IDC Frontier, a SoftBank company, and businesses and local governments across Japan run on it.¹⁴

Four zones in its East Japan Region 1 go down. Virtual servers stop. They will not restart.¹³

The count: 495 companies and local governments.¹³

Ibaraki Prefecture's government and police websites go dark. The prefecture puts up a temporary site so it can keep sharing disaster information.¹⁵

A software company called Six Apart has 31 servers stuck inside. A business marketplace can't be reached. Inventory and price-update services stop.¹⁵¹⁶

Then comes the hardest line in IDC Frontier's update. The customer data in those four zones will be hard to retrieve or restore. Customers can rebuild only from backups they kept themselves.¹³

Screenshots posted by customers show the attacker bragging that it took seven minutes to get in. That is the attacker's claim, not a verified fact.¹⁴

Two outages, not one

Look closely and there are two outages here.

The first is the attack. Ransomware locked up the servers in four zones. No containment decision caused that.

The second is caution. IDC Frontier cut Region 1 off from the network. Then it switched off the customer management console in every other region too, where no break-in had been found.¹³

Customers in those regions still had running servers. They just couldn't touch them. To start or stop their own machine, they had to ask IDC Frontier to do it for them.¹³

That is not a criticism. With an attacker inside and the way in still unknown, it was the responsible call. It is what any team does when it cannot yet prove what is safe.

But it shows the price of not knowing.

The attack hit four zones.
The uncertainty reached every customer.

Be clear about what this was

This was an attack on cloud software, not on a building. Nothing public ties it to a cooling controller, a power monitor, a door system or any device Findavi watches. IDC Frontier has not said how the attackers got in.¹³

We don't claim Findavi would have stopped it.

So why is it in this book?

Because it is idea three, playing out in public: in a shared facility, the defense can cause the outage. When you can't see the safe boundary, you draw it wide.

The customers who were ready

One detail matters more than the rest.

Six Apart kept seven daily backups of every server on a different cloud, Google Cloud.¹⁷ The copy it used was taken at 1:00 a.m., less than three hours before the attack. By 9:00 p.m. the next day, all 31 servers were running again on another provider.¹⁸

Other customers found out that their data lived in one place. And that place was gone.

The lesson

One lesson for each side of the contract.

If you run the facility: know your safe boundary before the bad night. Which devices, paths and controls can be isolated on their own? Which must stay on? Who can approve the change? Decide it on a calm Tuesday, not at 3:40 a.m.

If you rent the cloud: your provider's bad night is your bad night. Keep a backup somewhere else. Then prove you can rebuild from it.

The rest of this book is about the first lesson, for the building systems underneath. Small actions. Approved in advance. Checked twice.