OTS Breach: Up to 730,000 Customers and Driver's Licence Numbers

Okinawa Tourist Service (OTS) has confirmed that personal data on up to about 730,000 customers of its rental car, hotel, activity and membership services leaked to outside parties, including Japanese driver's licence numbers. Up to 6,000 licence images are still under investigation. Customers should expect impersonation attempts and treat unexpected contact as suspect.

Okinawa Tourist Service Inc. (沖縄ツーリスト株式会社, OTS) is a Naha based travel company that, according to Nikkei, was founded in 1958. It runs OTS Rent-a-Car, one of the best known rental car brands for visitors to Okinawa, along with hotel, activity and membership services. This post works from the two notices OTS published on its corporate site on 21 and 23 October 2026, translated from Japanese, and quotes every figure exactly as OTS states it. Press reports are used for context and attributed. OTS has not said when the intrusion happened or how the data left, and we do not guess. Where this post mentions the wider run of Japanese breaches this autumn, the link is timing only.

What happened

OTS received an inquiry from someone outside the company about a possible leak of personal information. Its first notice describes this as an "external inquiry regarding a possible leakage" that prompted an initial investigation. That investigation found a leak was possible. OTS blocked external access to the affected website on 18 October 2026 and, from 16:30 JST on 20 October, stopped taking new reservations for five services that handle personal information.

The first public notice followed on 21 October. On 22 October Japanese outlets reported data described as OTS customer data on sale on dark web sites. On 23 October OTS published a second report. It said that, with outside experts, it had found a match between information said to have leaked and information it holds, and had therefore concluded that customer data had leaked. It put the number of customers at up to about 730,000.

As of 25 October, the consumer booking site at www.otsinternational.jp and the rental car pages beneath it still return an HTTP 503 status with a short suspension message in Japanese, English, Traditional Chinese, Simplified Chinese and Korean.

Timeline

All times are Japan Standard Time. Where a source gives only a date, the table gives only a date. Press items are listed because they changed what the public knew, not because they are confirmed facts.

What is still unknown

• When the intrusion happened. Neither notice gives a date for the intrusion or for the data leaving OTS's systems. If the May 2026 sale post described by Ryukyu Shimpo is genuine and relates to the same data, the data may have been taken months before OTS blocked access. That is a reported, unverified claim, and OTS has not commented on it.
• How the attacker got in. OTS has not named a vulnerability, product, supplier or attack method. No CVE has been linked to this incident.
• Who did it. No threat actor has been named by OTS or by the police in any published source.
• Whether the licence images leaked. OTS says they are stored in a separate database and that it is still investigating.
• When the external inquiry arrived and who sent it. No date or sender is given.
• Whether individual notices will be sent. The notices are public; they do not say whether OTS will contact each affected customer.

The numbers, exactly as stated

Three different numbers are in circulation. They do not reconcile, and they measure different things.

Two points matter. OTS's "up to about 730,000" is a ceiling, not a count of confirmed victims. And the 6,000 figure is the size of the image store, not a count of leaked images; nothing OTS has published confirms that any licence image left its systems.

OTS's notice also marks the licence fields with an asterisk: they concern driver's licences issued in Japan only. OTS does not say how many of the up to about 730,000 customers are visitors from overseas, whose names and contact details may be in the data without any Japanese licence fields.

Technical details

OTS has published no indicators of compromise, no CVE, no file names, no hashes and no attacker infrastructure. What follows is everything concrete that the primary sources do publish, plus the legal and structural facts a defender needs to reason about this kind of leak.

Services in scope

OTS lists five services as suspended for new reservations. These are the services it describes as handling personal information.

OTS says its other services continue to operate. Bookings completed by 16:30 on 20 October 2026 can be used as booked.

Data fields

The second report lists the fields stored in the system that OTS considers the source of the leak.

Not in that system, according to OTS:

