After COLDCARD, Trezor and SafePal: CLAVI's Case for Data Minimization

Research cutoff: August 19, 2026. Vendor-reported totals are identified as such. This article is educational and is not legal or incident-response advice.

The direct answer: less retained data means less operator-side exposure

Data minimization is a security control because an operator cannot lose a record it never collected. The next-best outcome is to collect only what a defined purpose requires, isolate it from other systems and delete it on a verified schedule. But “zero data” is not a credible promise for an operating company. Shipping, invoices, support, fraud prevention and regulated services can create narrow recordkeeping needs. The defensible goal is zero operator access to vault secrets and minimum necessary retention everywhere else.

August coverage often compressed three distinct security stories into one alarming “hardware-wallet hacks” headline.

• The COLDCARD incident concerned the generation of wallet secrets.
• The Trezor incident concerned unauthorized access at a shipping provider.
• The SafePal disclosure concerned an authorization flaw in an order-tracking component.

What happened in July and August 2026?

Incident	Public disclosure or update	Security plane	Publication-safe account	Confidence
COLDCARD predictable-RNG incident	Advisory published July 30; guidance updated August 14, 2026	Secret generation	Coinkite and Block independently traced the issue to a firmware integration error that allowed a deterministic fallback generator to supply seed-generation randomness.	Confirmed root cause; some version and impact details remain disputed or estimated.
Trezor/ShipMonk exposure	Notice published August 13, 2026	Fulfillment and identity data	Trezor says ShipMonk informed it of unauthorized access affecting approximately 13,689 customer records. Trezor says its devices, keys and backups were not affected.	Vendor-reported scope, corroborated as a disclosure by independent reporting; not an independently audited dataset.
SafePal order-tracking exposure	Disclosure published August 16, 2026	Fulfillment and purchase data	SafePal says an authorization flaw exposed order information for approximately 39,798 customers. It says wallet credentials and payment-card data were not involved.	Vendor-reported and still developing.

COLDCARD: air-gapping cannot compensate for weak entropy

The COLDCARD vulnerability was a failure in creating secrets, not a breach of a customer database. Coinkite’s technical account and Block’s independent code analysis both found that a build or linking error allowed a deterministic MicroPython fallback generator to be used where hardware-generated randomness was intended.

A wallet seed is supposed to be unpredictable. If the possible seed space becomes small enough to search, an attacker can reconstruct candidate keys away from the device. The wallet can be switched off, stored in a safe and never connected to the internet; those protections do not restore randomness that was missing when the secret was created.

This is an important correction to simplistic descriptions of an “air-gap.” Physical and network isolation can sharply reduce remote attack paths, but they do not prove that every component inside the isolated boundary behaves correctly. Entropy generation, firmware integration, reproducible builds, update procedures and independent review remain part of the security model.

The exact Mk2/Mk3 version boundary is itself a useful lesson in evidence handling. Block’s analysis traces the affected path to version 4.0.0. Coinkite’s current advisory starts at 4.0.1. Rather than silently choosing one, users and publishers should acknowledge the discrepancy and treat a seed created under either boundary conservatively.

Coinkite also states that installing corrected firmware does not strengthen a seed already created on affected firmware. The update protects future seed generation; an affected seed still requires careful migration to a newly generated wallet, subject to the vendor’s dice and passphrase caveats. That distinction should appear in any remediation summary.

Galaxy Research’s August 3 on-chain analysis attributed 1,596 BTC across three high-confidence waves and 14 smaller incidents. Use that figure only with attribution. It is not a Coinkite-verified loss total, and this article does not repeat the larger fourth-wave or dollar estimates that remained unconfirmed.

The public record does not identify the attacker or show that artificial intelligence discovered the flaw. A separate phishing campaign exploited concern about COLDCARD, but no reviewed source establishes that it used a leaked Coinkite customer list.

Trezor: minimization appears to have reduced, not eliminated, exposure

Trezor’s August 13 notice concerned fulfillment data held by ShipMonk, not compromised wallet hardware. Trezor says ShipMonk informed it on August 10. That was the notification date, not necessarily the intrusion date.

Trezor’s notice did not name the exploit. BleepingComputer later reported that ShipMonk notification emails it reviewed tied the access to a Metabase vulnerability. Metabase’s primary advisory identifies CVE-2026-72898 as a critical, actively exploited unauthenticated SQL-injection flaw. No public ShipMonk postmortem or independent forensic report was located by the cutoff.

