IDCF Cloud Ransomware: Third-Party and Concentration Risk Lessons

On 7 October 2026, ransomware took down IDCF Cloud's East Japan Region 1, run by IDC Frontier, a SoftBank company. IDC Frontier says 495 companies and local governments were affected. If you rely on any cloud or hosting provider, list which business services run there, keep backups outside it, and prove you can restore them elsewhere.

This is not a vulnerability you can patch. It is a concentration story: hundreds of organisations sharing one region, one control plane and, for many, one copy of their data.

What happened

IDC Frontier has published six numbered notices on idcf.jp so far. The table below follows them, with outside reporting where it adds detail. Times are Japan Standard Time.

Two things stand out. First, the provider told affected customers on day two that recovery would depend on backups they held themselves. Second, the provider's own backup service and its snapshot feature were paused during the response, so customers who relied only on those tools waited.

What is still unknown or disputed

IDC Frontier has not said publicly how the attacker got in or who the attacker is. Rescana, citing Nikkei xTECH, reports that the company has identified the intrusion path but is withholding it for security reasons. We could not confirm that from IDC Frontier's own notices.

A message attributed to the attacker circulated in screenshots, first shared on X and reported by BleepingComputer and SDxCentral. It claims the whole region was encrypted in "exactly seven minutes", that about 239 hypervisors were reached, 225 datastores encrypted (3.6 PB), and 554,153 snapshots wiped. SDxCentral adds a claim of 41.5 PB of backup capacity removed. The reports differ on details: BleepingComputer gives about 16,000 VM disks, piyolog about 16,600, and Rescana calls the 225 items "databases" rather than datastores. None of these figures are confirmed by IDC Frontier. Treat them as attacker claims.

Customer data exposure is also moving. Several customers first disclosed that up to millions of email addresses might be exposed. According to a tracker kept by rocket-boys.co.jp, many of them later said no leak was found, including JR East (15 October, citing its contractor) and View Card (15 October). Initial counts were upper bounds, not confirmed leak totals.

Who is affected

IDC Frontier has not published a list of the 495 customers. The organisations below disclosed impact themselves or were named in the cited reporting.

MLex reported that at least one prefecture could not reach its backup data after the provider's systems went down. It did not name which.

Note the Shiga entry. According to rocket-boys, those prefectural sites went dark because a contractor ran them on IDCF Cloud. The prefecture was not necessarily an IDCF customer at all. This is fourth-party risk: your supplier's supplier.

How it works

We do not know the entry point, so this section stays at the level of what the public record supports.

Most public clouds run customer virtual machines on shared hypervisors, backed by shared storage, managed through a shared control plane. Zones and regions are meant to limit blast radius. In this case IDC Frontier says four of six zones in one region were hit while others were not, which suggests some separation held.

But several shared layers still mattered. The provider paused management consoles in all regions while checking them, so even unaffected customers briefly lost self-service control (IDC Frontier, 3rd report; BleepingComputer). The provider's backup service and snapshots were paused too. And if the attacker's claims about hypervisors and snapshots are accurate, the data and its in-platform copies sat in the same blast radius.

SDxCentral cites Google research that about 43% of ransomware intrusions Google responded to in 2025 targeted virtualisation infrastructure, up from 29% in 2024, with groups deleting snapshots and backups before encrypting. Whatever happened at IDCF, that pattern is why a snapshot inside the same platform is not a backup you can count on.

What to do now

Whether or not you use IDCF Cloud, these steps are worth doing this week.

1. If you are an IDCF Cloud customer, read the provider's notices directly. Start from the 6th report and work back. Check whether your workloads were in the four affected zones and whether you were among the snapshot users the 5th report says can retrieve data.

2. Rotate credentials tied to the provider. The 5th report says portal registration data for 48 customer companies was improperly queried, including login IDs and hashed passwords. Even if you were not one of the 48, change portal passwords and rotate any provider API keys. According to rocket-boys, one monitoring SaaS stopped IDCF-linked API keys as a precaution without being attacked itself.

3. Find out which of your services sit on which provider. DNS and IP ownership give a quick first pass:

   # Where does each public hostname point?
   dig +short CNAME app.example.com
   dig +short A app.example.com
   
   # Who owns that address?
   whois 203.0.113.10 | grep -iE 'netname|orgname|org-name|descr'
   
   # Who handles your mail and transactional email?
   dig +short MX example.com
   dig +short TXT example.com | grep -i spf
   

   The SPF record is often the fastest way to see every third party allowed to send mail as you, which matters here because several affected services were email delivery platforms.

