Japan asks for security. Nobody has to do it.

Part 15 of a series on Japan’s cybersecurity blind spot. Start with the overview, Japan cyberattacks in 2026: what the breach wave reveals, or read the previous part, The front door held. They came in through the vendor’s back office..

Update, 22 October: Since publication, a counterexample worth adding: Japan’s big banks are dropping photo-based ID checks ahead of a legal deadline. The update is at the end of “What a requirement would look like.”

TL;DR: When Japan’s government wants better security, it usually asks. It doesn’t require. On 21 October the Prime Minister asked website operators to get ready for an emergency PHP patch, about an hour before it came out. In 2023, three ministries asked credit-card companies to block forged email, and today about 5.7% of Japanese company domains that receive mail do it. In 2018, METI warned that legacy systems would push Japan off a “2025 digital cliff,” and two years later found that 95% of the companies it measured had barely started. Japanese law says this kind of request works only through voluntary cooperation, and nobody can be penalized for ignoring it. The organizations that were already able to act, did. Most weren’t, and a request can’t fix that.

Three requests

This autumn I’ve written about one breach after another, and one pattern keeps coming back. The government saw the problem, said so in public, and asked people to fix it. Then most of them didn’t, and when the attack came, the request turned out to be the whole of the plan.

Three cases show it on three different timescales: hours, years, and nearly a decade. They involve different ministries and different technology. What they share is the instrument. Each was a request, and each ran into the same problem: the people it reached weren’t the people who could carry it out.

Hours: the PHP patch

At about 10 p.m. on 21 October, Prime Minister Sanae Takaichi posted on X what she called “an urgent request I need you all to act on tonight.” PHP, the programming language behind about seven in ten websites whose server technology can be identified, was due to release fixes for two critical flaws at 11 p.m. Japan time. She asked operators to be ready to apply them “as quickly as possible” and, if they couldn’t, to consider taking their websites offline for a while. Kyodo and Mainichi reported the post that night, and Nippon TV put it at around 10 p.m.

She wasn’t the first to warn. IPA, the Information-technology Promotion Agency, the government’s IT and security body, had published a notice that day asking operators to prepare, and the National Cybersecurity Office had posted its own. But the details of the flaws had already leaked, and before the release Cloudflare’s CTO said the company was already seeing early attacks. For anyone who hadn’t prepared before that evening, there was nothing left to prepare.

Nippon TV’s news zero, 21 October, in Japanese, on company and local-government sites going into emergency maintenance after the Prime Minister’s post. Video: 【ネット混乱】企業や自治体などサイトが続々｢緊急メンテナンス｣ “PHPに関し重大な2件の脆弱性に注意喚起” 高市首相が呼びかけ いったい何が？【専門家解説】 from 日テレNEWS.

The deeper problem is older than that night. In Part 13 I checked the homepages of Tokyo Stock Exchange companies listed in Wikidata. Of the 1,732 that answered, 167 announce their exact PHP version, and 99 of those run a version PHP no longer patches, 30 of them still on PHP 5, which last received a fix at the end of 2018. For those sites, the Prime Minister’s request could not be met on any timescale shorter than a major upgrade. And this was not the first warning: in July 2024 IPA reported that a previous PHP flaw had been used against multiple Japanese organizations within a month of its disclosure.

Years: forged email

Phishing emails work because they look like they come from a real company. The defense is a set of public settings, SPF, DKIM, and DMARC, that let a company tell the world’s mail servers which messages genuinely come from its domain, and what to do with the rest. DMARC only protects anyone once the company sets it to “quarantine” or “reject.” Left at “none,” it watches and reports, and the forged mail still arrives. I explained the details in Part 4.

On 1 February 2023, MIC, the Ministry of Internal Affairs and Communications, the National Police Agency, and METI, the Ministry of Economy, Trade and Industry, jointly asked credit-card companies to deploy DMARC on every domain they show to customers, including domains that never send mail, and to run it with a policy that has receivers reject forged messages. The reason was plain: card-company phishing was driving card fraud. In 2025, the Council of Anti-Phishing Japan received a record 2,454,297 phishing reports, and credit-card and consumer-credit companies were again the category with the most brands impersonated.

MIC also publishes the national picture. In its table as of the end of June 2026, 26,684 of the 471,376 .co.jp company domains that receive mail enforce DMARC with quarantine or reject, about 5.7%. For local governments’ .lg.jp domains, it is 18 of 1,285, about 1.4%. For the central government’s own .go.jp domains, it is 94 of 566, about 16.6%. The government asked card companies to do something that more than four in five of its own mail domains still don’t do.

It is worth seeing what the alternative looks like. In October 2017, the US Department of Homeland Security issued Binding Operational Directive 18-01, a compulsory order to federal civilian agencies: DMARC set to reject on every domain within one year. It covered only federal agencies, and it didn’t get everyone there. On the deadline, Proofpoint, an email-security company, counted 62% of agency domains as compliant, up from about 15% nine months earlier. But it had a deadline, a measurement, and someone accountable for the gap. Japan’s request to card companies had none of those.

Nearly a decade: the 2025 digital cliff

In September 2018, a study group at METI published the DX Report, the document that gave Japan the phrase “the 2025 digital cliff.” It warned that if companies didn’t replace their aging, opaque systems, the losses could reach up to about ¥12 trillion a year from 2025. It called those systems technical debt, and it said the cause was management, not old technology. Part 12 covered what that debt looked like when it came due on 17 October.