Trezor reported two affected groups:

• 11,742 customers whose names, email addresses, phone numbers and shipping addresses were exposed.
• 1,947 customers whose names, cities and email addresses were exposed without full shipping addresses.

That produces an approximate reported total of 13,689, not “exactly 14,000.” Trezor says most affected records concerned customers who received orders in the United States, United Kingdom, Sweden, Colombia, Brazil, Italy or Portugal between May 10 and August 8, 2026. It separately cautioned that the partial records may include older orders and that the exact period was still being checked with ShipMonk.

According to Trezor, its own systems, hardware wallets, private keys and wallet backups were not affected, and parcel contents were not exposed. Exposed identity and delivery data can increase phishing and targeting risk, but the notice does not establish any physical attack.

Trezor’s published retention table says core completed or cancelled e-shop order and delivery data is generally deleted after 90 days, subject to ongoing-order exceptions. That policy appears to have limited the number of complete shipping addresses available. It did not eliminate the incident, and the older-partial-record caveat prevents anyone from presenting the policy as perfectly executed.

The same table also demonstrates why “Trezor deletes customer data after 90 days” is false. It lists different periods for separate purposes: invoice data for ten years in a separate environment, third-party fiat payment data for up to seven years, certain crypto-payment records for five years after the relationship ends, and closed support tickets anonymized after 120 days. Marketing and referral data follow still other rules.

Real minimization needs category-specific controls enforced across the merchant, warehouse, carrier, support and payment systems, replicas and backups.

SafePal: a wallet can remain intact while its buyers become visible

SafePal’s disclosure describes another commerce-data failure, not a reported compromise of wallet secrets. SafePal says an authorization flaw in an order-tracking plug-in exposed information for approximately 39,798 customers who placed orders between March 2, 2025 and April 11, 2026.

According to SafePal, the exposed fields included names, email addresses, shipping addresses, phone numbers and purchase details. The company says the incident did not involve seed phrases, private keys, wallet passwords, other wallet credentials, bank-account information, payment-card numbers or government identification numbers.

These statements remain vendor-reported. Even so, knowledge that a named person bought a security product can be valuable when its secrets remain protected.

For a hardware provider, the checkout and tracking stack is not “ordinary e-commerce” sitting outside the security perimeter. It can connect a real identity, a delivery location, contact channels and a security-sensitive purchase. Every plug-in and fulfillment partner handling that combination becomes part of the customer’s threat model.

Zero data is not one thing

“Collect no data” is a useful design challenge but an incomplete operating policy. A Personal Vault and the company that manufactures or supports it handle different categories of information.

The strongest target applies to the vault-secret plane: the provider should not receive private keys, recovery material, local AI prompts or other protected contents in the first place. CLAVI’s public documentation describes this as the design objective of its Personal Vault. That is a product-architecture claim about operator access to user secrets, not a claim that CLAVI Switzerland AG has no business records.

Commerce and corporate records require a different discipline:

Data class	Defensible objective	Why “keep nothing” may be incomplete
Vault secrets and protected local content	Keep operator-inaccessible by architecture; never request them through support.	These are the records whose non-collection most directly removes operator-side exposure.
Order and delivery data	Collect the minimum fields required by the chosen carrier; segregate them; expire them after delivery, returns and dispute windows.	A physical product cannot reach a customer without some delivery mechanism unless a privacy-preserving pickup option is used.
Invoices and accounting evidence	Retain information needed to substantiate accounting records, in a separate system.	Swiss law can require ten-year retention of accounting records and accounting vouchers, the annual report and audit report; this does not permit keeping a full CRM profile.
Support records	Prohibit secrets, minimize attachments, separate reshipment addresses and expire or anonymize closed cases.	A live warranty, replacement or dispute can require a limited record.
Marketing data	Make participation optional and keep consent records separate from fulfillment.	An order should not silently become indefinite profiling permission.
Security evidence and legal holds	Preserve a documented, narrowly scoped set when an incident or valid legal duty requires it; review the exception.	Routine deletion can lawfully pause for a specific investigation or preservation duty, but the exception should not become a permanent default.

The principle is not “delete everything regardless of consequence.” It is “make every retained field defend its existence.”

What do GDPR, Swiss law and crypto rules actually require?

