Lessons from Japan's 2026 Breaches (Part 1): AI-Driven Attacks and Protecting ID Documents

Hello, this is Ryuta Hamamoto from TIMEWELL.

In the last week of September 2026 alone, Times Car, the Keio railway group, Nippon Rent-A-Car, Tokyo Metro, eplus and Seicomart each announced that they had been hit by unauthorized access or a cyberattack. Go back to June and the list grows to include KDDI, Aflac Life Insurance Japan, Nichirei, Murauchi.com, Japan's Digital Agency and Gyazo. These are railways, insurers, a telecoms carrier, a food company, retailers and a government agency. Few companies could honestly say "that couldn't happen to us" after reading that list.

Let me be clear about where I stand. This piece is not about blaming anyone. Each of these organisations published what it knew and what it did not yet know, contacted affected people individually and opened help lines, even though all of that takes effort and invites bad press. They chose to disclose anyway. Because they did, the rest of us can learn from it, and I think that deserves credit.

Key points (as of 30 September 2026)

• I tabulated 12 breaches disclosed in Japan between June and September 2026, using only what each organisation officially said. For most of the late-September cases, the entry route has not yet been disclosed
• Public statistics point to the same few ways in: VPN appliances, remote desktop, published but unpatched vulnerabilities, and guessable passwords
• AI has made attacks faster and bigger rather than fundamentally different. AI API keys and the permissions given to AI agents are becoming targets in their own right
• Think about identity documents in five tiers, from "don't keep them" to "delete on schedule". Encryption only really helps once the keys are managed separately from the data

Part 2 covers protecting PCs and other endpoints, and where a small company should start.

Twelve disclosures, using only official statements

The table below sticks to what each company or agency officially published, in order of first announcement, as of 30 September 2026. Causes are given in words close to the official wording, and anything described as "under investigation" is left that way. I have not included press speculation or the names of any attackers.

First announced	Organisation and system	What was exposed	Cause as officially stated	Main response
23 June	KDDI (mail platform it provides to internet service providers)	12,231,954 email addresses, of which 7,616,173 also had passwords	A vulnerability in third-party software used in the system; the software vendor was not aware of it when KDDI found it	System fix, EDR (endpoint monitoring) rollout, forensics, forced password resets1
30 June	Aflac Life Insurance Japan (agent consultation tool and policyholder portal)	About 4.4 million customers (about 220,000 with bank account details) and about 40,000 agencies	Insufficient controls against the access and query technique used; not enough monitoring or throttling of large query volumes in a short time	Systems shut down, reported to the Financial Services Agency, letters to each customer, coordination with banks2
13 July	Nichirei (group servers)	53,866 records across three groups: delivery recipients, business contacts and employees (my total)	A cyberattack; details withheld to prevent further harm	Systems isolated, emergency task force, reported to the Personal Information Protection Commission, all sites back to normal on 24 July34
24 July	Murauchi.com (from part of its web system into several others)	7,716,811 records (names, addresses, phone numbers, email addresses and more)	A vulnerability in part of its web system used as the entry point, then access to several other systems	External access cut, reported to the Commission, police consulted, individual emails5
11 September	Digital Agency (GSS, the shared work environment for government staff)	About 246,000 records on staff and contractors; no data on the general public	A VPN appliance vulnerability that had been published before the attack, exploited before the patch was applied	Account disabled, connections cut, patch applied, reported to the Commission, individuals notified6
16 September	Helpfeel (Gyazo image-sharing service)	About 23.62 million user-related records, plus image metadata	Arbitrary command execution through a vulnerability in the image upload server	Route blocked and fixed, reported to the Commission and the Ministry of Internal Affairs and Communications, service paused and resumed on 27 September78
25 September	Times Mobility (web system for the Times Car car-sharing service)	About 6.6 million accounts, including identity document images for about 1.6 million	Under investigation (forensics by an outside specialist)	Access route blocked, reported to the Commission and police, individual notices, 24-hour help line91011
26 September	Keio railway group (group servers)	No data leak confirmed as of 26 September	Ransomware attack; entry route under investigation	Network isolated, police notified, investigation with outside experts12
26 September	Nippon Rent-A-Car Service (its smartphone app)	41 members; for those who had registered a licence, licence number, address and date of birth may also have been viewed	Not stated (investigation continuing)	Individual notices and password resets, reported to the Commission, police consulted13
27 September	Tokyo Metro (server for its Metpo loyalty programme)	About 59,000 email addresses to which mailings had been stopped (possibly viewed or taken)	Under investigation	Point of compromise identified and blocked, emails to those affected, dedicated help line14
29 September	eplus (system that manages refunds for its Smachike e-tickets)	1,463 records, 751 of which include bank account details for refunds	Believed to be unauthorized access by a third party (method not described)	Settings changed to block access, all systems re-inspected, reported to the Commission, preparing a police report15
29 September	Seicomart (member data server, reached through its app server)	About 570,000 accounts (possibly viewed)	Under investigation	Connection to the server cut, sign-ups and log-ins suspended16