• Credit card information. OTS says the system where the leak was confirmed did not hold card data, and no card leak has been found.
• Licence images. Up to 6,000 images of Japanese licences sit in a separate database. Whether they leaked is still under investigation.

How OTS confirmed the leak

The second report says OTS confirmed a match between customer information said to have leaked externally and information it holds, and on that basis judged that the data had leaked. In other words, the confirmation came from comparing data that had appeared outside with OTS's own records; the notices do not describe what its logs showed.

What the sale listings reportedly contained

All of this is second hand. None of it has been confirmed by OTS beyond the match described above.

• Ryukyu Shimpo, 23 October: a security vendor's report from May describes a dark web post claiming to hold and sell OTS related data. The vendor said the post cited customers' names, dates of birth, contact details and addresses, and included screenshots of ID documents and driver's licences to make the claim look credible. The vendor did not verify whether the data was genuine, but noted points that matched, including the domain of the rental car site OTS suspended.
• Okinawa Times, 23 October: about 600,000 records offered for sale, based on a security vendor's check.
• NHK, 22 October: licence images and other personal data, possibly from an Okinawa rental car company, on sale; the headline cites about 4,000 images.

No price, forum name or seller name has been published in the sources we could read, and this post does not add any.

Containment, as described

Official contacts and how to recognise real messages

OTS lists only email contacts. No phone line or hours are published in either notice.

Note the domains. The notices sit on the corporate site otspremium.com, the booking site is www.otsinternational.jp, and the contact addresses use otsinfo.co.jp. A message that uses any other domain and claims to be about this incident deserves extra suspicion. OTS says it will never ask for passwords or credit card information by email, SMS or phone.

The legal status of a licence number in Japan

Under Japan's Act on the Protection of Personal Information (APPI), some numbers count as personal information on their own, even with no name attached. These are called individual identification codes (個人識別符号). Article 1, item 5 of the APPI Enforcement Order lists the driver's licence number under the Road Traffic Act, and also the licence information record number used for the My Number card based licence. In practical terms, a licence number is personal information by itself.

Reporting rules that apply

The APPI (Article 26) requires a business to report certain leaks to the PPC and to notify the people affected. The PPC's breach reporting page lists four categories for private businesses:

The PPC asks for a preliminary report within 3 to 5 days of discovery and a final report within 30 days, or within 60 days where an improper purpose may be involved. A leak of this size meets the "more than 1,000 people" test on its own. OTS has not published its discovery date, so the deadlines cannot be worked out from public information.

Article 26(2) requires notice to each affected person, unless that is difficult and the business takes an alternative measure that protects them. Public notices are a common alternative. OTS's notices do not say whether individual messages will follow.

What a leaked Japanese licence number means

A Japanese driver's licence number is 12 digits. The breakdown below comes from a Japanese automotive news site rather than an official police document, and it notes that how digits 5 to 10 are assigned is not public. Treat it as reported, not official.

The defender lesson is in the last row. According to the same reporting, the number does not change at renewal, and only the final digit changes when a licence is reissued after loss or theft. A leaked licence number cannot be rotated the way a password can. The first 11 digits stay with the holder.

On its own, the number does three things for someone who holds it alongside a name, birth date and address:

1. It makes impersonation more convincing. A caller who can recite your licence number, issue date and expiry date sounds like a rental company, insurer or police officer. That is the main near term risk, and it is why OTS's notice focuses on fake emails, SMS and calls.
2. It links records. The first four digits reveal where and when someone first got a licence. Combined with a birth date, that is enough to match people across other leaked datasets.
3. It fills in forms. Some identity checks ask the applicant to type a licence number. A number by itself does not reproduce the card or its chip, but it removes one obstacle for a fraudster who already has other pieces.

The licence images, if they leaked, would be a larger problem, because an image carries the photo, signature area and layout that some remote checks still accept. That is the open question OTS is investigating.

What reissue does and does not do

