Japan's October 2026 breaches: a CISO briefing

In October 2026, organisations in Japan published 1,164 notices of cyberattacks, and most of them were not about a breach of their own systems. 1,013 notices (87%) came from customers of 42 suppliers that had been breached, and five of those suppliers produced 882 notices (76%) on their own. Three of the five are bulk-mail platforms. Local governments notified more than any other sector, almost entirely because of suppliers. Where the breached organisation said how the attacker got in, the commonest answers were a flaw in an internet-facing system, a misused account, abuse of an app or API, and ransomware. But 100 of the 176 distinct breaches (57%) did not say. This briefing is written for a CISO who has to explain October to a board. It covers what was affected, which industries notified and why, how the attacks worked, six patterns, how our count compares with others, and the decisions and measures we would put to a board. It contains no detection queries.

What is affected, and what is not

Status across the 1,164 notices of attacks published from 1 to 31 October 2026, as of 9 November. "Notices" are published statements; one breach can produce hundreds of them.

Item	Status	What is known
Local governments and public bodies	Affected, almost entirely through suppliers	521 notices, the most of any sector. 518 were caused by a supplier, such as a disaster-alert mail service, newsletter platforms and hometown-tax donor mail. Only 3 were about their own systems.
Customer contact data	Affected (the most common data)	Of the 792 notices that list the data, 668 include email addresses (84%), 499 names, 422 phone numbers and 275 postal addresses.
Data used in identity checks	Affected in 109 notices	Date of birth together with a name and a phone number or email address, the combination used to prove identity by phone or online.
Passwords	In scope in a minority	129 notices state a password status: 86 say no passwords were involved, 18 hashed, 12 storage not stated and 13 not yet confirmed.
Card data	Rarely in scope	20 notices mention a card-related item, such as expiry dates or last digits; 3 list a card number.
Service	Disrupted for many	205 of the 267 notices that do not say personal data was at risk report a service stopping, mostly customers of Blastmail, Medley's @link clinic booking, IDC Frontier and Arcadia.
The way in	Not disclosed for 57% of breaches	100 of 176 distinct breaches named no route.
One shared flaw behind it all	Not the case, per JPCERT/CC	JPCERT/CC says the attacks did not exploit one common flaw: each target was scanned for many known weaknesses.

The briefing in six lines

October was a step change, not noise. Notices rose from 22 in the first four days to 457 in the week of 12 October. Critical-infrastructure operators reported 15 cyberattacks to the National Cybersecurity Office (NCO) in October, against one or two a month since April. Tokyo Shoko Research counted 109 incidents at listed companies, against 10 to 19 a month before.
Your breach count is set by your suppliers. 87% of notices came from a supplier's breach. The five largest supplier breaches, three of them bulk-mail platforms, produced 76% of all notices.
The supplier's supplier matters. 78 local governments notified because Satofull, the hometown-tax portal, kept donor data on Yumil Link's Cuenote FC mail service, which was breached.
The routes are basic. Flaws in internet-facing systems, misused accounts and abused apps and APIs. The NCO's assessment is that basic measures were missing, in-house or at contractors, and that attackers surveyed Japanese sites at scale, probably with AI.
Disclosure is fast and incomplete. The median time from discovery to notice was 2 days, and first numbers moved later. 57% of breaches never named a route.
The board's leverage is in contracts and data. Know which suppliers hold your lists or send in your name, make them tell you quickly and name the way in, and stop them holding data you no longer need.

Figure 1. The month on one slide, sized 16:9 for a board or executive deck. Select it to open the full-resolution image. Original graphic from our October 2026 dataset.

October in numbers

Figure 2. Original graphic from our October 2026 dataset. Each bracket is one supplier breach reaching its customers; the table below gives the weekly totals.

Week	Notices	Because of a supplier	About its own systems
1–4 Oct	22	5	17
5–11 Oct	92	62	30
12–18 Oct	457	432	25
19–25 Oct	364	324	40
26–31 Oct	229	190	39
October	1,164	1,013	151

The busiest day was 14 October, with 184 notices, 154 of them from municipalities about Arcadia's disaster-alert mail service. Notices about organisations' own systems were steadier: 17 to 40 a week. The surge was a supplier surge.