The first thing that jumps out is how much is still "under investigation". None of the six disclosures from late September explains how the attackers got in. Forensic work, which reconstructs an intrusion from logs and traces, simply takes time. Telling people what you know now, instead of waiting until you know everything, gives them a head start on protecting themselves.

Times Car detected the intrusion at 9:07 a.m. on 25 September and issued its first notice the same day⁹. On the 28th it published the number of accounts and the data involved, and on the 29th the number and types of identity document images¹⁰¹¹. Three notices in four days. Aflac's report of 31 July went further than most companies would: it said the attack traffic looked like normal use and so was not caught immediately, and that its design reviews and pre-release penetration tests had not anticipated the technique². Putting your own weak spots in writing is not easy.

Almost every company made the same request of its customers: watch out for emails, texts and calls pretending to be us, and remember that we will never ask for your password. That is not boilerplate. Leaked names and email addresses are the raw material for the next round of phishing.

The statistics say the doors are mostly the same

Individual cases may still be under investigation, but the aggregate numbers are clear. Japan's Personal Information Protection Commission (PPC), the national data protection regulator, received 17,139 breach reports from businesses in fiscal 2025 (April 2025 to March 2026). Of those, 3,822 fell into the category of leaks possibly carried out for an improper purpose, which in practice means unauthorized access and similar attacks¹⁷. From the cases it followed up, the PPC names three recurring causes: vulnerabilities in VPN appliances or e-commerce software that were published, with fixes available, yet left unpatched; IDs and passwords that were easy to guess; and database access controls left wrong by configuration mistakes. It files all three under inadequate security safeguards.

The National Police Agency's report on the first half of 2026 counts 123 ransomware incidents reported between January and June, the most for any half-year since records began in the second half of 2020¹⁸. Small and medium-sized businesses accounted for 79 of them, or 64.2% by my calculation. Of the 36 victims who answered the survey question about how the attackers got in, 18 (50%) named VPN appliances and 9 (25%) named remote desktop. Thirty-six is a small sample, but the full-year 2025 figures tell the same story: 61 of 92 cases came through VPN appliances.

The Information-technology Promotion Agency (IPA), Japan's government body for IT security, publishes an annual list of the top ten threats to organisations. In the 2026 edition, ransomware is first, attacks through the supply chain or contractors second, and "cyber risks around the use of AI" enters for the first time in third place¹⁹. Fourth is attacks that exploit system vulnerabilities.

I want to avoid a misreading here. The PPC's list describes cases reported across the country, not the twelve organisations in my table. KDDI's vulnerability was unknown even to the software vendor, and the Digital Agency says it was working through the fix faster than its usual schedule when the flaw was exploited⁶. I covered that case in detail in What the Digital Agency's GSS Breach Teaches Companies About VPN Patching. Even so, among the cases where a cause was given, four (KDDI, Murauchi.com, the Digital Agency and Gyazo) point to a vulnerability as the starting point. That fits the statistical picture: the way in is usually a weakness in something reachable from the internet.