After the Times Car breach earlier this autumn, several prefectural police forces let people whose licence images leaked apply for a reissue without having lost the card. Shizuoka Prefectural Police published such a page; its fee table lists 2,600 yen for a conventional licence, 1,500 yen for a My Number card based licence and 2,700 yen for both. Hokkaido Shimbun reported about 70 such reissues in Hokkaido in roughly two weeks. Hokkaido Police also warned that a reissue "does not mean the risk of misuse disappears".

We found no announcement from Okinawa Prefectural Police or any other force about reissues for OTS customers as of 25 October. If one appears, remember what a reissue changes: the physical card, and, as reported, the final digit of the number. It does not change your name, birth date, address or the first 11 digits.

What to do now

If you have used OTS Rent-a-Car, OTS HOTEL, OTS ACTIVITIES or OTS Club

1. Treat any unexpected contact about this incident as suspect. OTS's second report warns of emails, SMS and calls impersonating OTS or related parties. Do not open links or attachments in messages you did not expect, and do not enter passwords, one time codes or card numbers.
2. Know what OTS will never do. OTS says it will not ask for passwords or credit card information by email, SMS or phone. A message about a refund, a damage charge or a compensation payment that asks for card details is not from OTS.
3. Contact OTS only through the published addresses. Use the email addresses in the table above, typed by hand, not the reply button on a message you received.
4. Secure the Facebook account if you used it with OTS. Your Facebook ID was in the data. Turn on two factor authentication, review active sessions and connected apps, and be wary of messages that use your OTS booking as a pretext.
5. Consider a self declaration with the credit bureaus. The Japanese Bankers Association's personal credit information centre (全国銀行個人信用情報センター) runs a self declaration (本人申告) scheme. Its page says it covers cases where ID document information, including image data, may have leaked to a third party. Member lenders see the note when they check your credit. The fee is 500 yen, online applications need a My Number card and an NFC capable phone, and a mail route exists. The centre is clear about the limits: it does not guarantee to prevent misuse, and the note is not checked when someone opens a deposit account. Other credit bureaus run their own schemes; check their current terms.
6. Watch your post and statements. Unexpected contracts, credit card applications, phone contracts or debt collection letters in your name are the signals that matter. You can ask the credit bureaus to disclose your file.
7. Decide on a reissue later, not now. No reissue route has been announced for OTS customers. If you lose your physical licence or it is stolen, report it to the police and apply for a reissue in the normal way.
8. Complain through the right channel. Start with OTS. If you are not satisfied, the PPC's Personal Information Protection Act consultation dial (個人情報保護法相談ダイヤル) is 03-6457-9849, weekdays 9:30 to 17:30, by phone only. It handles complaints about how businesses handle personal information and can, under certain conditions, mediate.
9. If you rented with an overseas licence, OTS says the licence fields concern Japanese licences only. Your name, contact details, birth date and any Facebook ID may still be in the data, so the phishing advice applies to you as well.

If you run a booking, rental or membership platform

The OTS case is a reminder that ID data collected for a rental contract outlives the trip. These checks take an afternoon and tell you how large your own version of this incident would be.

1. Find every column that holds licence, ID or social login data. On PostgreSQL:

SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE column_name ILIKE ANY (ARRAY[
  '%license%', '%licence%', '%menkyo%', '%dl_no%',
  '%facebook%', '%fb_id%', '%social%', '%birth%', '%dob%'
])
ORDER BY table_schema, table_name;

On MySQL, the same query works against information_schema.COLUMNS with LIKE conditions joined by OR.

2. Count how much of it belongs to people who are no longer customers. Adjust names to your schema:

SELECT
  count(*) FILTER (WHERE last_rental_end < now() - interval '1 year') AS older_than_1y,
  count(*) FILTER (WHERE last_rental_end < now() - interval '3 years') AS older_than_3y,
  count(*) AS total
FROM customers
WHERE license_number IS NOT NULL;

If the first two numbers are large, that is your retention problem, and it is the cheapest risk reduction available.

