A promise that turned out to be a policy, not a fact
Keystone, a maker of cryptocurrency hardware wallets, told customers on January 5, and repeated the claim in March and again in August, that shipping data from their orders is permanently deleted 180 days after purchase. That claim is exactly the kind of specific, repeated commitment a customer would reasonably use to decide how much personal information to hand over when buying a device meant to secure their most sensitive financial assets.
On October 20, Keystone detected unauthorized access to its online store, which runs on Shopify, and confirmed the breach on October 23. The exposed data included customer names, contact details, shipping addresses, and order specifics such as items purchased and prices. Some of that data belonged to orders well outside any 180-day window, which means the deletion promise and the operational reality of the store had drifted apart long before an attacker ever found the gap.
What stayed protected and why that distinction matters
Keystone has been clear that payment information, wallet recovery phrases, private keys, and wallet passwords were not part of the exposure, and there is no indication the attacker gained the kind of access that would let them drain a customer's crypto holdings directly. For a hardware wallet company, that is the one failure mode that would have been catastrophic for every affected customer's actual holdings, and avoiding it is a genuine point in Keystone's favor, one that separates this incident from the breaches that end in direct financial theft rather than downstream fraud risk.
The distinction matters for the reader's own posture, too, because it shows how a breach can be contained in its most dangerous dimension while still causing real harm in a quieter one. Shipping addresses and purchase histories cannot move a single dollar of anyone's funds, yet they are precisely what an attacker needs to build a highly credible pretext, and the data most exposed here is exactly the kind that most retention policies treat as low-sensitivity and therefore low-priority to actually delete on schedule. A security team that ranks data sensitivity purely by financial reach will keep underprotecting the shipping and order records that turn out to be the most useful input for a convincing phone call.
The social-engineering follow-through arrived within a day
By the evening after disclosure, a customer reported receiving a call that spoofed a police department's phone number and referenced a real Keystone order from 2024. That is the exploitation path this kind of exposure enables: a caller who can cite your actual purchase history, your actual address, and your actual order date sounds credible in a way generic phishing never does, and credibility is the entire mechanism behind a social-engineering attack against someone who owns a hardware wallet specifically because they do not trust software-based custody.
Keystone responded by warning customers directly never to enter a recovery phrase into any device they did not personally order, which is the right advice and also an admission that the company expects scammers to keep using this data for exactly that purpose. The gap between detection on October 20 and disclosure on October 23 is also worth noting: three days is a reasonable turnaround for confirming scope, but it is also three days during which affected customers had no idea their information was already circulating.
Shopify, and the vendor-of-a-vendor problem
Keystone says it verified API activity with Shopify as part of confirming the breach, but the company has not said whether Shopify was the entry point or whether the vulnerability sat somewhere else in its own storefront configuration. That ambiguity is itself instructive: when a breach happens on a platform run by a major e-commerce vendor, the brand customers associate with the failure is the retailer they bought from, not the infrastructure provider underneath it, regardless of where the actual fault lies.
Any PE-backed retail or commerce-tech company running on a major platform inherits this exact exposure. Your customers will hold your brand accountable for a breach even when the root cause traces back to a shared platform you do not control end to end, and your contract with that platform needs to specify data-retention enforcement, not just data-processing terms, if you want your own public privacy claims to hold up under the same kind of scrutiny Keystone is now facing.
The gap between a privacy policy and a help-center page
Keystone's formal privacy policy, last updated in May 2021, describes its data retention rules differently from the 180-day deletion promise repeated on social media, and the company's own help center separately states that city and country records are not deleted even when other shipping data is. Three different documents, three different versions of the same supposed policy, is not a communications slip. It is a sign that no single team owned the retention rule end to end and verified it against what the platform actually executes.
That pattern is common enough to be worth a direct audit at any company that makes a public retention promise. The question to ask internally should focus less on whether the policy document says the right thing and more on whether someone has actually queried the production database or the e-commerce platform's data store to confirm that records older than the stated window are truly gone, rather than merely hidden from the admin interface customers and employees normally see.
The due-diligence question this adds to every vendor review
For CTOs and CISOs running vendor risk assessments, this incident upgrades a question that usually gets a soft answer into one that needs a hard one: when a vendor claims data is deleted after a set period, what is the actual mechanism, who verifies it runs, and how often. A SOC 2 report attests to controls existing, not to whether a specific retention promise made in a tweet or a help-center article matches what the database schema enforces.
The practical takeaway for the next board update or vendor audit cycle is to stop accepting a stated retention policy as evidence of an enforced one, and to start asking any vendor handling customer PII, especially one built on a third-party commerce platform, to show the deletion job actually running against real data. Keystone's customers believed a specific, repeated promise, and the company's own storefront proved that promise was aspirational rather than operational.
