A Police Cloud Data Breach, and a Roster That Stays Home

A police cloud data breach reported on October 21, 2026, may have exposed personal information for about 125,000 police officers and staff across 20 Japanese prefectures. The system was a safety check: are you safe, and can you report for duty. It had been outsourced to Arcadia, a cloud provider in Minoh, Osaka. Most of the email addresses are believed to be personal accounts on private phones. A second set of systems, crime alerts to residents and businesses, may have exposed more than 18,000 further addresses. This page is about that outsourcing, and about where a device identity lives in this house.

The report this page follows is The Japan Times. The identity model the device uses is the one in MATA's freedom guide. The code that mints the key is the Janus work at Remade With Rust.

What the police cloud data breach put at risk

Sources at the National Police Agency told reporters that names and email addresses on the safety-check system might have been taken. Departments including Aichi, Hyogo, and Hiroshima were among the twenty. Some, including Tochigi and Saitama, had also registered the office a person worked in. Four departments, including Shimane and Yamaguchi, had outsourced crime-alert lists as well: about 16,000 people and more than 2,600 organizations. Kyoto and Fukuoka used both. No case of the data being used for fraud had been confirmed. The agency told the departments to warn people and to arrange some other way to reach staff in an emergency. Other local governments and fire departments that used the same provider are an open question in the same reports.

The roster lived at the vendor

The police cloud data breach is not a story about a clever bug in a radio. It is a story about a list of people, stored so a vendor's system could email them when something went wrong. Once the list is at the provider, a break-in at the provider is a break-in at the list. The departments did not each hold a private copy as the system of record. Arcadia did. That is the design the October 21 notes describe. They do not describe the attacker's method, and this page does not supply one.

What "might have been" means

The police cloud data breach is still phrased as potential exposure. The agency did not, in the note this page is using, publish a stolen-record count beyond the size of the systems, and it did not confirm misuse. A page that turned "might" into "was sold" would be ahead of the sources. The harm that is already real is the one the agency acted on: people should assume a personal inbox tied to their job may now be in someone else's hands, and the emergency contact path has to have a backup that is not that vendor.

A device key is not a staff list

rusty_esp_mid generates a P-256 key on the board at first boot, from the hardware random generator, and derives a did:mata from it. The owner signs an adoption record. The device pins that owner and refuses a stranger, including a stranger replaying the owner's own record. That record is the device, the owner, and the capabilities granted. It is not 125,000 personal email addresses, and it is not a duty roster for a prefecture. Remade With Rust is the house that writes that firmware. Rust is how the checker is built. The police cloud data breach would not have been stopped by a compiler. It would have been stopped by not placing the roster at the vendor.

What this website stores

Sign-in on dldeploy.com is sign in with MATA. The wallet signs a nonce. The server checks it. The session is a bearer key, and the server keeps a hash, not the key. There is no safety-check table of employees. The website itself is static files on a host. Hosting is not the same claim as "a cloud vendor cannot be breached." Fly can have an incident. The application data for this sign-in is the hash and the device history the portal keeps, not a copy of a workforce's private inboxes. The police cloud data breach is large because the vendor's product was the inbox list.

The key is not in a vault yet

Current development firmware runs with flash encryption off and can keep the identity in a plaintext partition, behind a loudly named dev feature. The wrap under an eFuse-held key, and a secure element that never releases the key, are planned and not shipped. A police cloud data breach comparison that skipped that sentence would be advertising a hardware vault the board does not have. The identifier is still born on the device. The partition it sits in, today, is not the end state.

The home computer keeps the household's devices

Home on MATA is the computer in the house, not a prefecture-wide safety check. A Janus device joins it on the LAN through the seam in the MATA Home integration. A pure Rust alternative to a vendor account is the refusal to let a company account be the owner. The Learn index lists what has been measured.

Adoption is one owner

The police cloud data breach scaled because one provider held many departments' lists. Adoption here pins one owner to one device. A second household does not inherit the first household's key by being a customer of the same website. Smart home access on your home computer is that boundary for the cameras and sensors: access is the home computer, not a vendor login that can enumerate a workforce.

The line this page will not cross

The police cloud data breach is a vendor-held roster of personal emails, possibly taken, not yet tied to fraud in the agency's account. This house does not operate that roster. A did:mata is a device key, adopted locally, with the dev-firmware partition still in the open. That is the protection, and it is the limit. People whose addresses were in the Arcadia systems should follow their department's warning. Nothing on this site is a substitute for that notice.