3. Check that the image store is separate and private. OTS kept licence images in a separate database, which is the right pattern. Make sure yours is not reachable from the same credentials as the booking application, and that object storage is locked down:

# AWS S3
aws s3api get-public-access-block --bucket <bucket>
aws s3api get-bucket-policy-status --bucket <bucket>
aws s3api get-bucket-encryption --bucket <bucket>

# Google Cloud Storage
gcloud storage buckets describe gs://<bucket> \
  --format="value(iamConfiguration.publicAccessPrevention)"

# Azure Blob Storage
az storage account show --name <account> \
  --query "allowBlobPublicAccess"

You want public access blocked, no public policy status, encryption enabled and public blob access set to false.

4. Stop storing the licence number in clear text if you only need to match it. A 12 digit number with a check digit has a small search space, so a plain SHA-256 hash can be reversed by brute force. Use a keyed hash with the key held in a key management service:

import hmac, hashlib

def licence_token(number: str, key: bytes) -> str:
    digits = "".join(ch for ch in number if ch.isdigit())
    return hmac.new(key, digits.encode(), hashlib.sha256).hexdigest()

Keep the clear number only where a person must read it, for example on the rental contract, and only for as long as the law requires.

5. Prepare to verify a leak claim without touching criminal markets. OTS confirmed its leak by matching. Plan how you would do the same: agree with counsel and the police how samples will reach you, compare keyed tokens of identifiers rather than raw values, record chain of custody, and never pay a seller for "proof".

6. Check your own regulatory clock. Under the PPC rules above, the preliminary report is due within 3 to 5 days of discovery and the final report within 30 or 60 days. Write down now who decides that a leak has been discovered, because every deadline counts from that date.

What changed since first reports

• From "possible" to "confirmed". The 21 October notice said a leak was possible. The 23 October report says it was confirmed by matching.
• From no count to "up to about 730,000". The first notice gave no count. RBC reported on 22 October that OTS had not yet determined how many customers were affected.
• Licence images entered the story through the press. NHK's 22 October headline came before OTS's own mention of its image store.
• Police were added. The first notice mentions the PPC. The second adds the police.
• A possible earlier date emerged. The May sale post described by Ryukyu Shimpo is the first public hint of an earlier timeline. It is unverified.

Open questions

• When was the external inquiry received, and when did the intrusion begin?
• Did the data leave through the booking website itself, a back office system, a supplier or a cloud store?
• Which of the five services' customers are in the up to about 730,000, and how many are overseas visitors?
• Did any of the up to 6,000 licence images leave the separate database?
• Will OTS send individual notices, and will it publish a dedicated lookup or phone line?
• Does the Digital DMO Platform hold data on behalf of other organisations, and if so, have they been told?

What would have helped

None of this judges OTS, which blocked access, suspended bookings, reported to the PPC and the police, and kept its licence images in a separate store. The question for everyone else is how to make the same class of event smaller, and how to hear about it from your own systems first.

Practices any team can use

• Keep licence data only as long as the contract needs it. A rental contract needs a licence check at pickup. Very few businesses need the number years later. Set a retention period per field and make the database enforce it.
• Separate ID images from everything else. OTS did this, and it is the reason the image question is still open rather than answered. Use separate credentials, separate network paths and separate logging for the image store.
• Tokenise identifiers you only need to match. A keyed hash of a licence number answers "have we seen this person" without keeping the number.
• Think twice about social login IDs. A Facebook ID ties a booking record to a public profile. If you use social login, store the minimum the provider requires and consider whether you need it at all after sign in.
• Watch for your own data outside. OTS learned of the problem from an outside inquiry, and the press reports a sale post months earlier. Monitoring for your domains and brand names in leak sites, paste sites and criminal forums, by your own team or a provider, is how you shorten that gap.
• Log access to the customer database, not only to the website. Bulk reads of customer tables, unusual export jobs and access from unexpected networks are the signals that tell you data is leaving.
• Inventory what the booking platform is built from. Booking engines, payment plugins, content management systems, frameworks and container base images are where many breaches start. Know the versions in every internet facing service and rebuild quickly when a fix ships.
• Write the customer message early, in every language your customers use. OTS's list of what it will never ask for is a good template.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Gold Open Source (gold.safeguard.sh) gives free CVE intelligence with affected and fixed versions.