4. Test a restore from a copy outside the provider. Not a backup job status, an actual restore into a different environment:

   # restic example: list, verify, then restore to a scratch location
   restic -r s3:s3.other-provider.example/backups snapshots
   restic -r s3:s3.other-provider.example/backups check --read-data-subset=5%
   restic -r s3:s3.other-provider.example/backups restore latest --target /srv/restore-test
   
   # PostgreSQL example: confirm a dump is readable before you need it
   pg_restore --list nightly.dump | head
   

   Write down how long it took and how old the restored data was. Those two numbers are your real recovery time and recovery point.

5. Check the age of your newest off-provider copy. piyolog reports that one affected retailer restored on another cloud using data from 30 August. That is a business decision worth making on purpose, not discovering during an outage.

6. Rebuild from source, not from the provider. Make sure your infrastructure code, container images and dependency manifests live outside the provider so you can stand the service up elsewhere. Generate a software bill of materials now so you know exactly what you would be rebuilding:

   safeguard scan --dir .
   safeguard scan --image registry.example.com/shop-api:2026.10
   ls ./output
   

7. Ask your critical suppliers one question. "Which hosting provider runs the service you provide to us, and where are your backups?" The Shiga example shows why.

What would have helped

None of this is a judgement on any named company. These are practices that reduce the damage when any shared provider has a serious incident.

Practices any team can use

A service to provider map. Keep a simple table: business service, owner, provider, region, where its data and backups live, and who to call. Include SaaS tools and contractors who host things for you. Several organisations here learned they were exposed only when a supplier's service stopped.

Your own backups, outside the blast radius. IDC Frontier's 3rd report told affected customers that restoration depended on backups they held themselves. According to piyolog and Impress Watch, Six Apart kept backups on a different cloud and moved its 31 servers to another provider within days. piyolog also reports that Mediwel kept separate backups outside IDCF. Provider snapshots are useful for convenience. They are not independent copies, and here they were paused along with the rest of the platform. Keep at least one copy in a different provider or on premises, ideally immutable or offline, under credentials the primary provider cannot touch.

Tested restores with timings. A backup you have never restored is a hope. Run a restore drill on a schedule, into a clean environment at a different provider, and record time to restore and data age. The rocket-boys tracker shows recoveries ranging from 9 October for some services to 20 October for others, with at least one restart date still undetermined on 19 October.

Regional failover that does not share a control plane. Multi-region within one provider helps with a data centre fire. It may not help when the provider pauses consoles across every region at once, as IDC Frontier did here as a precaution. For services where hours matter, keep a warm or cold standby at a second provider, with DNS you control and a short TTL so you can move traffic.

Contract terms that cover the bad day. Review cloud and hosting contracts for:

