Summary

  • IDCF said ransomware disrupted virtual machines in four zones of East Japan Region 1 from 7 October and affected 495 companies and local governments. The company stopped customer-facing consoles while it investigated; the public record does not identify the attacker, entry route, or the status of IDCF Cloud Backup.
  • IDCF’s product materials describe off-site backup storage and an immutable-storage option. That design speaks to where a copy sits. It does not, by itself, establish whether a customer can reach the backup catalogue and credentials while IDCF Cloud Console is unavailable, or provision compute elsewhere.
  • Two customers published different recovery paths. Six Apart moved 31 affected servers to Sakura Cloud using a Google Cloud backup from 01:00 on 7 October; Future Shop rebuilt an optional email service at another data centre while its core store and administration site remained outside the affected platform. Neither report says that the customer used IDCF Cloud Backup.

The most important sentence in IDCF’s incident guidance was not a promise about recovery. It was a route around an unavailable service: use the operating system to transfer files to another environment. For existing customers of IDCF Cloud Storage, the FAQ pointed to a second door—direct access through Google Cloud Console, provided the customer had the linked Google account and project information.

That advice is practical, but it describes more than one product. IDCF Cloud Storage is based on Google Cloud Storage. IDCF Cloud Backup is a separate managed service. The FAQ does not say whether its general statement that backup services were unavailable included that specific Veeam-and-Wasabi offering, which customer cohorts it covered, or whether any affected tenant had subscribed to it. Treating the GCS route as proof that the BaaS repository remained available would collapse two different systems into one.

A copy is only one part of recovery

IDC Frontier reported that the incident began at about 03:40 Japan time on 7 October. Its 8 October update named four affected zones—tesla, henry, pascal and joule—in East Japan Region 1. Virtual machines in those zones had stopped and could not be restarted. IDCF said data would be difficult to retrieve or restore and that, at that point, customer-held backups were the available restoration route. It also said the company had stopped the regional network and management console to limit further harm, then suspended external-facing consoles in other regions while checking their safety.

The 9 October update described an emergency response structure with parent SoftBank, customer guidance on backup and migration, and technical investigation with outside security specialists. It did not report a restoration result or a finished investigation. The latest public record therefore separates containment work from customer recovery; a response organisation is evidence of activity, not evidence that workloads are back.

The service design matters because IDCF had already made a commercial offer around this problem. Its March 2025 launch release described IDCF Cloud Backup as a Veeam service-provider backup service paired with Wasabi Hot Cloud Storage. The release listed ¥3,500 per protected server each month and ¥5 per gigabyte of storage. The current product page describes an operating-system agent, incremental copies, another-site cloud storage, an immutable-storage option and restoration to another server. It also says the backup service requires internet connectivity and that storage is currently offered in the East Japan area.

Those are meaningful product specifications. They describe the intended copy and restore model, not independent control of every step. The user guide starts the backup service from IDCF Cloud Console before opening Veeam Service Provider Console. The service-scope document permits local backup-console users that are not linked to an IDCF Cloud user. That is a potentially useful separation of account identities, but the public documents do not establish that a local user could reach the backup console through a direct route while the cloud console was down.

Nor do they say whether those local accounts were configured for any customer in the affected zones.

The storage page’s phrase “different site” is also narrower than a recovery guarantee. The current FAQ places backup storage in the East Japan area, while IDCF’s incident involved East Japan Region 1. The public record does not establish whether those locations share a failure domain. It would be wrong to treat a broad area label as proof of overlap; it would be equally wrong to treat it as proof of separation. Site, region, zone, identity provider, administrative console and restore destination are different dimensions.

Two customer rebuilds show what the copy price omits

Six Apart’s Movable Type Cloud update is unusually concrete. It said 31 servers in the affected IDCF region were moved to Sakura Cloud by 21:00 on 8 October, using the backup from 01:00 that morning. Its product documentation says the service kept seven daily backups in Google Cloud Storage in Tokyo. The 01:00 point is 2 hours 40 minutes before IDCF’s reported incident start, but the public report does not describe how much application data changed during that interval or whether other logs or replication filled the gap.

The record establishes a selected restore point and a completed migration task, not a universal recovery-time or recovery-point result.

The alternative destination was already part of Six Apart’s commercial offer before the incident. In June, the company had announced a Sakura Cloud plan. That does not make the migration costless: Six Apart warned that moving plans could change IP addresses, produce different storage or specifications, and take time. The customer’s ability to shift mattered because the destination, service plan and backup routine already existed. A cloud backup invoice alone would not have created those conditions.

Future Shop’s two updates show why resilience is not a single “company recovered” status. Only the mail-transfer servers for two optional email products—future Scenario Cast and futureCartRecovery—were hosted on IDCF; the main e-commerce site and administration console were elsewhere. Future Shop built a replacement mail environment at another data centre and resumed delivery by 12:30 JST on 9 October. Messages scheduled during the outage were not automatically resent. Delivery returning therefore closed one service interruption, not the lost communication window.

There was also a separate privacy question. Future Shop said the affected servers held some recipient addresses and message content that could include names, birthdays or member IDs. It said those records were encrypted while stored and automatically deleted after 14 days, while the start of the intrusion and possible data period remained unknown. The company explicitly said that service resumption did not mean its data-exposure investigation was complete. That distinction matters commercially: service continuity and incident liability follow different clocks.

The market price of backup is not the price of restoration

IDCF’s published launch price is a useful reminder of what buyers can count. A per-server fee and usage-based storage charge put a number on protected capacity. They do not put a number on a customer’s alternate compute, data-transfer time, network changes, identity recovery, application checks, staff coordination or the cost of a message or transaction that cannot be replayed.

The economic point is not that managed backup is mispriced. It can reduce the labour of building and maintaining a repository, and immutable retention can limit what a compromised production account can delete. But when a provider manages both the backup service and its normal entry point, the buyer must ask where the recovery authority resides. A second storage location is a data-plane feature; an independent credential path is an administrative feature; a tested alternative cloud is a capacity and portability feature. They may be sold together, but one does not prove the others.

A useful buyer test begins with the failure, not the product name. Disable the standard cloud portal in an exercise. Ask who can sign in, retrieve the backup catalogue, identify the latest usable point and approve a restore. Then restore one representative workload into a destination whose identity, billing and compute capacity do not depend on the unavailable console. Measure the time to a working application, not the time for a copy job to say “complete.” Record the data state and the work needed to update routes, addresses, access controls and customer-facing services.

That exercise would have to answer further questions that IDCF’s public materials do not settle: whether the customer owns or can export backup-catalogue metadata; which credentials can delete both the live workload and its backup; how support responds when the primary console is intentionally disabled; what restores to a different provider cost; and whether the copy’s geography is separated from the compute failure being tested. These are procurement questions, not allegations about the design.

Evidence, not inference

IDCF has published a fourth incident update describing coordination, investigation and assistance. Six Apart and Future Shop have published customer-specific actions. IDCF’s product pages disclose a backup service, its launch technology, a storage model and published prices. The public sources do not disclose IDCF Cloud Backup adoption among affected customers, whether its control plane stayed available, or whether a particular backup copy was used in the incident.

That absence limits the conclusion. IDCF’s BaaS has not been shown to fail, and the customer examples cannot be presented as its performance. What the event does establish is that a provider console, backup service, storage account and alternate compute destination can be separate operating dependencies. If a buyer pays for protection without testing the connections among them, the visible storage line can be more complete than the recovery plan.

Sources