The limits are plain here. OTS has not said what the weakness was or where it sat, and no CVE has been linked to this incident. Safeguard has no advisory for it and no patched build related to it. These capabilities help in the shared layer of frameworks, libraries and base images that booking platforms are built from, where pulling patched, signed components and rebuilding fast removes one common way in. They do nothing about how long licence numbers are kept or whether a social login ID is stored, which are the lessons that matter most in this case.

Where Safeguard fits

Safeguard would not have prevented this incident, and it would not have changed what OTS collected or how long it kept it. What it covers, at GA:

• Dependency and image scanning of the repositories, container images and SBOM files behind a booking platform, with JSON results under ./output.
• Component search across projects, showing every project that contains a given component and version when an advisory lands.
• Vulnerability matching and reachability analysis, ranking the vulnerable code paths your application actually calls.
• Policies and gates, so a build carrying a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, off by default.
• The Safeguard CLI assistant, which can edit code and run commands and asks before any command that changes something, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to add a retention job for licence numbers, or to replace a clear text column with a keyed token, and review each change before it lands.

safeguard scan --dir .                 # a repository
safeguard scan --image <name>          # a container image
safeguard scan --sbom <file>           # an SBOM file

Where Safeguard does not help: it does not monitor dark web markets, watch database access, detect data leaving a network, manage retention schedules or see inside a supplier's hosted booking service.

Common mistakes and troubleshooting

• Reading the ceilings as counts. "Up to about 730,000" is an upper bound, and "up to 6,000" is the size of an image store whose leak is unconfirmed.
• Treating the press figures as company figures. The 600,000 and 4,000 numbers are claims in criminal listings, reported second hand.
• Assuming a reissue fixes a leaked number. As reported, a reissue changes only the last digit. Your other data is unchanged.
• Clicking a "compensation" or "refund" link. OTS has announced no compensation process. Any message offering one should be checked against OTS's own site first.
• Hashing licence numbers with plain SHA-256. The search space is small enough to brute force. Use a keyed hash.
• Keeping ID images in the same database as bookings. If one set of credentials reaches both, an attacker who gets the booking data gets the images too.

FAQ

What happened at Okinawa Tourist (OTS)?

After an inquiry from outside the company, OTS found that customer personal information may have leaked. It blocked external access to the affected website on 18 October 2026, suspended new bookings for five services at 16:30 on 20 October, and said on 23 October that it had confirmed the leak by matching leaked data with its own records.

How many people are affected?

OTS says up to about 730,000 customers. That is a ceiling. Press reports cite about 600,000 records in a sale listing, a figure OTS has not used.

What data was exposed?

Name, date of birth, gender, address, phone number, email address, Facebook ID, the issue and expiry dates of a Japanese driver's licence and the licence number. The licence fields concern Japanese licences only.

Were driver's licence images leaked?

Not confirmed. OTS says up to 6,000 images of Japanese licences are stored in a separate database and that it is still investigating whether they leaked. NHK's headline about a sale listing cited about 4,000 images, a figure OTS has not confirmed.

Were credit cards affected?

According to OTS, the system where the leak was confirmed did not hold credit card information, and no card leak has been found.

When did the breach happen and how did the attackers get in?

OTS has not said. Neither notice gives an intrusion date or a cause. Ryukyu Shimpo reports that a security vendor saw a dark web sale post about OTS related data in May 2026; the vendor did not verify the data and OTS has not commented on the timing.

Is the data really for sale on the dark web?

Several outlets reported sale listings on 22 and 23 October, and OTS's 23 October report confirmed a match between data said to have leaked and its own records. Okinawa Times' 24 October headline says the data matches the sale listings.