• incident notification timelines and the channel they use (customer contact was via SoftBank's corporate division in this case, per the 4th report),
• data return and export rights during an incident, not just at termination,
• whether provider backups are included, and whether they share infrastructure with production,
• disclosure of subcontractors and the hosting they use,
• exit support and the format your data comes back in.

Vendor reviews that ask about concentration. Annual questionnaires often ask whether a supplier has backups. Better questions: where are they, at which provider, when was the last restore test, and how long did it take? Ask the same of the contractors who run websites and email for you.

Where Safeguard fits

Safeguard does not stop a provider's ransomware. It does not back up your data, run your failover, or watch a cloud provider's hypervisors. If your workloads had been in the affected zones, Safeguard would not have kept them online. Here is what it can do in the parts of this problem it touches.

Third-Party Risk Manager. Safeguard's Third-Party Risk Manager (TPRM) is generally available. You onboard vendors, request SBOMs, projects or products from them, score and continuously monitor supplier risk, and apply policies and gates. That gives the service to provider map above a home alongside your other supplier records instead of a spreadsheet nobody updates. To be clear, that scoring is driven by the software and evidence vendors share with you. It would not have warned anyone that a hosting provider was about to be hit.

Compliance and vendor records. The compliance suite includes Vendors and Risks views, so the concentration risk you identify (for example "four customer facing services on one provider region") can be recorded as a risk with an owner and treatment, and the restore drills you run can be attached as evidence.

Knowing what you would rebuild. Rebuilding on a new provider is faster when you know exactly what is in each service. Safeguard generates SBOMs from repositories, container images and existing SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version, and matches components against vulnerability databases with reachability analysis. That inventory travels with you; it does not depend on the provider being up. For more on using SBOMs during an incident, see SBOM incident response: finding affected products fast.

Running checks from your own machine. If your usual environment is down, the Safeguard CLI and local runner work from a laptop, and safeguard exec runs in CI. That helps you scan rebuilt images before they go live at a new provider.

Common mistakes

• Treating provider snapshots as backups. In this incident the snapshot feature was suspended and, by the attacker's unverified claim, hundreds of thousands of snapshots were wiped.
• Assuming multi-region means independent. Regions can share consoles, identity and support channels.
• Mapping only direct vendors. Shiga's sites went down through a contractor's hosting.
• Counting a successful backup job as a successful restore. Only a timed restore proves recovery.
• Repeating the first exposure numbers. Many early counts were later revised to "no leak found". Quote the latest statement and say when it was made.

FAQ

What happened to IDCF Cloud?

IDC Frontier says a third party's ransomware attack disrupted IDCF Cloud East Japan Region 1 from about 03:40 JST on 7 October 2026. It isolated and shut down the region. Four zones were damaged, and the provider says 495 companies and local governments were affected.

Was customer data stolen?

IDC Frontier's 5th report (14 October) says it found no evidence that customer virtual server data in the affected zones was viewed or taken out, and judges there was no external leak. Separately, portal registration data for 48 customer companies was improperly queried. Several customers first warned of possible email address exposure; many later said no leak was found.

Can affected customers get their data back?

The 3rd report said data in the four zones would be very hard to retrieve and that restoration depended on customers' own backups. The 5th report later said backups for 194 customers who used snapshots could be retrieved, with delivery being arranged individually. The 6th report (18 October) resumed the backup service; snapshots remained suspended.

Who was behind the attack and how did they get in?

Not disclosed by IDC Frontier at the time of writing. Rescana, citing Nikkei xTECH, says the company has identified the intrusion path but will not reveal it. No group has been named in the reporting we checked.

We are not in Japan. Why does this matter to us?

Any team on a shared provider carries the same shape of risk, and the same lessons apply to every cloud and hosting company.

Is multi-region on one provider enough?

It helps with local failures. Here, the provider paused management consoles in every region as a precaution and suspended its backup tools, so customers in unaffected regions still lost some control for a time. For critical services, consider a standby at a second provider.

Would Safeguard have prevented this?

No. Safeguard does not protect a cloud provider's infrastructure. It can help you keep a current vendor register, record concentration risk, and know exactly what software you would rebuild elsewhere.

Try it yourself

See how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use, for example to query your vendor and project records.

Click through it at your own pace, or open it full screen.

If your usual environment is down, you can still scan from your own machine. This demo sets up the runner locally, approves it with its device code, then scans from the terminal.

Click through it at your own pace, or open it full screen.

To try the CLI on your own repositories, download Safeguard and follow the CLI docs. For other incidents this month, see October 2026 security incidents and what would have helped and our incident response playbook for a compromised dependency.

Quick check

Sources

• IDC Frontier: 2nd report on unauthorised access (7 Oct 2026, Japanese)
• IDC Frontier: 3rd report on the outage (8 Oct 2026, Japanese)
• IDC Frontier: 4th report on response structure (9 Oct 2026, Japanese)
• IDC Frontier: 5th report on investigation progress (14 Oct 2026, Japanese)
• IDC Frontier: 6th report on resuming the backup service (18 Oct 2026, Japanese)
• Impress Watch: IDCF Cloud outage caused by ransomware, 495 organisations affected (Japanese)
• piyolog: summary of the IDCF Cloud ransomware attack (Japanese)
• rocket-boys.co.jp Security Measures Lab: affected services and recovery tracker (Japanese)
• BleepingComputer: Ransomware attack disrupts Japan's IDCF Cloud used by govt clients
• SDxCentral: SoftBank cloud arm attacked in seven minutes
• Rescana: IDCF Cloud ransomware hits 495 Japanese companies and local governments
• MLex: Japan cloud ransomware attack exposes municipal backup vulnerabilities

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.