Two counts that do not use our data show the same break. The government's emergency package of 6 November charts incident reports from critical-infrastructure operators to the NCO: one or two cyberattacks a month from April to September, and 15 in October. It also says reports to the Personal Information Protection Commission (PPC) rose sharply in October, without giving a number (Cabinet Secretariat). Tokyo Shoko Research (TSR) counted 109 leak and loss incidents at listed companies and their subsidiaries in October, against 10 to 19 a month before, and 215 for January to October. That already beats its previous annual record of 189 in 2024 (TSR).

Where the breaches came from: suppliers

Figure 3. Original graphic from our October 2026 dataset. A supplier's own notice is counted with its customers'.

October's notices came from 176 distinct breaches. 42 were at a supplier or platform whose customers also notified; 134 were at the notifying organisation itself. The 42 supplier breaches produced 1,030 notices, including the suppliers' own; the 134 produced one each.

Five breaches, 76% of notices. Arcadia's SpeeCAN RAIDEN, a service that sends disaster and safety alerts for local governments, produced 351 notices (Arcadia). Rakus Lite Cloud's Blastmail produced 280 (Rakus), Yumil Link's Cuenote FC 111 (Yumil Link), Studio 98 (Studio) and IDC Frontier 42.
Mail platforms above all. Arcadia, Blastmail, Cuenote FC, Arara and two unnamed mail contractors account for 754 notices, nearly two in three. Our analysis of the mail-delivery platform breaches and the follow-ups on Arara and Blastmail cover them in detail.
Customers publish together. All 350 customer notices about Arcadia came between 13 and 20 October, 154 of them on 14 October alone. 87 of Studio's 97 customer notices came between 16 and 20 October, around its own notice of 16 October. A supplier breach reaches the board as a wave of peer notices, not one event.

Figure 4. Original graphic from our October 2026 dataset. Band width is the number of notices.

Figure 4 follows each breach to the sectors that had to notify. Arcadia's notices went almost entirely to local government, Medley's to clinics and Sourcenext's to cable-TV and internet providers. Blastmail's reached every sector and Studio's all but one: a general-purpose platform's breach becomes every industry's problem at once.

Industries: who had to notify, and why

Figure 5. Original graphic from our October 2026 dataset. "Own" counts notices about the organisation's own systems, including platforms whose customers also notified.

Two views give different answers. By notices, the public sector dominates, because suppliers notify on its behalf many times over. By breaches of the organisation's own systems, the picture is consumer-facing business: retail and consumer services had 37 such breaches, IT and online services 30, media 14, manufacturing 12 and transport and travel 12.

Sector	Notices (own systems)	Own-system breaches, by stated route	What drove the notices
Local government and public bodies	521 (3)	3, none stated	Arcadia's alert mail (349), Satofull donor mail via Cuenote FC (78), Blastmail (52), Studio-built sites (19)
IT, software and online services	158 (41)	30: 10 flaw, 7 account, 3 app or API, 10 not stated	Platforms breached in their own right (Studio, Commune, Cuenote FC, Arara and others) and their tech customers, such as 48 Studio users
Media, entertainment and sport	81 (15)	14: 5 account, 1 ransomware, 8 not stated	Newsletters on Blastmail and Cuenote FC; staff and development accounts at the Nikkei group
Retail, food service and consumer services	83 (38)	37: 7 flaw, 3 app or API, 2 account, 25 not stated	Member apps and online shops, including MUJI's app (27.26 million), Burger King Japan (11.18 million) and Yakiniku King (10.79 million)
Manufacturing and consumer brands	47 (12)	12: 2 ransomware, 2 account, 1 flaw, 1 app or API, 6 not stated	Community sites on Commune (11) and brand newsletters
Healthcare and pharma	46 (5)	4: 1 ransomware, 1 account, 2 not stated	27 clinics using Medley's @link booking app, most reporting an outage rather than a leak
Finance and insurance	33 (7)	5: 1 app or API, 4 not stated	Supplier platforms: digital-bond platforms run by NTT Data's STdirect and Securitize Japan, an FAQ system from Scala, a trading system from TradeWorks
Transport and travel	34 (12)	12: 2 app or API, 1 flaw, 1 account, 8 not stated	Booking systems, including skyticket (14.64 million through one route) and Club Tourism (4.32 million); JR group member services on IDC Frontier's cloud
Telecoms, ISPs and cable TV	31 (5)	4: 1 app or API, 3 not stated	17 cable-TV and internet providers that resold Sourcenext's smartphone security app

Sectors are coded from each organisation's name; see "How we counted". Figures in millions are each company's own count of records or members.