What AI agents are changing

The manual work of attacking is being handed to AI

AI companies publish reports on how their own models have been misused, which makes them first-hand sources.

In November 2025, Anthropic said that attackers it assessed as a state-sponsored group had used its AI coding tool to try to break into roughly 30 organisations, succeeding in a small number of cases²⁰. According to Anthropic, AI performed 80 to 90% of the campaign, with humans stepping in at perhaps four to six critical decision points per operation. The same report notes the AI's limits, such as occasionally inventing credentials. An August 2025 report described a data extortion operation against at least 17 organisations in which AI automated reconnaissance, credential harvesting and network intrusion, with ransom demands sometimes exceeding $500,000²¹.

Anthropic's September 2026 report contains a line I would put in front of every IT team. Access to AI itself, in the form of compromised API keys, session tokens (the data that keeps you logged in) and devices, "has increasingly become the sole objective of multiple criminal groups"²². The report's advice is to treat AI keys and agent integrations as seriously as production credentials, because attackers do. The more your staff use AI at work, the more those accounts and keys become the equivalent of a master key to the office.

But it is not a magic new weapon

Read only those reports and you might conclude AI has turned attacks into something entirely new. Public agencies and other AI companies are more measured. Google's Threat Intelligence Group wrote in February 2026 that it had "not yet observed" state-backed or influence-operation actors "achieving breakthrough capabilities that fundamentally alter the threat landscape"²³. OpenAI's October 2025 report found that attackers were building AI into existing workflows rather than creating new ones, and that there was "no evidence of new tactics or that our models provided threat actors with novel offensive capabilities"²⁴. The IPA's commentary on its 2026 threat list singles out indirect prompt injection as a genuinely new attack on AI's own weak points, but says most other cases are conventional attacks made semi-automated and faster by AI, so conventional security measures remain effective²⁵.

I don't see these two views as contradictory. The substance of the attacks is old: exploit a vulnerability, log in with stolen credentials, trick someone into clicking. What has changed is speed, volume and how much one attacker can get done. So the answer for defenders is not "buy AI to fight AI". It is to run the basics, patching, authentication, permissions and backups, at a pace that can keep up. That will do far more good.

AI agents are becoming targets themselves

The other shift is that the AI agents companies deploy are becoming targets and stepping stones in their own right. An agent that reads email, logs into internal systems and changes data on its own will be attacked the same way a person with those rights would be.

On 18 September 2026, Japan's Ministry of Economy, Trade and Industry (METI) held the first meeting of a new sub-working group on the safe use of AI agents by businesses²⁶. The secretariat's material names indirect prompt injection and the theft of AI accounts and API keys as attacks aimed at AI, and sorts the risks of AI agents into twelve factors. They include contamination of instructions and inputs, where an agent is steered by malicious or external content; flawed or abused tools and permissions, where it has been given too much power; damage multiplying through high-speed, high-volume execution, where mistakes or attacks run faster than any human can respond; and human oversight and approval becoming a formality. METI plans to publish guidance during fiscal 2026, so for now this is a working draft.

International frameworks point the same way. OWASP lists "Excessive Agency" among the risks of LLM applications and traces it to excessive functionality, excessive permissions and excessive autonomy²⁷. Its December 2025 top ten for agentic applications puts agent goal hijack, tool misuse, and identity and privilege abuse at the top²⁸. For a concrete example of indirect prompt injection, see my piece on EchoLeak.

What are your agents allowed to do? Whose permissions do they run with? When someone clicks "approve", do they actually read what they are approving? If nobody in your organisation can answer those three questions straight away, that is the first thing to fix. If you want a quick read on how evenly AI knowledge is spread across your staff, our AI literacy check is a reasonable place to start.

"Messages pretending to be us" are getting harder to spot

