Keystone says a website breach exposed its device authentication key, and it will destroy 18,835 unsold wallets

Six days, one key and 18,835 unsold wallets

Keystone says it detected unauthorized access to its website on Tuesday 20 October 2026. It told the public that a key used to verify its devices had been taken on Monday 26 October. That is six days (derived). By Keystone's own account, devices carrying the compromised key were delivered to customers after 20 October. The company says it will destroy 18,835 devices that it had not sold, and it says that devices delivered before 20 October remain safe to use if they pass its online authentication.

The headline version of this story, that thousands of owners will see their wallets destroyed, is not what the record says. Every report read places the 18,835 in Keystone's own inventory, and most call them unsold. Keystone is reported to have said it will not ask owners to return their devices. What the record does show is a different and, for owners, more awkward fact: for any unit delivered after 20 October, Keystone says a pass on its own authentication check no longer rules out a counterfeit. It has not said how many such units exist or what its extra verification involves.

Keystone's statement was posted on X by its account on Monday 26 October. X's robots.txt tells automated clients not to fetch pages, so the statement was not opened directly. It is read here through seven outlets that quote or paraphrase it: CoinDesk, Gizmodo, Blockhead, Parameter, FinanceFeeds and Bitcoin.com and crypto.news. They agree on the counts used below, and differ on one date, noted later. What was read directly is Keystone's own website: its device verification page, its About page, its firmware page and a 2025 archived copy of its blog post on how the check works. All of it was read between 14:13 and 14:26 UTC on Tuesday 27 October 2026. Keystone sells the devices and wrote the statement, so its reasons for the destruction, and its reassurance for earlier buyers, are its own account.

This is a separate matter from the Ledger reseller case covered in this site's briefing on one implanted device and loss estimates. That case involved hardware tampered with in a reseller channel. Here a manufacturer says the means of telling genuine from counterfeit was stolen, and says nothing about whether any counterfeit exists.

What Keystone states, and what it does not

The table sets Keystone's statement, as the outlets report it, against what none of the seven reports gives. "Not stated" means not found in any of them. It does not mean the information does not exist.

What the key is, according to Keystone's own design post

Keystone's website tells owners to check a new device at keyst.one/authentication: scan a QR code from the page with the device, type in the digits the device shows, and wait for a result. Its page says a pass "confirms that your hardware and firmware are genuine and untampered". Keystone's own blog post on the design, read from an Internet Archive capture dated 7 April 2025 (567 days before the 26 October statement, derived), explains the mechanism. Each device has a pair of keys installed in its Secure Element during manufacturing, used only for this check. A hardware security module server behind the page, which Keystone says is an AWS service, holds its own key pair and knows each device's public key. The server makes a random string, encrypts it to the device's key, signs it and shows it as a QR code. The device checks the server's signature, decrypts the string and shows eight digits, which the owner types back.

Zoom

Two things follow, and the first is plain. The check is a proof of origin that depends on keys Keystone holds. If someone holds the same keys, a copy can answer the challenge in the same way, which is what Keystone says it fears. The second is a gap. The 2025 post said that spoofing the check would need both the server and the device's Secure Element to be compromised, and called that extremely improbable. Keystone's October statement says a flaw in a monitoring tool on the website led to the key. How those two statements fit is not explained in anything read. It is possible that the key taken is not one of the pair the post describes, or that the design has changed since April 2025 (inference). Keystone has not said, and a reader cannot tell which.

Keystone also says the key cannot be erased or rewritten once installed, which is why, by its account, the unsold units cannot be saved. That is a design fact worth taking at face value and testing: a verification key that cannot be rotated in the field is a single point of failure for every unit that carries it. Whether all units carry the same key or each carries its own is the question that decides how far the loss reaches, and it is the one the reports leave open.

The friendly names: guarantee, air gapped, secure element

The page that offers the check is headed "Device Verification Guarantee". Its list of benefits includes protection "against any Supply Chain Attack". Read at 14:19 UTC on 27 October 2026, one day after Keystone's statement that a pass can no longer be relied on for some devices, the page carries no notice of that. Its FAQ, in the same read, still says passing the check confirms that the hardware and firmware are genuine and untampered. Keystone's statement, as reported, limits that claim to devices delivered before 20 October.

