“SE versus open source” lists flatten three different questions: who executes the signature, who is allowed to load code onto it, and what you can verify on the specimen in your hand. Here are the distinctions, then the contracts — a type is not a ranking.
Three distinctions that break the tables
Open source is not verifiable on the unit
A GitHub repository describes software someone published. It does not say which binary is sitting in the flash of the device in your hand. Confusing the two is the most common shortcut in comparison tables: “open-source firmware” is treated as a property of your Nano, your Coldcard, your Safe. It is a property of a repository.
To bring the repository closer to the unit you need reproducible builds — two independent compilations of the same commit produce the same hash — and then a way to read that hash on the device: a bootloader that displays it, a dump, an attestation whose key you control. On an MCU, that is sometimes possible. On a Secure Element with a closed OS, the code that signs is not dumpable. At best you verify that Ledger or Infineon attest “this is a genuine chip”. You do not compile BOLOS.
The closest thing to unit verification is not a “slightly more auditable” SE. It is commodity hardware onto which you flash a binary you built (SeedSigner, Krux on a Yahboom K210), while living with the closed boot ROM of the Pi or the K210. Published RTL, such as TROPIC01’s, can be read. It does not prove that the die in your Safe 7 is that Verilog. Nobody verifies a wafer from their living room.
An authenticator is not a smartcard, and neither is “the” SE
“Secure Element” is a marketing word that covers at least three objects. Mixing them produces tables in which Coldcard, Ledger and Satochip share an identical “SE: yes” cell. They do not share the same silicon.
A vendor-OS SE (Ledger’s ST33, Tangem’s Samsung) is a certified small computer: OS, applications, keys that are born and sign inside the chip. A JavaCard smartcard (Satochip, TAPSIGNER, JCOP) is an ISO 7816 platform with an applet VM and GlobalPlatform. A fixed-instruction authenticator (Microchip ATECC608, Maxim DS28C36B on Coldcard, and in another measure the OPTIGA Trust M at Trezor) does not run your code: it has slots, HMAC, ECDSA, a datasheet. No OS. No Recover applet. Coldcard has two chips of this third family, from two vendors, so that breaking one ROM does not deliver the seed. That is not “two Ledgers”.
The card form factor does not help. Tangem is a card and a closed Samsung SE, not a JavaCard whose applet you can read. Satochip is a card and a JavaCard whose applet you can read, not an ATECC. Coldcard is not a card. Filing all three under “NFC / SE / hybrid” is precisely the imprecision.
Silicon programmability decides what an update can do
If the manufacturer can load new code into the chip that holds the seed, Recover is not a physical betrayal. It is a policy. Ledger showed that an ST33 running BOLOS, once updated, knew how to shard entropy. An ATECC608 will not learn that: its instruction set is frozen in mask ROM. On Coldcard, the code you update is the MCU firmware, which is published. On Satochip, it is applets, provided you hold the card’s issuer keys; on a locked production card, that is Satochip, not you.
TROPIC01 inverts the sentence again. It is a RISC-V whose application firmware is designed to be updated and read. You can patch an ECC implementation. A lab that faults signature verification can, as Donjon did in 2026, run unsigned code on it. Openness and programmability are the same object: useful for fixing, useful to an equipped attacker. Hence the other two layers of the Safe 7.
Frozen silicon does not receive a backdoor by update. It also does not receive a patch. Vendor-OS silicon receives both, depending on who signs. Asking “does it have an SE?” without asking “who is allowed to load code onto it, and is that code the one on this unit?” is the question that produces the lists you read everywhere.
Vendor-OS secure element
A certified computer whose manufacturer signs the code
The secret is born, lives, and signs inside a small Common Criteria–certified computer. That computer has an OS (BOLOS at Ledger, Samsung’s OS at Tangem), applications, and field updates signed by the vendor. The interface MCU displays and talks to the world; it does not see the seed. You do not read the code that touches the keys. You read a certification and an authenticity attestation.
An ST33 or a Samsung SE is not a slot authenticator. It is a secure CPU, with memory, an entropy generator, tamper detectors, and the ability to run new code if the vendor’s signature checks out. Ledger Recover is possible only because that ability exists: an update could teach the chip to shard entropy. An ATECC608 would not have learned it.
Common Criteria EAL5+ or EAL6+ describes a scope evaluated by a lab, under a methodology. It is not “unattackable”. It is not “the code is public” either. It is the chosen substitute for reading the binary.
Attestation says: this chip is a genuine vendor chip. It does not say which SE firmware runs on it beyond what the vendor is willing to attest. Compiling BOLOS at home is not on the menu.
Strengths
Lab-grade physical resistance by construction (glitch, side channels, extraction), well above a bare STM32.
Keys do not travel in the clear on the display MCU.
Certifications useful if the threat is seizure, targeted theft, a border search with equipment.
Limits
The vendor can, in principle, make the SE do new things. Recover turned that sentence from theoretical into historical.
You do not verify the signing binary, only an attestation chain.
“Closed source” here is not a style. It is the contract: company + lab, not a reading of the silicon.
The MCU can be read; the chip beside it, almost never
The catalogue word “hybrid” puts Trezor Safe 3, Coldcard and, too often, Satochip in the same bucket. They do not share silicon. What the bucket gets right: the firmware that composes the transaction, displays, speaks PSBT, is published, sometimes with reproducible builds. A separate chip hardens the PIN, wrapping, or a share of the secret. That chip is not “a Ledger SE”. On Coldcard they are two fixed-instruction authenticators. On Safe 3 / 5, a companion OPTIGA. Neither runs Recover.
ATECC608 and DS28C36B (Coldcard) have a datasheet, slots, HMAC, ECDSA. No OS, no applets. The wallet runs on the MCU. The two chips, from two vendors, hold shares of the secret so that one broken ROM is not enough. Calling that “dual SE” without this sentence is copying the product sheet.
The OPTIGA Trust M on Safe 3 / 5 is an EAL6+ companion SE. It wraps, attests, hardens the PIN. Keys do not “live in” the OPTIGA the way they live in an ST33. The open STM32 signs. You can aim at a reproducible MCU hash. You will not dump the OPTIGA.
BitBox, OneKey, Keystone, ELLIPAL belong here because of application firmware, not because their silicon is the same. Read the “silicon class” line on each sheet. The bucket is not the description.
Strengths
The code that decides what is displayed and what is signed can be read, compiled, sometimes reproduced.
An authenticator or companion SE raises the cost of the glitching that killed the Trezor One, without giving the vendor an OS into which to load Recover.
Two authenticators from distinct vendors (Coldcard) are not “twice the SE”: they avoid a single mask ROM as a single point of failure.
Limits
The helper silicon remains a box. Open MCU source is not an audit of the Microchip ROM.
An entropy bug in the open firmware, left for years, showed that the repository does not read itself. Yasmarang on Coldcard: the two chips compensated for nothing.
“Hybrid” in a table is the word that flattens these differences. Do not use it as a conclusion.
A smartcard in the ISO 7816 sense is an applet VM, GlobalPlatform, issuer keys. Satochip sells that: an NXP JCOP EAL6+ and an AGPLv3 applet. It is not Tangem (same card form factor, closed Samsung SE, key often born imprisoned), nor Coldcard (authenticators, no JavaCard). If the “SE” cell in tables lines them up, the cell is wrong.
The applet compiles and can be read. On development cards whose ISD keys are known, you flash it. On a locked production card, only the vendor installs. The JavaCard OS and the NXP silicon stay closed: you audit the applet, not the chip.
Private keys do not leave the silicon, as with Ledger, but the update contract is not BOLOS. It is GlobalPlatform. The seed, on Satochip, remains a BIP39 you import — so a plate, or a Seedkeeper. That is not Tangem’s seedless model.
No screen. The phone or PC is the display. Clear signing depends on the host. Satochip says so: a software HMAC in the applet has a cost against a bench.
Strengths
The applet is readable, forkable, sometimes self-hostable on a generic card.
Card form factor, NFC, no battery, cheap as a multisig leg.
Classic BIP39 seed: portability outside the vendor’s ecosystem.
Limits
JavaCard OS and NXP die opaque. EAL certifies the chip, not the applet as you compile it.
Without a screen, the host is an untrusted viewer.
Real programmability only if you hold the issuer keys — otherwise it is the vendor, as elsewhere.
The documentary maximum, not proof that your specimen matches
Free firmware and gerbers / BOM / schematics (CERN-OHL at Foundation, Jade at Blockstream). You reduce blind trust in the drawing. You do not prove that the board in your hand was assembled from those files. Openness is about what can be inspected, not about the absence of a security chip, and not about an ESP32’s closed boot ROM.
Passport publishes the circuit and still ships security silicon. Jade, especially, is an MCU (ESP32) with open schematics, often a multisig leg. Neither makes an SE dumpable, if there is one.
Reproducible builds close part of the software gap. The factory gap — swapped component, test implant — is handled by attestation, buying direct, and, for DIY, buying generic boards you flash yourself.
“Fully open source” on a product sheet means: files exist. The next question is always: what can you measure on this specimen, tonight.
Strengths
Less black box on the drawing, a chance to fork after commercial end of life.
Often Bitcoin-only: narrower firmware surface.
Cheap Jade holds as a key in a 2-of-3 where its physical weakness is a quorum.
Limits
An open schematic does not prevent a factory swap.
Rebuilding the device to verify the supply chain remains out of reach for almost everyone.
UX and availability less “one app for everything”.
Everything is readable; the silicon was not designed to hide a secret
An off-the-shelf microcontroller runs everything. No authenticator, no JavaCard, no ST33. The software can be read. The die has no integrity mesh and no SE-class glitch detector. That was the Trezor One and Model T. Kraken, in 2020, dumped an encrypted seed in fifteen minutes of physical access.
Countermeasures are software: PIN-encrypted flash, delays, wipe. They hold against a hurried thief. They fold against a bench.
This architecture survives mainly where people stopped storing a secret (stateless). A bare MCU with a seed sleeping in flash is a historical object, still in circulation.
Auditability of the C did not prevent the glitch. It made the glitch understandable. That is not the same sentence as “therefore it is safer”.
Strengths
No silicon black box beside the firmware.
Pedagogy, cost, historical community.
Limits
Physical attacks (glitch, fault, dump) in the equipped attacker’s garden.
Evil maid and seizure are the threat models that win.
Units still in a drawer did not change physics because the catalogue changed.
Stateless / DIY
No persistent secret; the vault is the plate
You load firmware into RAM, you sign a PSBT, you power off. There is nothing left to extract. An SE has nothing to keep. Verifiability comes from commodity hardware you flash, not from a vendor publishing RTL. The steel seed becomes the secret again. Photographed, it is lost — the dongle is plastic.
SeedSigner (Pi Zero) and Krux on K210 (Yahboom, M5, Maix): firmware in RAM, QR, dice. On power-off, zero seed — unless you chose to encrypt a mnemonic on the Yahboom. The PC sees an already-signed transaction.
You can, more than elsewhere, put on the unit a binary you built. The Pi or M5 boot ROM stays closed. That is the honest ceiling of “verifiable” in 2026 for a private individual.
Every spend is a ritual. Firmware is re-checked. A gaze, human or camera, while the words are on screen, bypasses all the hardware.
Strengths
The least dishonest unit-verifiability in the catalogue, low cost, nothing to steal once off.
A natural multisig leg.
You understand seed, PSBT, derivation, because you touch them.
Limits
Useless day to day for anyone who does not want the ritual.
The plate is the real vault — and the real phishing.
Pi / M5 supply chain: verifying the binary is not a luxury.