What the company confirmed. Per IDC Frontier’s Oct 7 and Oct 8 incident notices, the outage started about 3:40 a.m. JST Wednesday in IDCF Cloud East Japan Region 1, specifically the tesla, henry, pascal, and joule zones. Observed impact: virtual servers stopped and could not be restarted. Cause stated by the company: unauthorized access via ransomware. Contracted customers hit: 495 companies and local governments, contacted individually. IDCF Cloud TypeS (formerly White Cloud ASPIRE) and IDCF Private Cloud are out of scope for this incident, per the Oct 8 notice.
Recovery posture, not just downtime. After cutting the region off the network and stopping systems on Oct 7 to limit secondary damage and data leakage, the Oct 8 “3rd report” is the harder line: for those four zones, IDC Frontier’s current view is that retrieving or restoring customer data from company-held storage looks difficult, and restores should run from backups customers already keep. Unaffected zones and other regions (including East Japan Region 1’s radian and newton zones, East Japan Regions 2 and 3, and West Japan Region 1) show no confirmed unauthorized access so far, but external management consoles stay paused while safety checks continue; the company is manually starting and stopping VMs for customers while consoles are down. Supervisory authorities and the Tokyo Metropolitan Police have been notified.
What remains unverified. Screenshots circulating as a threat-actor message claim a seven-minute breach, encrypted databases, sealed VM disks, wiped snapshots, and multi-petabyte impact. Mainichi/Kyodo quote an IDC Frontier official saying the firm is aware of such a statement and is checking authenticity. Treat those actor numbers as Unverified until the company or police corroborate them. Exact intrusion path: still under investigation with an external security firm. Whether personal data left the environment: not stated as confirmed in the Oct 8 notice. Nissui Logistics and some Ibaraki prefectural sites were reported separately as disrupted in secondary coverage; a firm company link for every named secondary victim is not in the IDC Frontier release.
Why enterprise buyers care tonight. This is a SoftBank-group IaaS hit that took down hundreds of corporate and municipal tenants in one region and told them the provider may not be able to rebuild their disks. If you run production on a single region without customer-controlled, offline-tested backups, or if your DR assumes the cloud console will always be available for failover, this is the failure mode to table with your CISO before the next board pack. Ask vendors for region isolation guarantees, backup ownership (who holds the last good copy), and console lockout playbooks. SoftBank Corp ownership does not change the ops question: when the hyperscale-adjacent provider says restore from your own backups, the RTO is yours.
Desk sheet: IDC Frontier (SoftBank Corp subsidiary) IDCF Cloud ransomware · start ~3:40 a.m. JST Oct 7, 2026 · East Japan Region 1 zones tesla/henry/pascal/joule · 495 companies and municipalities · VMs stopped / no restart · Oct 8: customer data in those zones may only restore from customer backups · consoles paused elsewhere for safety · TypeS and Private Cloud out of scope · actor petabyte claims Unverified · sources: idcf.jp notices Oct 7–8, Mainichi/Kyodo, BleepingComputer.