What this means by sector. In the public sector, health and telecoms, the risk sits in procurement: the breaches that produced their notices were at suppliers they chose. In retail, IT, media and transport, organisations' own apps and member systems were entered too, and most did not say how, which leaves their peers unable to learn from them.

Figure 6. Original graphic from our October 2026 dataset. Brighter cells hold more breaches; a dash means none.

Figure 6 crosses sector with route for the 134 own-system breaches. Retail alone accounts for 25 of the 76 that gave no route. IT and online services is the one sector where named routes outnumber silence: 10 flaws and 7 misused accounts against 10 undisclosed. Media's cases lean to accounts (5 of 14), and ransomware is spread thinly across manufacturing, media, education and healthcare.

How they got in: tactics and techniques

Figure 7. Original graphic from our October 2026 dataset. Each breach is counted once, with the route its own or its customers' notices give.

Of the 76 breaches that named a route, 32 (42%) were flaws in internet-facing systems, 22 (29%) misused accounts, 13 (17%) abuse of an app or API and 9 (12%) ransomware. Responders describe the same techniques across cases without naming victims: JPCERT/CC's alert sets out five case types (JPCERT/CC), its analysts found attack servers holding app-analysis tools (JPCERT/CC Eyes), and NICT named "A2B" (app-to-backend) attacks (NICT).

Stage	ATT&CK	What October shows	Evidence
Survey targets at scale	T1595.002 Vulnerability Scanning	Each target scanned for many known flaws and for configuration and backup files left reachable (Case A)	JPCERT/CC; the NCO's 5 November guidance
Bring tools, including AI	T1588.002 Tool	AI penetration-testing platforms such as Cairn, CyberStrikeAI and ARTEX in attack attempts (Case E); APK and Flutter analysis tools on attack servers	JPCERT/CC alert and blog
Pull keys out of public apps	T1552.001 Credentials In Files	API endpoints and keys taken from analysed smartphone apps (Case B)	JPCERT/CC; NICT
Exploit an internet-facing system	T1190 Exploit Public-Facing Application	32 breaches, including Studio, Commune, Cuenote FC and Arara; Metabase SQL injection (Case C)	Breached organisations' notices
Log in with someone else's account	T1078 Valid Accounts, T1078.004 Cloud Accounts	22 breaches: staff mail and Microsoft 365 accounts, admin logins, a second cloud at Arara	Breached organisations' notices
Keep a foothold	T1505.003 Web Shell	WAR files with JSP web shells on application servers reachable from the public web server (Case D)	JPCERT/CC
Hide where requests come from	T1090.003 Multi-hop Proxy	Tor exit nodes and residential proxies to get round address limits; the real app's User-Agent	JPCERT/CC
Collect at volume	T1119 Automated Collection	APIs called to pull member records, such as Sourcenext's member API (22,519,960 records)	Sourcenext
Encrypt or stop systems	T1486 Data Encrypted for Impact	9 ransomware breaches, including IDC Frontier's cloud, which took down services for its customers	Breached organisations' notices
Turn the platform on its users	T1584 Compromise Infrastructure, T1566 Phishing	Arcadia's system sent 1,423,428 phishing emails on 13 October; up to about 7.13 million lures went out through Arara	Arcadia and Arara notices, via our mail-platform analysis
Exploit the data next	T1656 Impersonation	A risk rather than a report: contact names, billing emails and payment histories suit invoice fraud	Our reading of the notices

There is no ATT&CK technique for "a supplier holding my data was breached". From the customer's side, a supplier breach is a third-party failure; the techniques above describe what happened inside the supplier.

Six patterns a board should know

1. One supplier breach, hundreds of notices

What happened. The five largest supplier breaches produced 76% of the month's notices. Arcadia's alert-mail service alone produced 351, from municipalities that had handed it residents' contact details.

Why it matters. For most organisations, the next notice will not start in their own network. A board that tracks only internal incidents is watching a quarter of the risk.

What breaks it. A supplier register ranked by the data each supplier holds and how many people it reaches, not by spend. The NCO's 9 October alert asks firms to manage contractors "together with them", including their subcontractors (NCO).

2. The supplier's supplier

What happened. 78 local governments published notices because Satofull, which runs a hometown-tax donation portal, used Yumil Link's Cuenote FC for some email, and Cuenote FC was breached (Satofull, Seto City). The municipalities' supplier was Satofull; the breach was at Satofull's supplier. Digital bonds show the same shape. On 31 October six issuers and brokers, among them Kagome, JR West and Nomura Securities, told bond buyers that their data had leaked from a contractor's system behind NTT Data's bond-perk service (Kagome, JR West, Nomura).