Zoom

Three labels do the work of controls here. Guarantee is a word for a promise, and on this page it describes a check that one party can now pass without the product. Air gapped is how Keystone describes its design, and it is a real property: an air gapped device does not use a network connection to sign, so the seed is not exposed to online attack. It says nothing about whether the box was made by the maker, and the authenticity check an owner is told to use is a website. Secure element is a chip that protects keys inside it. It does not protect a copy of a key held anywhere else, and which copy was taken is not stated (inference). Keystone's own wording is better than its labels here: it separates the seed, which the stolen key has no part in, from the authenticity check.

One more label sits on its About page. Among three figures it shows "0" beside "Security Incidents". It was still there when read at 14:18 UTC on 27 October, a week after the intrusion was detected (derived: seven days from 20 October). This is likely a static counter that nobody updated rather than a claim made after the breach (inference), and Keystone has not commented on it. It is shown because a reader checking the company's record would find it.

Zoom

The clock: three days, one day, two days

Keystone's first public post was an apology on Saturday 24 October. It said that on 20 October it detected unauthorized access to its official website, and that after checking API activity with Shopify it confirmed on 23 October that a third party obtained customer shipping information. The post's identifier decodes to about 17:59 UTC on 24 October (derived), and Gizmodo's embed of it shows the same date. Blockhead dates the first disclosure to 25 October. The article follows the post's own date. The fuller statement followed on Monday 26 October at about 14:02 UTC (derived), where the key theft was disclosed.

Zoom

The intervals, all derived: three days from detection to confirmation that data was taken, one more day to the first public post, and two more to the disclosure of the key. That is six days from detection to the key. The statement's own wording matters for the first interval: the reports say Keystone blocked access and disabled sensitive website functions on 20 October, but they do not say when it learned the key had been taken. If it knew on 20 October, the six days are six days in which devices with the old key kept reaching customers. If it learned later, the gap is shorter. Keystone has not said which, and it has not said how many devices went out in that window.

Which device is which, and what an owner is told to do

Zoom

The logic behind the first card, which is this site's inference and not Keystone's words, is that nobody could have held the key before it was taken, so a device delivered before 20 October cannot be a copy made with it. That is sound for devices made and delivered before the theft, provided the delivery chain was sound too. It does not help an owner who bought through a reseller, whose delivery date may be unclear. The reports do not say how reseller stock is treated.

The second card is the hard one. Keystone is reported as saying it cannot completely rule out that such a device is counterfeit even if it passes the online check, and as telling those customers to contact support for additional verification before using it. What that verification is, how long it takes, and what an owner should do in the meantime beyond not using the device, is not stated. Keystone's own page, in its FAQ for a failed check, tells owners to stop, not to enter a seed phrase, to keep a screenshot, and to write to the support address printed on the page.

Keystone has also warned, per the reports, that no message offering asset migration, wallet verification or a recall should be trusted, and that it will never ask owners to return a device under that pretext. That matters because the leaked customer data is exactly the data a scammer needs to make such a message look real.

The customer data: half the records should not have existed

The numbers in Keystone's account add up. Of 51,083 buyer records in its Shopify store, 25,119 had had their personal data erased before the intrusion. 51,083 minus 25,119 is 25,964 (derived), which is the number of records that still held personal data. That is 50.8 per cent of the store's buyer records (derived). Add the 12,873 unpaid checkout records and the total is 38,837 records (derived), which FinanceFeeds also notes is not a count of people.

The records span purchases from 2024 to 2026, against a published promise to delete after 180 days. A purchase made on the last day of 2024 was already 658 days old on 20 October 2026, which is 3.7 times the promised limit (derived). Keystone says an automated deletion tool failed without the company noticing, and in the words CoinDesk quotes, it "failed to fulfill our commitment to erase customer data on time". Blockhead describes the tool as one Keystone built to work around Shopify's manual deletion process. Shopify's deletion of the overdue records was requested on 24 October and, with a ten day wait, is due on 3 November (derived: ten days), so for a further week the data stays where the attacker found it.