The report was advice. It named a date, but nobody was required to do anything, and the self-assessment METI added later was voluntary too. In December 2020 METI checked on progress, and published the result as DX Report 2. Among the companies that had voluntarily completed its self-assessment, presumably the more motivated ones, 95% had either not started at all or had only just begun. Given how many companies hadn’t even done the self-assessment, METI wrote, Japan’s overall effort was at “a totally inadequate level” (全く不十分なレベル).

Then it said the most honest thing in the whole story. The message of the original report, METI wrote, “was not correctly conveyed” (正しく伝わっておらず). Companies had read it as “DX means replacing legacy systems,” or decided that if they were competitive today, they needed nothing more. A ministry measured its own request, found it had failed, and said so. The cliff date then came and went.

Why requests stall

Japan has a legal name for this kind of instrument. A request from a ministry to a company is usually administrative guidance, 行政指導, and the Administrative Procedure Act is explicit about its limits. Article 32 says officials must remember that guidance “is realized only through the voluntary cooperation of the other party,” and that they may not treat anyone unfavorably for not following it. A request is, by law, something you can decline.

That would matter less if the people receiving the request could carry it out. Usually they can’t, and this is the thread that runs through this whole series. The request goes to management. The PHP version is chosen by a hosting company or a web agency. The DMARC record sits in a DNS account that a vendor set up years ago. The legacy system is understood by an engineer who retired. Part 5 put it as: you outsourced the work, not the responsibility. A request from Kasumigaseki lands on the responsibility, and the work is somewhere else.

The government’s own record makes this harder to fix. A ministry can’t credibly push companies to enforce DMARC while most of its own domains don’t. And nobody publishes who acted. There is no list of card companies that met the 2023 request, and no follow-up from the ministries that made it. Without a deadline or a measurement, a request costs nothing to ignore, and ignoring it is the easy choice for an owner who doesn’t know what they run.

What requests do achieve

To be fair to the people making them, requests aren’t worthless. From the evening of 21 October, banks, brokerages, and game companies took web services offline as a precaution, and the Ministry of Health, Labour and Welfare and the Ministry of Finance suspended parts of their own sites. Chief Cabinet Secretary Minoru Kihara said the government had received no reports of related damage so far. Those organizations knew they ran PHP, had someone on call, and could act within an hour. The request gave them cover to do something costly.

That is exactly the limit. A request moves the organizations that already know their own systems and already have someone who can act. It does nothing for the ones that don’t, and those are the ones attackers find first. Switching a site off for a night is visible action, as Part 8 argued, and it can be the right call, but it isn’t the patch. For the 99 listed-company sites on unsupported PHP, there was no patch to apply when the site came back on.

What a requirement would look like

This part is my view, not a finding. A requirement doesn’t have to be a new law. It needs four things the requests above lacked: a deadline, a public measurement, a named owner, and a consequence. The government could start with its own house: put every .go.jp domain at an enforcing DMARC policy by a fixed date and publish the count each month. It could write supported software and enforced email authentication into procurement contracts, so vendors that run government systems have to meet them. And when it asks an industry for something, it could publish who has done it a year later.

Update, 22 October: Japan already has a case that shows the difference. Under a revised ordinance to the Act on Prevention of Transfer of Criminal Proceeds, from 1 April 2027 banks and other regulated businesses may no longer verify customers online by having them photograph a driver’s licence. They must read the IC chip in a My Number card or other chip-embedded ID instead. On 9 October the Financial Services Agency told financial institutions to make that switch “as quickly as possible” without waiting for the deadline, citing breaches that had exposed customers’ licence images.

The big banks are moving early. Sumitomo Mitsui Trust Bank dropped photo checks in March and MUFG Bank in May. Mizuho Bank switched on 19 October, citing the Times Car breach that exposed licence images of more than a million users, and Sumitomo Mitsui Banking plans to follow, Jiji reports (Japan Times in English). Here the request sits on top of a requirement with a date, and the banks are beating the date. This covers new online account opening only. It says nothing about the licence images banks already hold.

What it means for your company

You don’t need to wait for any of that. Every item in these three requests can be checked from the outside, today, by anyone: which PHP version your sites announce, whether your domains enforce DMARC, and whether anything you run is past its end of life. The harder question is the one behind all three: who, by name, is responsible for doing the work when the next request arrives at 10 p.m., and do they have the access to do it?

If you don’t know, start there. The Domain Exposure Report reads the public signals for one domain, including email authentication and visible software versions, for ¥5,000 + tax, without testing your systems. For the harder map, which systems you depend on, who runs them, and who can change them, that’s what Diagnostics is for.

The next part, GMO’s own hackers saw it coming. The fix wasn’t fast enough., follows a cloud breach where the warning came from inside the company.

Why do Japanese government cybersecurity requests fail to change behaviour?

Japanese government security requests fail because they are administrative guidance, which Article 32 of the Administrative Procedure Act says works only through voluntary cooperation and carries no penalty for ignoring it, and because they reach management while the work sits with a vendor. Three cases show the pattern. The Prime Minister’s October 2026 request to prepare for an emergency PHP patch came about an hour before release, and 99 of 167 listed-company sites that announce a PHP version run one PHP no longer fixes. A 2023 request from three ministries for card companies to enforce DMARC left Japan at about 5.7% of mail-receiving .co.jp domains enforcing it by June 2026, and 16.6% of the government’s own .go.jp domains. METI’s 2018 warning about a 2025 digital cliff was followed in 2020 by its own finding that 95% of self-assessed companies had barely started. A requirement needs what these lacked: a deadline, a public measurement, a named owner and a consequence.

Sources as of 13:00 JST, 22 October 2026.