The legal landscape supports minimization without prescribing a universal retention schedule. Applicability depends on the company, purpose, service and jurisdiction. This is not legal advice.

Framework	What can safely be said	What it does not mean
GDPR	Article 5 requires personal data to be adequate, relevant and limited to what is necessary, with storage no longer than necessary. Article 25 requires data protection by design and default.	GDPR does not require every company to collect zero data or prescribe a single local-only architecture.
GDPR breach notification	Article 33 requires supervisory-authority notice without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in a risk to natural persons’ rights and freedoms. Article 34 uses a separate high-risk test for notice to people, subject to exceptions.	Not every incident must be announced to everyone within 72 hours.
Swiss FADP	Article 7 requires data protection by design and by default, with defaults limited to processing required for the purpose. Article 24 requires notice “as soon as possible” when a breach is likely to result in high risk.	Swiss law does not use GDPR’s fixed 72-hour formulation.
Swiss accounting law	Article 958f requires accounting records and accounting vouchers, the annual report and audit report to be retained for ten years from financial-year end.	It does not impose ten-year storage on telemetry, marketing profiles, support files or wallet data.
MiCA	An in-scope CASP retains specified service, activity, order and transaction records five years, potentially seven after a timely authority request. CASP status turns on professionally providing a listed MiCA service. Safekeeping or control is specifically relevant to custody; transfer, execution, exchange, advice and other services have separate tests.	Every hardware seller is not automatically a CASP, and MiCA does not require every customer field to be kept.
EU Transfer of Funds Regulation	All in-scope EU-CASP transfers carry information duties. A transfer exceeding €1,000 to or from a client’s self-hosted address triggers an ownership/control assessment. Specified information is retained five years; a Member State may allow or require up to five more only after an AML/CFT necessity-and-proportionality assessment.	€1,000 is not a general Travel Rule threshold. Pure person-to-person transfers with no CASP are excluded.
Swiss CARF implementation	Swiss SIF says the framework cannot be implemented before January 1, 2027, and its legal basis does not apply in 2026. OECD CARF covers reportable-user identity and aggregated relevant transactions for in-scope service providers.	Switzerland did not implement CARF on January 1, 2026, and CARF is not a universal database of every hardware-wallet buyer’s holdings.

MiCA, the Travel Rule, DORA, Swiss AMLA and CARF cannot be applied to CLAVI from labels such as “hardware,” “self-custody” or “non-custodial.” The analysis can change with key access, signing or intervention capability, transfer and exchange services, smart-contract controls, contractual roles and continuing customer relationships. The production feature set requires qualified legal review before a public exclusion is stated.

The European Data Protection Board’s final Guidelines 02/2025 v2.0, adopted 7 July 2026, say linkable wallet addresses and public keys can be personal data; encryption does not necessarily anonymize them. They generally advise against on-chain personal data because immutability complicates deletion, without imposing a categorical ban.

A data-boundary model for CLAVI’s Personal Vault

CLAVI should describe privacy as an inspectable boundary, not an absolute adjective. The canonical CLAVI definition presents the product as a Personal Vault for digital assets, private data and private communications. The useful follow-up is a category-by-category statement of what the operator can access and what the operating company still needs to process.

The public model should answer seven questions for every data class:

1. Purpose: Why does this field exist?
2. Minimum fields: Which attributes are strictly necessary?
3. System: Where is the record stored, and is it separated from other purposes?
4. Access: Which roles and processors can see it?
5. Expiry trigger: Does the clock start at collection, delivery, ticket closure, relationship termination or financial-year end?
6. Deletion evidence: How are production copies, replicas, processor systems and backups covered?
7. Exception: What can pause deletion, who approves it and when is it reviewed?

Read alongside Why CLAVI Isn’t Competing with Ledger, the point is not that one security mechanism defeats every attack. A Personal Vault combines layers: secret generation, signing authority, local processing, physical control, carefully bounded corporate data and a legal environment. Each layer has a different failure mode.

Nine controls that turn minimization into operations

A policy reduces risk only when systems and processors enforce it. For hardware and Personal Vault providers, the practical control set is straightforward to state, even when implementation is difficult.