I rented a car from OTS. What should I do?

Expect impersonation attempts. Do not click links in unexpected messages and never give passwords or card numbers; OTS says it will not ask for them. Contact OTS only through the published addresses, secure any Facebook account you used, and consider a self declaration with the credit bureaus.

Should I get my driver's licence reissued?

No reissue route for OTS customers had been announced as of 25 October. After the Times Car breach some prefectural police offered one, while warning that a reissue does not remove the risk of misuse. As reported, a reissue changes only the last digit of the number.

Is this linked to the other Japanese breaches this autumn?

OTS has not linked it to any other incident. It falls in the same weeks as the Times Car breach, the Lawson ID breach, the BOOKOFF breach and the others in our Japan breach wave roundup, but that is timing only.

Would Safeguard have prevented this?

No. The lessons here are about retention, ID data handling and early detection, which Safeguard does not manage. Safeguard helps with one shared layer: finding and fixing known vulnerable components in the services you build, and making changes with an assistant that asks before any command that changes something.

OTS has not named the weakness behind this leak, so nobody can say whether a package fix was involved. For the parts of a booking platform that teams do build from open source, this is the general playbook.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows OTS or its systems. Each is a real Safeguard session, applied here to a team running a rental or booking platform.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. For a booking service, you would run /scan . in the reservation API's repository, then ask the assistant to add a scheduled job that clears licence numbers a set time after the rental ends, with a test that fails if an old record keeps one.

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

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on commands and file edits, ending with an upgrade done and tests passing. A team could pick the folder holding its booking site, ask for the web framework to move to the fixed release for its line after an advisory, and approve or deny every change before it lands.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If an advisory lands at night for a library your reservation API uses, the on call engineer could approve the dependency bump and test run from a phone, and deny anything that touches the customer database until a second person has looked.

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

To try it on your own services, download Safeguard and follow the CLI docs. For the wider month, read October 2026 security incidents and what would have helped.

Quick check

Sources

• Okinawa Tourist Service: Notice regarding potential leakage of customers' personal information and temporary suspension of services (21 Oct 2026, JP and EN)
• Okinawa Tourist Service: Notice regarding the status of investigation into the leakage of customers' personal information, second report (23 Oct 2026, JP and EN)
• OTS Rent-a-Car: Service suspension page (fetched 25 Oct 2026)
• Personal Information Protection Commission: Breach reporting (漏えい等報告について)
• Personal Information Protection Commission: Personal Information Protection Act consultation dial
• e-Gov: Act on the Protection of Personal Information (Article 26)
• e-Gov: Enforcement Order of the Act on the Protection of Personal Information (Article 1)
• Japanese Bankers Association, personal credit information centre: Self declaration (本人申告)
• Shizuoka Prefectural Police: Notice for people whose licence images leaked in the Times Car website breach
• Hokkaido Shimbun: About 70 licence reissues in Hokkaido after the Times Car breach; misuse risk remains (9 Oct 2026)
• NHK: Licence images possibly leaked from an Okinawa rental car company on sale on dark web sites (22 Oct 2026)
• RBC Ryukyu Broadcasting via Yahoo News Japan: OTS customer information possibly sold on a dark web site (22 Oct 2026)
• Ryukyu Shimpo via dmenu news: Leaked OTS customer data possibly sold on a dark web site, licence images included (23 Oct 2026)
• Okinawa Times: 600,000 records on sale on a dark web site (23 Oct 2026)
• Okinawa Times: Up to 730,000 people's personal information leaked at Okinawa Tourist (23 Oct 2026)
• Okinawa Times: Leaked data matches dark web sale listings (24 Oct 2026)
• Ryukyu Shimpo: OTS leak up to 730,000, match with held data confirmed (24 Oct 2026)
• Nikkei: Okinawa Tourist leaks personal information on up to 730,000 people (24 Oct 2026)
• Kuruma News: What the 12 digit driver's licence number means (14 Jul 2024)

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