Figure 8. Original graphic from the notices of Satofull, Seto City, the six issuers and brokers, Sourcenext and BTV. Red marks the breached organisation and amber the ones that had to publish.

Why it matters. Fourth parties are invisible in most registers. The PPC's revised warning lists breaches at cloud services and weak supervision of group companies among nine typical cases (PPC).

What breaks it. Contracts that require a current list of sub-processors holding your data, and that pass breach-notice duties down the chain.

3. Mail platforms hold the list and the megaphone

What happened. Mail platforms produced 754 notices, nearly two in three. Three of them, Arcadia, Arara and Cuenote FC, were also used to send phishing or spam to people on the lists or in their name.

Why it matters. A mail platform holds the recipient list and the sending reputation of every customer. When it is breached, the attacker can reach those recipients from infrastructure they already trust.

What breaks it. Purge recipient lists after each campaign, authenticate your sending domains so that a platform you have left cannot send as you, and have a "we did not send this" notice ready.

4. Apps and APIs read like a database

What happened. 13 breaches named app or API abuse, including Sourcenext's member API and skyticket (our analysis). JPCERT/CC describes attackers taking endpoints and keys out of public apps, calling internal APIs the app never uses, and changing user privileges. NICT calls this A2B.

Why it matters. None of this needs malware. The API answers as designed, to the wrong caller, so security tools see normal traffic.

What breaks it. An inventory of every API, including unpublished ones, an authorisation check on every object, and rate limits on login, reset and search. The PPC lists exactly these steps for its API case, and the NCO's 5 November guidance repeats them (NCO). Our API leak guide sets out how to test for it.

5. Known flaws, found at machine speed

What happened. 32 breaches named a flaw in an internet-facing system. JPCERT/CC says the campaign scanned each target for many known weaknesses rather than one, and from 23 October it named AI penetration-testing platforms in attack attempts. The NCO says attackers surveyed Japanese websites at scale and probably used AI, so that weaknesses once rated low were combined into a way in. A new flaw then arrived: PHP2Shell, listed as exploited by CISA on 26 October and chained with a Linux privilege escalation against a firewall product by 29 October (JPCERT/CC, IPA).

Why it matters. Patch cycles measured in weeks lose to a survey measured in hours. IPA adds that PHP also runs in the web interfaces of VPN devices and security appliances.

What breaks it. Know what you expose, take off the internet what nobody needs, and fix known-exploited flaws on exposed systems within days. Our notes on AI attack platforms and PHP2Shell give the detail.

6. Accounts and ransomware: the old routes still work

What happened. 22 breaches came through misused accounts, from staff mailboxes to development clouds, such as the Nikkei group's (our analysis). Nine were ransomware, including IDC Frontier's cloud, which stopped services for its customers (our analysis).

Why it matters. Shared infrastructure turns one ransomware case into dozens of outages, and one stolen password into a supplier breach.

What breaks it. Phishing-resistant MFA for staff, administrators and contractors' remote access. The PPC now includes it in its preview of revised safeguards. Add tested restores for anything a customer depends on.

What the data was, and what it enables

Figure 9. Original graphic from our October 2026 dataset; data items as each notice lists them.

Contact data dominated: of the 792 notices that list the data, 84% include email addresses. That makes the first harm phishing in the breached organisation's name. 109 notices pair date of birth with a name and a phone number or email address. Once leaked, that combination stops proving identity, which is why the FSA asked financial institutions on 9 October to move to IC-chip checks of identity documents. The government's 6 November package widens the use of My Number Card chip checks in place of image-based checks.

Card numbers appear in only 3 notices, and 18 notices say hashed passwords were in scope. For most of October's victims, the cost is fraud and phishing against their customers, plus the outage, rather than direct card fraud.

Speed: two days from discovery to notice

Figure 10. Original graphic from our October 2026 dataset; dates as each notice gives them.

For the 225 notices that give both a discovery date and a notice date, the median gap was 2 days and three quarters were within 4. For notices about an organisation's own systems (100 with both dates), the median was 2.5 days. The PPC expects a preliminary report within roughly 3 to 5 days of learning of a reportable breach, and a final report within 30 days, or 60 when the breach may have been done with improper intent (PPC guidelines).