1. Maintain a field-level purpose register. “Order data” is too vague. Name, street address, phone, email, SKU and tracking ID each need a documented purpose and owner.
2. Separate data by purpose. Fulfillment, accounting, support, marketing and security evidence should not become one searchable customer profile.
3. Make optional fields genuinely optional. A carrier’s local requirement should not become a universal checkout requirement.
4. Use short operational lifetimes. Start expiry from a defined event and document extensions for active returns, warranties or disputes.
5. Verify processor deletion. Contract language should be backed by deletion jobs, reports, sampling or audit rights that cover warehouses, carriers and sub-processors.
6. Design backups for expiry. A record is not meaningfully deleted if it remains routinely restorable and queryable from long-lived backups. Where immediate removal is impractical, restrict restoration and reapply deletion before returned data becomes active.
7. Keep secrets out of support. Staff, forms and automated tools should never request recovery phrases, private keys or vault contents. Sensitive attachments need explicit handling and expiry rules.
8. Reduce the meaning of a parcel. Neutral packaging, generic sender details and lawful locker or pickup options can reduce association, but none should be marketed as guaranteed anonymity.
9. Plan for exceptions without normalizing them. Incident evidence and legal holds need a recorded scope, approval, review date and release process.

Threats, dependencies, logistics and regulation keep changing. The answer is not indefinite collection “just in case,” but a living data map whose purposes, processors and deletion evidence are reviewed as the world evolves.

Frequently asked questions

Was Trezor’s hardware hacked in August 2026?

Trezor says no. Its August 13 notice concerned unauthorized access at ShipMonk, a shipping provider, and exposure of customer fulfillment data. Trezor said its own systems, hardware wallets, private keys and wallet backups were not affected. Trezor’s notice did not name the exploit; BleepingComputer later reported that ShipMonk notification emails tied the access to a Metabase vulnerability, and Metabase identified the actively exploited flaw as CVE-2026-72898.

Was the COLDCARD incident a customer-data breach?

No customer database breach has been established in connection with the COLDCARD vulnerability. The confirmed problem was in seed generation: a firmware integration error allowed a deterministic fallback generator to supply randomness. A separate phishing campaign later exploited public anxiety about the incident, but public evidence does not show that it used a leaked Coinkite customer list.

What information did Trezor and SafePal report as exposed?

Trezor reported names, emails, phone numbers and shipping addresses for 11,742 customers, plus names, cities and emails for 1,947 more. SafePal reported names, emails, phone numbers, shipping addresses and purchase details for approximately 39,798 customers. These are company-reported figures, not independently audited totals, and neither company reported exposed wallet secrets in these notices.

Does GDPR require a hardware-wallet company to collect no data?

No. Where GDPR applies, it requires personal data to be adequate, relevant and limited to what is necessary for a defined purpose, and kept no longer than necessary. It also requires data protection by design and by default. That supports minimization, segregation and deletion schedules, but it does not create a universal zero-collection rule.

Does self-custody automatically exempt a provider from financial regulation?

No. Regulatory status follows what a provider actually does, including key control, signing or intervention powers, transfer or exchange services, smart-contract roles and continuing customer relationships. A hardware sale alone does not settle the analysis. CLAVI’s production feature set and contractual role therefore require jurisdiction-specific legal review before any MiCA, Travel Rule, AMLA, DORA or CARF exclusion is claimed.

What should zero knowledge mean for a Personal Vault?

For a Personal Vault, zero knowledge should describe a precise technical boundary: the operator should not receive or be able to recover the user’s vault secrets. It should not be used to suggest that an operating company has no order, invoice, support or compliance records. Those business records need separate purposes, access controls and retention schedules.

Why must deletion be verified across logistics and other processors?

A controller’s deletion policy cannot reduce exposure if copies remain active at a warehouse, carrier, payment processor, support platform, backup provider or marketing service. Contracts are necessary, but the stronger control is verifiable deletion across production systems, replicas and backups, with documented exceptions for unresolved orders or lawful preservation.

The durable position: no vault secrets, less business data, more evidence

The safest customer record is the one that never enters the operator’s systems. That principle should be applied most strongly to private keys, recovery material and protected vault content. For the narrower information an operating company must process, the standard is different but still demanding: collect less, separate purposes, expire records, verify downstream deletion and document the exception.

COLDCARD shows why privacy cannot replace sound cryptographic implementation. Trezor and SafePal show how commerce systems can expose people while wallet hardware remains outside the reported incident. A more honest definition of Personal Vault security must protect the secret, protect the person and identify the data that exists between them.