Parameter reports users who bought devices more than two years ago receiving breach notices, which would fit those records, and reports one buyer describing a call from someone posing as a law enforcement officer. That is a buyer's account and is not verified. Reports in AMBCrypto and Parameter quote a security researcher warning that shipping addresses expose holders to physical threats, and give figures for physical attacks on crypto holders from other bodies that were not checked here. A leaked postal address cannot be recalled, which makes this the part of the breach that does not end when the key is replaced.

Technical details

Keystone has published no indicators of compromise, no tool name, no vulnerability identifier, no hashes and no domains for this incident, in anything read. What it has published is how the check works, and the instructions an owner is given. They are copied below from Keystone's own pages, with the page and the time read in each caption.

The first block is the three step procedure and the result wording on the verification page. A defender or an owner uses it to know what a pass is claimed to mean. After 26 October that claim holds, by Keystone's own account, only for devices delivered before 20 October.

The verification process is very simple, with three steps: 1) Use your device to scan the QR code on the webpage; 2) Enter the verification code displayed on your device into the verification tool on this page; 3) Wait for the system to return the verification result. If the result shows 'Verification passed,' it means your device is genuine and has not been tampered with; if verification fails, please contact official customer support immediately (support@keyst.one).

The second block is what the page tells an owner to do after a failed check. The page's sentence continues beyond the part copied here to say not to enter a seed phrase. It is the instruction on the page that applies directly to a bad result.

A failed verification may indicate that the device firmware has been tampered with, the device is counterfeit, or there is a supply chain attack risk. If this occurs, immediately stop using the device and do not perform any operations on it

The third block holds two sentences from Keystone's 2025 design post. They state where the check's keys live and what Keystone said an attacker would need. They are the baseline against which the October statement should be tested.

Each Keystone has a pair of public and private keys pre-installed in the Secure Element during manufacturing that is used solely for the purpose of Web Authentication.

Not only would the HSM server have to be hacked, but the device’s Secure Element would also have to have been compromised.

The fourth block is the firmware information Keystone's firmware page shows. It is given because an owner will ask whether a firmware update changes anything. None of the reports read links a firmware release to the incident, and the page does not mention the incident, so this is a version record and nothing more.

Multi-Coin Firmware   version 3.2.0   2026-10-23
Cypherpunk Firmware   version 3.2.0-CYPHERPUNK   2026-10-23
Bitcoin-Only Firmware   version 3.2.0-BTC   2026-10-23

What to do, in the order worth doing

These steps are drawn from Keystone's own advice as reported, its verification page, and the gaps above. Nothing here needs more than the device, the order record and the official support address.

What could not be verified

• Keystone's own statement. It was posted on X by the company's account. X's robots.txt disallows automated fetching, so it was not opened. Its content is taken from seven outlets that agree with each other, and the quoted phrases are as those outlets print them.
• The date of the first post. Blockhead says 25 October. Gizmodo's embed and the post identifier say 24 October. The article uses 24 October. The identifier decoding assumes the standard X time encoding and is labelled derived.
• Which key. Nothing read says which key was taken, whether it is one for all units or one per unit, or how a monitoring tool on a website reached it.
• Counterfeits and losses. No report read describes a counterfeit device found or any theft of funds from this incident.
• Reseller stock and the unfulfilled orders. Whether either is inside the 18,835 is not stated.
• Customer anecdotes and physical attack statistics. Reported by others, not checked.
• Not read. The Hacker News report (it answered with a bot check, so it was skipped) and crowdfundinsider (it blocked the request).
• Time stamped. Pages were read between 14:13 and 14:26 UTC on 27 October 2026. Keystone's pages, its lookup page, its notice to owners and the count of 0 on its About page could change within hours.

The question that exposes the gap

If the check that proves a device is genuine can now be passed by a copy, what evidence does the owner of a device delivered after 20 October have that the one on the desk is the one the factory made, and who has promised to produce it?

Key facts