Fast notices are first scopings. Arara's count rose from about 77 million to 81,329,467 addresses, and Blastmail's affected contracts from 345 to 421. Where notices gave both dates, the attacker's first access was found a median of one day later (37 breaches; the longest gap was 25 days). Those are the breaches found quickly; TSR notes a case in which an information and communications group took more than two months to notice.

For the board: expect a second, larger number, and do not let the first notice close the incident.

How the government responded

Figure 11. Original graphic built from the documents listed under "Sources and updates". Dates are publication dates.

The response moved in three steps. First, regulators told firms what to fix: the PPC on 7 October, then the NCO, ministries, FSA and IPA together on 9 October. Second, responders described the attacks: JPCERT/CC's cases A to E, NICT's A2B, and JPCERT/CC's look inside attack servers. Third, on 6 November the government adopted an emergency package (Cabinet Secretariat). For a board, its items set expectations:

Revised PPC safeguard guidelines, with deletion of data no longer needed, aiming to take effect in January 2027.
AI-assisted vulnerability testing of government systems brought forward, a request to local governments to do the same, and a "top gun" team at IPA to promote penetration testing, including at private firms.
Reporting and evidence. Ministries are to collect information quickly from victims of serious incidents, firms are asked to report to the police and hand over logs, and a police unit is planned to secure logs early.
Threat hunting. Manuals and detection tools for firms, targeted by the end of the year.
Help for victims, through help desks for firms and the consumer hotline 188 for individuals.

How our count compares

Count	Scope	October	What it shows
Our dataset	Every notice we found: companies, public bodies, non-profits	1,164 notices from 176 breaches	Where notices came from and why
Tokyo Shoko Research	Listed companies and their subsidiaries only	109 incidents (preliminary); 215 for January to October	A record year by early November; 10 incidents of 10 million records or more in 2026, 6 of them in October
NCO	Incident reports from critical-infrastructure operators	15 cyberattacks, against 1–2 a month from April to September	The same step change in a regulated population

The counts measure different things and should not be added or compared directly. They agree on the shape: October broke the pattern of the previous months. TSR's own totals, 349,998,482 records for January to October against 30,636,910 for all of 2025, add up each company's own figures, some of which include duplicates, as TSR notes for SG Holdings.

The attacker's playbook

How October looks from the attacker's side. This is our reading of the evidence above.

Figure 12. Original graphic from JPCERT/CC's alerts and blog, NICT, the NCO's 5 November guidance, Arcadia's notice and our dataset.

Survey everything Japanese and internet-facing. Scan at scale for known flaws, exposed admin screens, configuration and backup files, with AI tools speeding the search (T1595.002, T1588.002).
Prefer the shared platform. One way into a mail or form platform yields every customer's data. One way into Arcadia's alert-mail service led to 351 notices.
Read rather than break. Use the platform's own APIs and export functions, with keys taken from public apps, so that traffic looks legitimate (T1552.001, T1119).
Hide in residential addresses. Rotate through Tor and residential proxies, and send the real app's User-Agent (T1090.003).
Monetise twice. Take the data, then send phishing from the platform's trusted sending infrastructure before it is shut down (T1584, T1566).
Ride the disclosure. Breach notices tell recipients to expect contact; lures that pretend to be the follow-up arrive into that expectation (T1656).
Move to the edge next. PHP2Shell shows the next step: appliances and firewalls, from which attackers can move into internal networks.

The defender's playbook: decisions for the board

Seven decisions

Re-rank suppliers by data and reach. Tier 1 is any supplier that holds customer lists or sends email or SMS in your name. Expect mail platforms, form builders, booking and community platforms to land there.
Write disclosure into contracts. Notice to you within 24 hours of suspicion; the way in, in writing, within a fixed period; a current list of sub-processors; logs on request; and deletion at exit.
Make suppliers hold less. Purge recipient lists after each campaign and set retention periods. The PPC reminded firms on 7 October that the law asks them to delete personal data they no longer need (PPC).
Use phishing-resistant MFA for staff, administrators and supplier access. This includes contractors' VPN and remote-desktop paths, which the NCO's 5 November guidance singles out.
Test apps and APIs as an attacker would. Before release and continuously, including the APIs the app never shows. Fund this as an operating cost, not a project.
Patch exposed systems against known-exploited flaws within days. Include appliances: find every place PHP runs, as IPA asked on 2 November.
Pre-approve the notice. Templates, decision rights and a customer phishing warning ready to go, because peers publish within 2 days.

The first 90 days