That brings me back to phishing, the one warning every company in the table gave its customers. The Council of Anti-Phishing Japan received a record 2,454,297 phishing reports in 2025, about 1.43 times the previous year²⁹. Its guidelines say generative AI now produces natural-sounding Japanese, so awkward wording no longer gives phishing away, and that warnings alone are no longer enough to prevent the damage³⁰. Voice phishing, where criminals phone companies while posing as their bank, has also been rising since autumn 2024.

An IPA paper from August 2026 describes two techniques that work without stealing a password at all³¹. In one, a fake site relays traffic to the real one, lets the victim complete multi-factor authentication, and then steals the session cookie that proves they are logged in. In the other, information-stealing malware (infostealers) lifts IDs and passwords saved in browsers and other apps; those credentials are then traded among attackers and lead to ransomware or other breaches.

Put leaked names and email addresses together with polished, AI-written text and "a message from us" becomes very hard to tell apart from the real thing. For impersonation by voice and video, my analysis of the Arup deepfake case is worth a read.

How to hold identity documents: starting from the Times Car disclosure

What has been disclosed

Times Car's third notice says identity document images were leaked for about 1.6 million accounts¹¹. Four types are confirmed: driving licence images, proof-of-address images such as utility bills, student ID images (for the student plan) and family verification images (for the family plan). The second notice lists "driving licence information" among the leaked items, but as of 30 September it does not say what that includes, such as licence numbers or expiry dates¹⁰. The company says it will give affected members details in about two weeks. The cause is under investigation.

Passwords, on the other hand, were stored in a form that cannot be restored, and the company says it has found no evidence that passwords themselves were exposed in readable form¹⁰. That is a good example of design limiting the damage, and worth remembering.

What follows is not a discussion of how Times Car actually stored anything. That has not been disclosed, and I will not guess. Treat it as a general framework for deciding how far your own company should go if it handles identity documents. The legal points are general too, so please check your specific situation with a lawyer.

What the law asks you to record, and what companies collect

In Japan, car-sharing is licensed as a form of vehicle rental. One basis for recording a driver's licence is a circular from the Ministry of Land, Infrastructure, Transport and Tourism (MLIT) on rental cars³². It requires operators to keep a rental register, on paper or electronically, recording, among other things, the driver's name, address, type of driving licence and driving licence number, and to keep it for two years from the end of the rental. Rental-type car-sharing falls under the same framework. As far as I can see, the circular says nothing about keeping an image or copy of the licence.

Times Car's rental terms say that, when you apply to join, the company asks you to present your driving licence and other identification (for web applications, including sending it electronically) and to agree to it being copied³³. When you renew your licence, you submit a copy or image of the new one. In other words, keeping images is a practice the operator set out in its own terms rather than something the law directly demands.

I am not saying collecting images is wrong. A business that lends unattended cars to members has good reason to check that the applicant is who they claim to be, that the licence is genuine and that it hasn't expired, and an image is a practical way to do that. But where there is a gap between what the law requires you to record and what you actually hold, you should be able to explain why you hold the difference and for how long. Article 22 of Japan's Act on the Protection of Personal Information asks businesses to make an effort to delete personal data without delay once they no longer need it (an obligation to try, and one that gives way where another law sets a retention period)³⁴.

Five tiers of holding identity documents

The choice is not simply "encrypt or don't". I find it more useful to think in five tiers. The higher the tier, the less you lose in a breach; the lower the tier, the more you rely on operational discipline to make up for it.

Tier	How you hold it	What leaves in a breach
1	Don't keep it. Read the IC chip and keep only the result and time of the check	A record that a check happened
2	Keep only the number the law requires and the check result; delete the image once the check is done	The number and the result
3	If you must keep images, store them apart from member data and restrict who can see them and through which path	Images, but only if that separate store is also breached
4	Encrypt each field in the application and manage keys somewhere other than the data	Unreadable data, unless the keys are stolen too
5	Set a retention period and delete when it ends	Only what is still within the period

