Japan Digital Agency
The agency built to modernise government technology was reached through the oldest remote access problem there is.
What happened?
An attacker exploited a VPN vulnerability to reach systems at Japan's Digital Agency, the department created to modernise government technology and services. Reporting on September 14, 2026 put the exposure at approximately 246,000 personnel records.
Public reporting has not established the attacker, the dwell time or the specific vulnerability. Those gaps are noted here rather than filled, and this entry should be read as thinner than the others in this series until an official notice is published.
What data was actually inside?
Personnel records containing personal information on government employees. Reporting available at the time of writing does not break that down further, so the specific fields are not established.
What can be said is structural. A central digital agency holds staff records not only for itself but often for the programmes it runs across other departments, which is why a 246,000 figure exceeds the headcount of any single ministry team.
Who gets hurt and how?
Government employees, who did not choose the employer's security posture and cannot change the identifiers involved. Public sector personnel data is a targeting resource rather than a fraud resource: it maps who works on what, reports to whom and can be approached.
For a digital agency specifically, the staff list is also a map of which people hold administrative access to national systems. That makes the exposed set useful for the next intrusion rather than only for this one.
What did they think they were doing right?
A VPN is the correct control for remote access to internal systems, and requiring one is the baseline recommendation in every public sector security framework. The agency was doing the expected thing.
Edge devices carry a specific burden that the framework language tends to understate. A VPN concentrator is reachable from the internet by definition, which makes patch latency on that one appliance worth more than patch latency across a thousand internal machines.
What did they not know about their own data?
The shape of this incident suggests the boundary was better understood than the contents. An organization can know exactly which appliance was vulnerable and still not know what the systems behind it were holding.
The 246,000 figure arrived quickly, which is a good sign, and the absence of any field-level breakdown in public reporting is the familiar one. Counting records is a query. Describing what is inside them is an inspection, and the two get confused precisely when there is no time left to tell them apart.
If a single credential in your environment was compromised today, could you say within 24 hours exactly what data was accessed?
Not sure where to start? How to find sensitive data across your estate
What does attribution look like the morning after?
No group has claimed it in public reporting. VPN vulnerabilities are exploited at scale by both criminal and state aligned actors, and a government technology department is a plausible target for either.
Attribution for a national agency breach usually surfaces through a government statement rather than a leak site, which means it arrives later and with fewer details than the ransomware cases in this series.
What would have changed the outcome?
Patching the edge faster, which is the obvious answer and the one every post incident review reaches. It is also the one that depends on knowing the appliance exists and who owns it.
The less obvious answer is reducing what sits behind the VPN in reachable form. Personnel records for 246,000 people accessible from a single remote access path is an architecture decision, and it is the decision that turned an appliance vulnerability into a national personnel disclosure.
Japan Digital Agency found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.
Want to understand the process first? Read our guide to sensitive data discovery .