In June 2026, Ledger’s in-house security team, Donjon, published a laser fault injection attack against the TROPIC01 chip inside every Trezor Safe 7, one of the more closely watched disclosures in cryptocurrency security this year. Trezor and chipmaker Tropic Square confirmed the flaw the same week and said no funds were at risk, but the disclosure still landed as a wake-up call: a chip marketed as “the world’s only independently auditable secure element” had a silicon-level hole that no firmware update could close. If you own a Safe 7, or you’re deciding whether to buy one, this tutorial walks through exactly what changed, what didn’t, and the 12 concrete steps to lock your setup down properly.
This isn’t a generic hardware wallet security checklist. It’s built specifically around the Safe 7’s triple-chip design, the attack Ledger Donjon actually demonstrated, and the command-line tools (trezorctl, udev, a Python audit script) you can use today to verify your device is behaving the way it should. By the end you’ll have a working firmware-audit script, a hardened backup scheme, and a clear-eyed view of what the TROPIC01 disclosure does and doesn’t mean for your coins.
Why the TROPIC01 Disclosure Changes How You Should Treat a Safe 7
Trezor launched the Safe 7 in October 2025, marketing it as its most secure device yet, calling it “the first quantum-ready hardware wallet” built around a next-generation secure element chip. The pitch was a three-chip architecture: no single component holds enough secret material to compromise a wallet on its own. Eight months later, that pitch got its first real stress test.
Ledger’s Donjon team disclosed on June 3, 2026 that it had used a lab-grade laser fault injection technique, precisely timed 1064nm infrared pulses, to bypass the firmware verification system inside TROPIC01. According to Ledger’s writeup, Donjon informed Tropic Square of the flaw in January 2026, giving the company roughly five months to coordinate a response before going public. Trezor’s own blog post responding to the disclosure was direct: “The vulnerability concerns only the TROPIC01 Secure Element chip, one of three physical, independent security layers.” That framing matters, and it’s the starting point for everything in this guide.
The practical stakes: this is not a remote exploit. An attacker needs your physical device, a decapping setup, and laser fault injection equipment that costs tens of thousands of dollars and lives in an electronics lab, not a coffee shop. But “not remote” is not the same as “not real,” especially if you’re holding meaningful value, traveling with a device, or storing a wallet somewhere you don’t fully control. This tutorial treats the disclosure as a forcing function to actually audit and harden a Safe 7 setup rather than as a reason to panic.
It also matters because of timing. The disclosure landed in the middle of a broader industry conversation about post-quantum migration for Bitcoin, and Trezor had already positioned the Safe 7 as its answer to that longer-term threat. A silicon flaw in the very chip meant to carry that “quantum-ready” branding is an awkward coincidence, even though the two issues (physical fault injection today versus a theoretical quantum computer years out) are unrelated in mechanism. This guide covers both: hardening what you can control right now, and setting realistic expectations about what quantum-readiness actually means for a device you already own.
Inside the TROPIC01 Disclosure: What Ledger Donjon Actually Found
TROPIC01 is developed by Tropic Square, a SatoshiLabs company, and marketed as the industry’s only independently auditable secure element, meaning its design (unlike most secure elements) is open enough for outside researchers to actually study it. That openness is exactly how Ledger Donjon found the flaw: by examining the chip’s firmware verification path and testing whether physical fault injection could force it to accept unsigned code.
Per Ledger’s published research and Trezor’s own account, the attack works roughly like this: an attacker decaps the chip, positions it under a precision laser rig, and fires a timed 1064nm infrared pulse during the firmware boot-verification sequence. That fault can corrupt the verification logic long enough to let unsigned or attacker-controlled firmware load onto TROPIC01. From there, an attacker with sustained physical access could potentially manipulate values TROPIC01 is responsible for, including parts of PIN handling and device authenticity checks.
Two things keep this from being a fund-draining catastrophe. First, TROPIC01 doesn’t independently hold your seed or private keys, those are split across the chip architecture rather than sitting in one place. Second, the Safe 7’s second secure element, an EAL6+-certified Infineon OPTIGA Trust M, and its hardened STM32U5 microcontroller still have to be defeated too. Trezor and Tropic Square have said publicly that remediation is underway. Multiple outlets have reported a hardware revision is expected later in 2026, though neither company has published a confirmed date, and as of this writing there is no publicly assigned CVE identifier tied to the disclosure. Treat any specific “fixed in” date you see elsewhere as unconfirmed until Tropic Square posts one directly.
Laying the sequence out helps explain why this disclosure was handled about as well as a hardware flaw can be, from a coordinated-disclosure standpoint:
| Date | Event |
|---|---|
| January 2026 | Ledger Donjon privately informs Tropic Square of the TROPIC01 firmware-verification flaw |
| January-May 2026 | Tropic Square and Trezor investigate, per Ledger’s account, engaging in “substantive technical discussion” and moving toward a remediation plan |
| June 3, 2026 | Public disclosure: Ledger Donjon publishes the laser fault injection research, and Trezor posts its response confirming no known fund impact |
| Mid-to-late 2026 | Tropic Square remediation work continues, with a revised chip reported by multiple outlets but not confirmed to a shipping date |
| September 2026 | No CVE identifier has been publicly assigned, and Safe 7 remains on sale with the original TROPIC01 chip |
Notice what’s absent from that timeline: any report of funds actually being stolen through this vector. That’s the difference between a disclosed vulnerability and an active exploit, and it’s why the response here is “harden your setup,” not “panic-sell your hardware wallet.”
Trezor’s Three-Layer Security Architecture, Explained
Understanding what actually protects your coins on a Safe 7 makes every step below easier to follow. The device relies on three independent hardware components sourced from three separate vendors:
| Layer | Component | Vendor | Primary Role |
|---|---|---|---|
| Layer 1 | TROPIC01 | Tropic Square | Auditable secure element handling PIN processing, device authenticity checks, secret storage |
| Layer 2 | OPTIGA Trust M (V3) | Infineon | EAL6+ certified secure element that enforces attempt limits and protects its own secrets |
| Layer 3 | STM32U5G MCU | STMicroelectronics | Hardened ARM Cortex-M33 (160MHz) coordinator that does not hold all secret material alone |
The design intent is straightforward: no single vendor’s silicon is a single point of failure. Tropic Square has put it plainly: “An attacker would need to compromise all three independent layers to reach it,” referring to the wallet’s actual key material. The June disclosure demonstrated a real break of Layer 1 alone. That’s serious research, and it’s exactly why Trezor’s “no impact to your funds” statement is a claim about the architecture holding under partial compromise, not a claim that TROPIC01 is flawless. The steps below help you make sure the other layers, and your own operational habits, are pulling their full weight.
It’s worth understanding what EAL6+ actually means, since it does a lot of work in Trezor’s messaging. Evaluation Assurance Level 6+ is a Common Criteria security certification tier used for chips that need to resist “high attack potential” adversaries, the same category laser fault injection falls under. An EAL6+ rating on the Infineon OPTIGA Trust M means that chip specifically has been independently tested against physical attacks similar in spirit to what Ledger Donjon demonstrated against TROPIC01. TROPIC01 itself doesn’t carry that same certification. Its selling point is auditability (researchers can study the design) rather than a formal EAL rating. Those are two different kinds of trust, and the June 2026 disclosure is a reminder that “auditable” and “already audited into submission” aren’t the same thing. A chip being open to scrutiny is precisely what let outside researchers find the flaw in the first place, which is arguably the system working as intended, just not painlessly.
This isn’t the first time a hardware wallet vendor has had to manage a public disclosure like this, and it won’t be the last. Coldcard’s own entropy flaw, SafePal, and Trezor’s own earlier Safe 3 have all had security researchers or attackers surface real flaws over the past two years. The pattern that separates a manageable disclosure from a catastrophic one is almost always the same: does the flaw require physical possession, and does the architecture contain the blast radius to one component. TROPIC01 checks both boxes so far. That’s genuinely good news, but it only stays good news if owners actually take the steps below rather than assuming “no funds at risk” means “no action needed.”
Prerequisites: Tools, Versions, and Skills You Need
Before starting, gather the following. None of this requires advanced technical skill, but you should be comfortable with a terminal for the CLI-based steps.
- A Trezor Safe 7 device (this guide is Safe 7-specific, since Safe 5 and Safe 3 use a different chip mix)
- Trezor Suite desktop app, downloaded only from trezor.io/trezor-suite, never a third-party mirror
- A computer running Linux, macOS, or Windows with a free USB-C port
- Python 3.9 or newer, if you want to install trezorctl and run the audit script in Step 4 and Step 10
- A second signing device (any brand) if you plan to set up multisig in Step 8
- A fireproof/waterproof metal backup plate, or at minimum an offline paper method, for seed and Shamir share storage
- 30-90 minutes of uninterrupted time. Do not rush the backup and verification steps
One note on versions: Trezor Suite and trezorctl ship frequent point releases, and hard-coding a specific version number here would be stale within weeks. Every step below shows you how to check your installed version directly rather than asking you to trust a number printed in an article.
You do not need to be a security researcher to complete this guide. Every command below is copy-pasteable, and every step explains what you’re checking for and why, not just what to type. If you only have 15 minutes, prioritize Steps 1, 2, 5, and 6 (device confirmation, firmware update, PIN, and passphrase). Those alone address the highest-probability risks. The remaining steps, multisig, udev hardening, and the audit script, are where you go if you’re protecting meaningful value or want a repeatable process rather than a one-time fix.
Step 1-2: Confirm Your Device and Update Trezor Suite
Step 1: Confirm your device model and current firmware
Plug your device in and open Trezor Suite. Under device settings, confirm the model reads “Trezor Safe 7,” not Safe 5 or Safe 3, since the TROPIC01 chip is unique to the Safe 7 line. Note your current firmware version as displayed in Suite. You’ll compare it against the latest release in the next step.
Step 2: Update Trezor Suite to the latest release
Open Trezor Suite’s About/Settings panel and check for updates, or re-download the installer directly from trezor.io. Suite will prompt you to install any pending firmware update once connected. Always perform firmware updates through Suite itself, never through a third-party tool, and always verify the device’s on-screen fingerprint matches what Suite displays before confirming an install. If Suite ever shows a firmware update prompt on first connection to an unfamiliar computer, disconnect and verify you’re on the official site before proceeding, phishing sites have cloned Suite’s update flow before.
Step 3-4: Install trezorctl and Audit Firmware From the CLI
Step 3: Install trezorctl for command-line verification
trezorctl is Trezor’s official Python command-line tool and ships as part of the python-trezor project. Installing it gives you a scriptable way to check device state without relying purely on the GUI.
pip install --user trezor
trezorctl --version
trezorctl listThe trezorctl list command should show your connected Safe 7 with its USB path. If nothing appears, jump to the Troubleshooting section below before continuing, this is the most common stopping point on Linux due to missing udev permissions, which Step 9 covers.
Step 4: Audit device features and firmware from the CLI
Run the features command to pull a structured JSON dump of your device’s reported state, including firmware version, model, and bootloader mode:
trezorctl get-featuresA healthy response looks roughly like this (fields trimmed for readability):
{
"vendor": "trezor.io",
"model": "Safe 7",
"major_version": 2,
"minor_version": "current",
"patch_version": "current",
"bootloader_mode": false,
"pin_protection": true,
"passphrase_protection": false,
"initialized": true,
"unlocked": true
}Cross-check the version fields against the changelog on trezor.io to confirm you’re not running an outdated build. If bootloader_mode reports true outside of an intentional firmware update, disconnect and re-verify through Suite immediately, that’s not a normal resting state.
Step 5-6: Harden Your PIN and Configure Shamir Backup
Step 5: Set a strong PIN and enable a passphrase wallet
The Safe 7 supports PINs up to 50 digits. Use at least 8-10 digits entered via the device’s own randomized keypad layout (Trezor scrambles the on-screen number positions specifically to defeat shoulder-surfing and keylogging). Then enable passphrase protection in Trezor Suite’s device security settings. A passphrase acts as a “25th word”: it derives an entirely separate hidden wallet from the same seed, so even if someone extracts your seed words, they can’t reach passphrase-protected funds without also knowing the passphrase. Write your passphrase down somewhere separate from your seed backup. Losing it means losing access to that wallet permanently, since Trezor cannot recover it for you.
Step 6: Configure Shamir Backup instead of a single seed
Safe 7 supports Multi-share Backup (Trezor’s branding for a Shamir-style SLIP-39 scheme) alongside the standard single 12/20/24-word backup. Instead of one seed phrase that, if found, gives an attacker everything, Shamir splits your backup into multiple shares where only a threshold number (for example, 3 of 5) are needed to reconstruct the wallet. Set this up from the device’s backup wizard during initialization, or via a wipe-and-restore if your device is already initialized with a single seed. Store each share in a physically separate location. The entire point is that no single location’s compromise is fatal.
Step 7-8: Model Your Threat Exposure and Move to Multisig
Step 7: Build a physical threat model for your device
The TROPIC01 attack requires an adversary to physically possess your device long enough to decap the chip and run laser fault injection in a lab, work that takes specialized equipment and real time, not seconds. Ask yourself honestly: does your device ever leave your control unattended? Do you travel with it, store it at a shared address, or leave it in a location others can access? If the answer is yes for a meaningfully valuable wallet, that’s your signal to move to Step 8’s multisig setup rather than relying on a single device’s physical security.
Step 8: Move high-value holdings to a multisig setup
Multisig spreads trust across multiple independent devices so that compromising any single one, whether through TROPIC01-style fault injection, theft, or a supply-chain tamper, isn’t enough on its own. This builds on the same cold storage principles as a multi-device vault: using Sparrow Wallet as a coordinator, export your Safe 7’s public key descriptor and combine it with descriptors from at least one other device, ideally from a different vendor entirely so a single vendor-level flaw can’t compromise every key:
# In Sparrow: File > New Wallet > Multi Signature
# Policy: 2-of-3
# Add device 1: Trezor Safe 7 (via Trezor Bridge)
# Add device 2: second hardware wallet, different vendor
# Add device 3: third hardware wallet, offline backup device
# Export the multisig wallet descriptor (.json) and back it up separately from all seedsA 2-of-3 policy across two different vendors means an attacker needs to defeat two independently designed security architectures, not just find one chip’s flaw. This is the single highest-leverage step in this entire guide for anyone holding meaningful value.
Step 9-10: Lock Down Linux Access and Build an Audit Script
Step 9: Set up udev rules for a secure Linux workflow
On Linux, trezorctl and Trezor Bridge need permission to talk to the USB device without running as root. Create a dedicated udev rule rather than running everything with sudo:
sudo tee /etc/udev/rules.d/51-trezor.rules <<'EOF'
SUBSYSTEM=="usb", ATTR{idVendor}=="534c", MODE="0660", GROUP="plugdev", TAG+="uaccess"
KERNEL=="hidraw*", ATTRS{idVendor}=="534c", MODE="0660", GROUP="plugdev", TAG+="uaccess"
EOF
sudo udevadm control --reload-rules
sudo udevadm triggerThe vendor ID 534c is SatoshiLabs' registered USB vendor ID and applies across the Trezor product line. After reloading, unplug and replug your device, then re-run trezorctl list to confirm it's detected without needing sudo.
Step 10: Write an automated firmware-audit script
This is your complete working project for this tutorial: a small Python script that wraps trezorctl to flag stale firmware, unexpected bootloader mode, or missing passphrase protection every time you run it. Save it as trezor_audit.py:
#!/usr/bin/env python3
"""Quick Safe 7 hygiene check. Run after every firmware update or before moving funds."""
import json
import subprocess
import sys
def get_features():
try:
raw = subprocess.check_output(["trezorctl", "get-features", "-j"], text=True)
return json.loads(raw)
except FileNotFoundError:
sys.exit("trezorctl not found. Install with: pip install --user trezor")
except subprocess.CalledProcessError:
sys.exit("No device detected. Check the USB cable and udev rules (Step 9).")
def audit(features):
warnings = []
if features.get("model") != "Safe 7":
warnings.append(f"Unexpected model: {features.get('model')} (this script targets Safe 7)")
if features.get("bootloader_mode"):
warnings.append("Device is in bootloader mode. Confirm this was intentional.")
if not features.get("pin_protection"):
warnings.append("PIN protection is OFF. Enable it in Trezor Suite before proceeding.")
if not features.get("passphrase_protection"):
warnings.append("Passphrase protection is OFF. Consider enabling it (Step 5).")
return warnings
if __name__ == "__main__":
f = get_features()
print(f"Model: {f.get('model')} Firmware: {f.get('major_version')}."
f"{f.get('minor_version')}.{f.get('patch_version')}")
issues = audit(f)
if issues:
print("\nWARNINGS:")
for w in issues:
print(f" - {w}")
sys.exit(1)
print("No issues found.")Run it with python3 trezor_audit.py any time you've just updated firmware, restored a backup, or handed the device to someone else temporarily (a repair shop, a partner, a border agent). It won't catch a silicon-level fault injection attack, nothing running on the host machine can, but it will catch the much more common failure mode: a setting you forgot to re-enable after a factory reset.
Step 11-12: Plan Quantum-Resistant Migration and Ongoing Monitoring
Step 11: Plan your path to quantum-resistant addresses
Trezor markets the Safe 7 as quantum-ready hardware, but that claim is about the device's capacity to support future signature schemes, not a claim that your existing Bitcoin addresses are quantum-resistant today. The relevant protocol work is BIP-360, which proposes a new Pay-to-Multi-Ripple (P2MR) output type using the bc1z address prefix. As BIP-360 co-author Ethan Heilman put it, "BIP 360 is step one," describing an output type with "the upgradability and features of P2TR without the quantum vulnerability." Heilman has also been clear that address migration alone isn't the finish line: "If we want full quantum safety, we also need step two: adopting a post-quantum signature algorithm."
A companion proposal, BIP-361, goes further, outlining a staged retirement of old signature types with a multi-year window (several drafts have floated roughly five years) after which coins left on legacy addresses could become unspendable unless moved. Heilman has summarized the full scope of the work bluntly: "Bitcoin needs a minimum of two soft forks to become quantum resistant," pairing a new output type like P2MR with "a post-quantum checksig (signature scheme)" before the network can claim real quantum resistance, not just quantum-readiness in marketing copy.
Neither BIP has activated on Bitcoin mainnet as of September 2026, so there is no P2MR address to move funds into yet. What you can do now: keep firmware current so your Safe 7 is ready to support P2MR the moment Trezor ships it, and avoid reusing addresses unnecessarily, since an exposed public key (which happens the moment you spend from a legacy address) is the actual precondition for a quantum attack, not merely holding coins. This is also a good moment to internally separate two different risk categories you're managing with the same device: near-term physical/supply-chain risk (what Steps 1 through 10 address) and long-horizon cryptographic risk (what BIP-360 and BIP-361 address). Conflating them leads to bad decisions, like assuming a firmware update fixes quantum exposure, or assuming quantum resistance means you can skip PIN hygiene.
Step 12: Set a recurring verification and monitoring routine
Hardening isn't a one-time task. Put a recurring calendar reminder, monthly is reasonable for active wallets, to: check Trezor Suite for firmware updates, re-run your trezor_audit.py script, confirm your backup shares are still legible and in their designated locations, and check Trezor's official blog for any new disclosures. Subscribing to Trezor's security advisories directly (not a third-party aggregator) is the fastest way to hear about the next issue before it hits general tech news.
Common Pitfalls When Hardening a Hardware Wallet
Most of the damage done to hardware wallet users doesn't come from silicon-level attacks like the one Ledger Donjon demonstrated, it comes from process mistakes that are entirely avoidable. The following list covers the ones that show up most often in incident reports and support forums.
- Typing your seed into a computer to "back it up digitally." Any seed or Shamir share that touches an internet-connected device is no longer cold storage, full stop.
- Storing all Shamir shares in the same house. This defeats the entire purpose of splitting the backup. Geographic separation is the point.
- Downloading Trezor Suite from a search ad or unofficial mirror. Fake Suite installers are a recurring phishing vector, so always type trezor.io directly.
- Skipping the on-screen fingerprint check during firmware updates. This is the step that would actually catch a tampered update in transit.
- Treating passphrase and PIN as interchangeable. A PIN protects against casual theft. A passphrase creates a hidden wallet that protects against seed exposure. You need both.
- Buying a hardware wallet from a third-party marketplace instead of the vendor directly. Devices with tampered packaging or pre-set PINs have shown up in resale channels.
- Assuming multisig removes the need for good backups. Losing 2-of-3 signing devices is just as fatal as losing a single-sig seed, so back up every key in the quorum.
- Ignoring vendor security advisories because "nothing happened to my funds." A disclosed-but-unexploited flaw today is still worth acting on before it becomes an exploited one.
- Re-using the same PIN across a hardware wallet and unrelated accounts. If the PIN leaks anywhere else, it removes one of your device's two independent authentication layers.
Troubleshooting Guide
Nine of the most common issues readers hit while working through this tutorial, roughly in the order you're likely to encounter them:
- trezorctl list shows nothing on Linux: Your udev rule likely didn't apply. Re-run Step 9, then run sudo udevadm trigger and unplug/replug the device before retrying.
- pip install trezor fails with a permissions error: Use pip install --user trezor, or install inside a virtual environment (python3 -m venv venv && source venv/bin/activate).
- Trezor Suite won't detect the device on Windows: Install Trezor Bridge separately from trezor.io, then restart Suite. Some Windows configurations need Bridge running as a background service.
- Firmware update fails partway through: Do not unplug the device. Follow the on-screen recovery instructions in Suite. Safe 7's bootloader is designed to survive an interrupted update, but disconnecting mid-flash can force a bootloader-mode recovery.
- Device shows a different fingerprint than Suite during an update: Stop immediately. Disconnect, verify you're using the official Suite build, and if the mismatch persists, contact Trezor support before proceeding.
- Shamir Backup wizard won't let you proceed past share entry: Double-check you're entering the exact SLIP-39 wordlist spelling. Trezor validates checksums per share and will reject a single mistyped word.
- trezorctl get-features returns a permissions/access error on macOS: Grant the terminal app USB access in System Settings > Privacy & Security, then retry.
- Sparrow Wallet doesn't detect your Safe 7 for multisig setup: Confirm Trezor Bridge is running and that Suite is fully closed, only one application can hold the USB connection at a time.
- Passphrase wallet shows a zero balance you expected to see: This usually means you're on the standard wallet, not the passphrase-derived one, or you've mistyped the passphrase. Passphrases are case- and character-sensitive with no recovery option.
Advanced Tips for Power Users
If you're running a Safe 7 as part of a business treasury or a security-sensitive personal setup, a few additional practices are worth the extra effort. First, air-gap your coordinator machine entirely for the highest-value multisig setups, using a permanently offline computer with Sparrow installed and PSBT files moved via SD card or QR code rather than a network connection. Second, consider geographically distributing multisig cosigners across different jurisdictions if you're protecting against coercion or seizure scenarios, not just device compromise. Third, extend the trezor_audit.py script from Step 10 to log results with timestamps to a local file, giving you an audit trail if you ever need to demonstrate consistent security hygiene (useful for insurance, estate planning, or institutional compliance). Finally, if you manage multiple devices across a team, script trezorctl calls into your existing configuration-management tooling (Ansible, for example) so firmware-version drift across the fleet gets flagged automatically rather than discovered during an incident.
A second tier of advanced hardening worth considering: rotate your threat model review at least twice a year, not just once at setup. Devices age, travel patterns change, and new disclosures reshape what "reasonable" security looks like. Treat the trezor_audit.py output as one input into a broader personal or organizational security review rather than a pass/fail gate on its own. If you're securing funds for other people, whether family members, a DAO treasury, or a small fund, document your multisig quorum, your backup locations (in a way that doesn't itself leak the seed material), and your update cadence somewhere your successor or co-signers can find it without you present. A perfectly hardened wallet that only one person understands is itself a single point of failure.
Finally, if you're evaluating whether to add a second TROPIC01-based device to an existing multisig setup, think carefully about correlated risk. Two Safe 7 units in the same 2-of-3 quorum both inherit the same chip-level exposure. A vendor-diverse quorum (Trezor plus a device using an entirely different secure element supply chain) gives you protection against exactly the kind of single-chip disclosure this tutorial is built around.
Trezor Safe 7 vs Other Hardware Wallets After the Disclosure
The TROPIC01 disclosure doesn't mean rival devices are inherently safer, every hardware wallet vendor has had its own disclosed flaws. See our Ledger vs Trezor comparison for a fuller pricing and feature breakdown. Ledger's own Donjon team has previously found and disclosed physical flaws in earlier Trezor models too, including the Safe 3 in March 2025. The honest comparison is about architecture and disclosure track record, not about which brand has never had a bug.
| Factor | Trezor Safe 7 | Single secure-element wallets |
|---|---|---|
| Secure element count | Two independent SEs plus hardened MCU | One SE, one point of chip-level failure |
| Open-source firmware | Yes | Varies by vendor |
| Public vulnerability disclosure history | Yes, TROPIC01 (2026) and Safe 3 (2025) both disclosed publicly | Varies, some vendors disclose less openly |
| Shamir Backup (SLIP-39) support | Yes | Vendor-dependent |
| Marketed quantum-readiness | Yes, positioned for future BIP-360 support | Vendor-dependent |
The practical takeaway for this guide: a multi-chip architecture with a public disclosure history is, on balance, a stronger signal than a vendor that has simply never been audited by researchers as thorough as Ledger's Donjon team. The steps in this tutorial, especially multisig and Shamir Backup, are designed to make your security independent of any single vendor's next disclosure, whichever brand it turns out to involve.
It's also worth resisting the urge to treat this as a simple ranking exercise. Ledger's own devices have had their own disclosed issues over the years, and every hardware wallet, regardless of brand, ultimately depends on the owner following through on backup hygiene, firmware verification, and sane custody decisions. The architecture buys you resilience against a partial compromise. It doesn't buy you immunity from a lost seed phrase or a phishing site cloning your update flow. Both matter, and this guide is built to cover both.
Frequently Asked Questions
Is my Trezor Safe 7 safe to keep using after the TROPIC01 disclosure?
Yes, according to Trezor's own statement, funds are not directly exposed by the chip flaw alone because the attack requires sustained physical possession of the device plus lab equipment, and the other two security layers remain intact. Follow the hardening steps above rather than replacing the device.
Do I need to move my funds to a new device immediately?
No. There is no remote exploit and no evidence of funds lost to this vulnerability. Moving to multisig (Step 8) is a stronger long-term response than swapping devices.
What's the difference between Shamir Backup and a standard seed backup?
A standard backup is a single 12, 20, or 24-word phrase, and anyone who finds it can access your wallet. Shamir Backup splits your backup into multiple shares, requiring a threshold number to reconstruct the wallet, so a single found share isn't enough on its own.
Does the Safe 7 actually protect against quantum computers right now?
No. It's built to support future post-quantum signature schemes once BIP-360 and related proposals activate on Bitcoin mainnet, but that hasn't happened yet as of September 2026. Your current addresses use standard elliptic-curve signatures.
Is a CVE assigned to the TROPIC01 vulnerability?
As of this writing, no publicly assigned CVE identifier has been cited in Ledger Donjon's research writeup or Trezor's official response.
Can I run trezorctl and Trezor Suite at the same time?
No, close Trezor Suite before running trezorctl commands. Both applications compete for the same USB connection, and only one can hold it at a time.
What should I do if I bought my Safe 7 from a reseller, not directly from Trezor?
Run the Step 4 features audit and inspect the tamper-evident packaging before initializing the device. If anything looks off, contact Trezor support before entering any seed or PIN.
Does multisig with a Safe 7 require all cosigners to be Trezor devices?
No, and mixing vendors is actually recommended. A 2-of-3 setup spanning two different hardware wallet brands means an attacker has to defeat two independently designed security architectures, not just one.
How is this different from a normal firmware bug?
A typical firmware bug can usually be patched remotely with a signed update. The TROPIC01 issue lives at the silicon level, meaning Tropic Square cannot fix already-manufactured chips with a software patch. Any true fix requires a new chip revision. That's why the hardening steps in this guide focus on operational controls (PIN, passphrase, multisig, physical custody) rather than waiting on a firmware download to make the problem disappear.
