A hardware wallet keeps keys isolated from a general purpose computer. That isolation is enforced by firmware, which means the firmware itself is the thing being trusted.
Signatures gate what will run
Devices carry a manufacturer public key in read-only memory and check that any firmware image is signed by the corresponding private key before executing it.
This prevents an attacker from loading modified firmware, since they cannot produce a valid signature without the manufacturer's key.
It also means the manufacturer's signing key is a control point. Anyone able to sign can produce firmware the device will accept as genuine.
What an update can change
Firmware controls how transactions are parsed, what is shown on the screen and how keys are used. All of that can change with an update.
A build that displayed a destination address accurately could, in principle, be replaced by one that displays something different from what it signs.
This is not an accusation against any manufacturer. It is a statement of where the boundary sits, and the boundary is worth knowing when evaluating a device.
Reproducible builds narrow the gap
If firmware source is published and the build process is deterministic, independent parties can compile it and confirm the result matches the distributed binary.
That converts a promise into something checkable, because a discrepancy between source and binary becomes visible to anyone who performs the comparison.
The check has to actually be performed by someone. Publishing source without reproducibility, or reproducibility without anyone verifying, leaves the assurance theoretical.
Secure elements add a separate vendor
Many devices store keys in a secure element chip designed to resist physical extraction, which is a meaningful improvement over general purpose microcontrollers.
These chips typically run proprietary code under manufacturer agreements, so that portion cannot be independently audited even when the surrounding firmware is open.
Designs differ in how much they place inside the element, and the split determines how much of the device's behavior is externally verifiable.
Why updates should not be skipped either
Declining updates avoids the risk of a new build while retaining any vulnerability the update fixes, including flaws in transaction parsing that have been demonstrated publicly.
The reasonable position is neither automatic acceptance nor refusal, but updating from official channels after release notes and independent commentary are available.
Verifying the device's genuineness after an update matters too, since a compromised update path is one of the few ways to attack a wallet that never exposes its keys.