Days	Do	Owner	Done when
0–30	List every supplier that holds customer data or sends in your name, with record counts and sub-processors	Third-party Risk	List complete for Tier 1, signed off by the business owners
0–30	Inventory internet-facing systems and APIs; take unneeded admin screens offline	IT Operations	Inventory reconciled with an outside-in scan
31–60	Add notification, route-disclosure, sub-processor and deletion clauses at Tier 1 renewals; ask current Tier 1 suppliers for them in writing	Legal / Privacy	Every Tier 1 supplier has answered
31–60	Phishing-resistant MFA for administrators and supplier remote access	IT Operations	No admin or supplier path left with password-only access
61–90	Authorisation and rate-limit tests on customer-facing APIs; fixes tracked	IT Operations	Every customer-facing API tested; high findings fixed
61–90	Tabletop: a Tier 1 mail platform is breached and sends phishing as you	SIEM, Email Security, Legal / Privacy	Notice and customer warning out within 48 hours in the exercise

Measures for the board

Measure	Why it matters	Suggested target
Tier 1 suppliers with a 24-hour notice clause and a named security contact	Most of October's notices came from suppliers	100%
Personal data held at Tier 1 suppliers, in records	Exposure is what suppliers hold, not what you hold	Falling quarter on quarter
Time from a supplier's notice to your own customer notice	Peers publish in a median of 2 days	2 working days or less
Exposed systems with known-exploited flaws past their fix deadline	Machine-speed surveys find what is left open	Zero past 7 days
Customer-facing APIs tested for authorisation in the last 90 days	API abuse needs no malware	100%
Admin and supplier access paths with phishing-resistant MFA	Accounts were the second commonest route	100%
Sending domains that would reject mail sent without your authorisation	Platforms were used to send phishing	All sending domains

These targets are our suggestions, not regulatory requirements.

What remains unknown

How 100 of the 176 breaches were done. Their notices do not say, and the route shares above rest on the other 76.
Who is behind the campaign. No government body has named an actor. JPCERT/CC names tools in attack attempts but links none to a named victim.
How many people were affected. Notices count records, accounts or people, they overlap between suppliers and customers, and many give no number.
Whether October is the peak. TSR says large incidents continued in November, and our follow-ups on Docomo and Chainalysis show the pattern continuing.

How we counted

Dataset. Our research tracker's October 2026 dataset holds 1,169 notices published from 1 to 31 October, found through victims' sites, regulators, piyolog, ScanNetSecurity and searches of municipal sites. We excluded 5 that describe a mistake rather than an attack, leaving 1,164.
What we read. For 950 notices we read the organisation's own page; 73 rest on reports only; and 141 come from our earlier dataset, which did not record this. 522 have a second source recorded.
Known limits. About 470 rows, mostly Arcadia's municipal customers, had dates and data fields extracted automatically; a check of 20 matched in 19. The client lists for Blastmail (about 280) and Satofull (78) were compiled from public roundups.
Breaches. Each breach is counted once. A supplier's own notice is merged with its customers', Satofull's wave with Cuenote FC, and Futureshop's IDC Frontier outage with IDC Frontier.
Sectors. Coded by rule from each organisation's own name, with more than 130 names coded by hand. In a random sample of 60 non-public notices, 54 were coded as we would code them by hand; we corrected the other six. In a second random sample of 50, 47 matched, 2 were unclassified and 1 was arguable (a manufacturer coded as retail because the breach was in its online shop). After the samples we also corrected two systematic errors: cable-TV operators had been coded as media, and railway companies, whose names end in 道, had been read as prefectures. 30 notices (2.6%) remain unclassified.
Not comparable with earlier counts. Our 25 October risk model covered 198 attack notices from 10 August to 25 October. This dataset adds municipal notices and compiled client lists, so its counts are much larger and not directly comparable.
Not published. The row-level dataset stays in our research tracker; this briefing publishes aggregates only.

Sources and updates

9 November 2026: first published. We read the government, JPCERT/CC, IPA, PPC and TSR documents directly. TSR's figures appear elsewhere only as republications of its own article, so they rest on TSR alone. The emergency package's chart of critical-infrastructure reports appears only in the Cabinet Secretariat's document; Impress Internet Watch confirms the 5 November guidance. NICT's 13 October alert is cited as summarised by JPCERT/CC and the NCO, and in our earlier analysis; we did not reopen it for this briefing. All counts are from our dataset as of 9 November and will change as late notices are added.

Japan's October 2026 breaches: a CISO briefing on where they came from, how attackers got in, and what boards should decide

30-second briefing