In practice you aim for tier 1 or 2, combine tiers 3 and 4 only for the processes that genuinely need images, and apply tier 5 to everything. OWASP's cheat sheet on cryptographic storage puts it bluntly: "The best way to protect sensitive information is to not store it in the first place"³⁵. Tier 3 means not putting images in the same place as your member database, so that compromising one server doesn't hand over both customer records and document images.

For tier 4, a common pattern is envelope encryption: a data encryption key (DEK) encrypts the data, a key encryption key (KEK) encrypts the DEK, and the KEK lives in a cloud key management service or an HSM (a dedicated hardware device for keys). OWASP says keys should be stored separately from the encrypted data where possible, and that the KEK must be stored separately from the DEK³⁵. In Japan, IPA publishes design guidelines for cryptographic key management systems³⁶.

Where "encryption at rest" doesn't help

I often hear "our database is encrypted". Usually that means encryption at the disk or database layer, and it only helps in certain situations.

OWASP says the right layer depends on your threat model, and gives the example that hardware-level encryption "is effective at protecting against the physical theft of the server, but will provide no protection if an attacker is able to compromise the server remotely"³⁵. NIST SP 800-111 explains that once a user passes pre-boot authentication, full-disk encryption software "transparently decrypts and encrypts" data as needed³⁷. Put those together and disk or database encryption is a defence against stolen hardware and media. If someone gets into a running server and pulls data through legitimate paths, it comes out decrypted. That is my reading, not a quote from either source.

That is why tier 4 matters: the application encrypts each field and tightly limits who and what can decrypt it. Only the identity-check screen can open an image. Every decryption is logged. A sudden burst of decryption requests is stopped. Aflac listing stronger monitoring and control of high-volume access among its remediation steps reflects the same idea².

What "advanced encryption" means in Japanese law

Encryption also has legal weight in Japan. Under the Act on the Protection of Personal Information, leaks that may have been caused for an improper purpose, such as unauthorized access, or that affect more than 1,000 people must be reported to the PPC. But if the leaked data was protected by what the rules call advanced encryption or other measures necessary to protect individuals' rights and interests, no report is required³⁴.

The PPC's Q&A (Q6-19) sets out the conditions³⁸. The encryption must make the data hard for a third party to read by the technical standards of the time of the leak. It should use algorithms such as those on Japan's e-Government Recommended Ciphers List or in ISO/IEC 18033, properly implemented. And the means of making it readable again, meaning the keys, must be properly managed. For that, at least one of three conditions must hold: the encrypted data and decryption keys are kept apart and the keys themselves are protected from leaking; the data or keys can be deleted remotely; or the system is designed so that third parties cannot use the keys.

So "we encrypted it" is not enough. Only once you have designed where the keys live and who can use them can a leak potentially fall outside the reporting duty. If the key sits on the same server as the application and the application decrypts automatically, and an attacker takes over the application, I would be cautious about claiming the data was unreadable to a third party. That is our interpretation; please confirm individual cases with a lawyer or the PPC.

Moving away from sending images to prove identity

Government policy is moving away from image-based identity checks. Japan's Act on Prevention of Transfer of Criminal Proceeds sets identity verification rules for financial institutions and certain other businesses. Its ordinance has been revised so that, from 1 April 2027, verifying identity online by having customers send images or copies of their ID documents will in principle be abolished, and reading the ID's IC chip data will become the standard method³⁹. For face-to-face checks, photo IDs will be limited to those with IC chips, and reading the chip will be mandatory. The National Police Agency cites bank accounts opened with forged or altered ID documents and then used for fraud as the background³⁹. In a separate report it also notes cases of generative AI being misused to create identity documents⁴⁰. Image-based checks are weakening from both ends: images can be forged, and images you have collected can leak.

There is also a model for what to keep. The Digital Agency's app for checking My Number Cards (Japan's national ID card) in person reads the card's IC chip to guard against forged cards. The only things it stores on the business's smartphone are the time of the check and an eight-digit reference number derived from the card, excluding the six-digit date of birth⁴¹. The agency's material states plainly that no personal information is stored.

I have not been able to confirm whether car-sharing or car rental falls under the revised identity verification rules. Still, as government systems for confirming identity without holding images mature, that is a good prompt for any business to revisit its own approach.

If your company handles identity documents, see whether you can answer these questions. What does the law actually require you to keep, and what do you actually hold? Why do you hold the difference? Where is it, who can see it, and for how many years? If it leaked, could you honestly say it was unreadable? Start with whichever question you can't answer.

Wrapping up Part 1, and what comes in Part 2

Part 1 has looked at how attackers get in and what is left for them to take once they do. AI is making attacks faster and bigger, and AI agents and their keys are now targets too. And the information you collect will all leave at once in a breach, unless you split it up, keep the keys elsewhere and delete it on schedule.

In Part 2, I look at how to protect employees' PCs and other devices, and where a small or mid-sized business without a dedicated security person should begin, based on material from public agencies.

About TIMEWELL

TIMEWELL helps companies bring AI into their work, through implementation support and training. The more widely AI is used inside a company, the more the issues in this piece, managing AI accounts and API keys, deciding what permissions agents get, and making staff harder to fool, become part of adopting AI rather than an afterthought. TIMEWELL holds ISO/IEC 27001 (information security management) certification, with a scope covering the planning, development and provision of SaaS products using AI technology.

Our AI security training, WARP SECURITY, spends less time on attack techniques and more on what to decide before anything happens: how far to let AI agents act, how to design approvals, and how to handle an incident, including the decision to disclose. If you'd like to think this through for your own organisation, you can book an individual consultation.

Summary

• The twelve organisations that disclosed breaches between June and September 2026 published what they knew mid-investigation and set up individual notices and help lines. For most late-September cases, the entry route has not yet been disclosed
• Ransomware reports hit a half-year record of 123 in the first half of 2026, with SMEs making up over 60%. VPN appliances and remote desktop remain the main ways in
• AI has made attacks faster and bigger. Public agencies say conventional defences still work, but AI API keys, agent permissions and more convincing AI-written phishing now need specific attention
• Think about identity documents in this order: don't keep them, keep only the number, keep them apart, encrypt with separately managed keys, delete on schedule. Disk or database encryption alone will not stop someone who is inside a running server

Anything you collect may one day leak. Seen that way, the first question is not how to protect it but whether you need to keep it at all. Part 2 picks up from there, at the front door.

References

The facts in this article are based on the sources below, as of 30 September 2026. Causes are given only as far as each organisation has officially explained them. Sources marked (Japanese) are in Japanese; titles are my translations.

Footnotes

1. Apology and report on unauthorized access to the mail system for ISP operators (Japanese) — KDDI — 6 July 2026 (corrected 21 July) ↩

2. Investigation results and recurrence prevention measures regarding unauthorized access to our systems and the resulting data leak (Japanese) — Aflac Life Insurance Japan — 31 July 2026 ↩ ↩² ↩³

3. System failure in our group (2nd report) (Japanese) — Nichirei — 15 July 2026 ↩

4. System failure in our group (7th report) (Japanese) — Nichirei — 18 September 2026 ↩

5. Apology and report on the leak of customer information due to unauthorized access (1st and 2nd reports) (Japanese) — Murauchi.com — posted 24 July 2026, updated 15 September ↩

6. Q&A on the possible leak of staff personal information due to unauthorized access to the Government Solution Service (Japanese) — Digital Agency — 11 September 2026 ↩ ↩²

7. Notice and apology regarding the information leak caused by unauthorized access to Gyazo (Japanese) — Helpfeel — 16 September 2026 ↩

8. Notice and apology regarding the information leak caused by unauthorized access to Gyazo (2nd report) (Japanese) — Helpfeel — 25 September 2026 (updated 27 September) ↩

9. Possible leak of personal information due to unauthorized access to the Times Car website (1st report) (Japanese) — Times Mobility — 25 September 2026 (updated 26 September) ↩ ↩²

10. Investigation results and next steps regarding unauthorized access to the Times Car website (2nd report) (Japanese) — Times Mobility — 28 September 2026 ↩ ↩² ↩³ ↩⁴

11. Investigation results and next steps regarding unauthorized access to the Times Car website (3rd report) (Japanese) — Times Mobility — 29 September 2026 ↩ ↩² ↩³

12. Notice and apology regarding system failure caused by a ransomware attack (Japanese) — Keio Corporation — 26 September 2026 ↩

13. Apology and notice regarding the leak of member information due to unauthorized access to the NR app (Japanese) — Nippon Rent-A-Car Service — 26 September 2026 ↩

14. Apology regarding unauthorized access to services for Metpo members (Japanese) — Tokyo Metro — 27 September 2026 ↩

15. Apology and notice regarding unauthorized access to our systems and the leak of personal information (Japanese) — eplus — 29 September 2026 ↩

16. Apology and notice regarding the possible leak of personal information due to unauthorized access to the Seicomart app (Japanese) — Seicomart — 29 September 2026 ↩

17. FY2025 Annual Report (Japanese) — Personal Information Protection Commission — July 2026 ↩

18. Cyberspace threats in the first half of 2026 (Japanese) — National Police Agency — September 2026 ↩

19. 10 Major Information Security Threats 2026 (Japanese) — Information-technology Promotion Agency (IPA) — 29 January 2026 ↩

20. Disrupting the first reported AI-orchestrated cyber espionage campaign — Anthropic — November 2025 ↩

21. Detecting and countering misuse of AI: August 2025 — Anthropic — August 2025 ↩

22. Detecting and countering misuse of AI: September 2026 — Anthropic — September 2026 ↩

23. GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use — Google Threat Intelligence Group — 13 February 2026 ↩

24. Disrupting malicious uses of AI: October 2025 — OpenAI — October 2025 ↩

25. 10 Major Information Security Threats 2026, commentary for organisations (Japanese) — IPA ↩

26. First meeting of the Industrial Cybersecurity Study Group WG1 sub-working group on the safe use of AI agents by businesses: meeting materials (Japanese) — Ministry of Economy, Trade and Industry — 18 September 2026 ↩

27. LLM06:2025 Excessive Agency — OWASP GenAI Security Project ↩

28. OWASP Top 10 for Agentic Applications — OWASP GenAI Security Project — 9 December 2025 ↩

29. Phishing Report 2026 (Japanese) — Council of Anti-Phishing Japan — May 2026 ↩

30. Anti-Phishing Guidelines, FY2026 edition (Japanese) — Council of Anti-Phishing Japan — May 2026 ↩

31. Attack email techniques targeting organisations and countermeasures (Japanese) — IPA Security Center — 3 August 2026 ↩

32. Handling of rental of private vehicles by lessors as vehicle users (rental cars), last amended 31 May 2022 (Japanese) — Ministry of Land, Infrastructure, Transport and Tourism ↩

33. Times Car rental terms (Japanese) — Times Mobility (viewed 30 September 2026) ↩

34. Guidelines on the Act on the Protection of Personal Information (General Rules), partially revised April 2026 (Japanese) — Personal Information Protection Commission ↩ ↩²

35. Cryptographic Storage Cheat Sheet — OWASP Cheat Sheet Series ↩ ↩² ↩³

36. Cryptographic key management guidelines, including design guidelines for cryptographic key management systems (Japanese) — IPA — updated 24 April 2026 ↩

37. SP 800-111: Guide to Storage Encryption Technologies for End User Devices — NIST — November 2007 ↩

38. Q&A Q6-19: What counts as personal data protected by advanced encryption or similar concealment? (Japanese) — Personal Information Protection Commission ↩

39. Annual report on the prevention of transfer of criminal proceeds (2025), special feature 2: revisions to identity verification methods (Japanese) — National Police Agency ↩ ↩²

40. Cyberspace threats in 2025 (Japanese) — National Police Agency — March 2026 ↩

41. About the My Number Card in-person verification app (Japanese) — Digital Agency — July 2024 ↩