A hardware wallet exists so a private key never touches a networked machine. That part is well understood. The part that decides whether a device is actually safe is narrower: can the person holding it see, on hardware they trust, exactly what they are about to authorise — and refuse. A device that signs what the host asks without showing it has moved the key and kept the vulnerability.
Each maps to a specific attack. A device that has five of the six has a named weakness, not a smaller amount of security.
| Signal | How | What it changes |
|---|---|---|
| Key generation on the device | Entropy sourced and keys derived in the secure element, never imported | A key generated elsewhere existed elsewhere — on a machine, in a process, in someone's memory |
| Keys never leave | Signing happens inside the boundary; the key is not exported under any command | Extraction through the host interface, malware on the connected computer |
| Trusted display and confirmation | Address and amount rendered by the device, physically confirmed | The host showing one transaction while requesting the signature for another |
| Verified firmware | Signature checked from an immutable first stage before execution | Substituted or modified firmware that behaves correctly until it does not |
| Tamper evidence | Enclosure and package designed so interference is detectable | Interception in transit, or a device returned to a user after handling |
| Supply chain attestation | The device proves at first use that it is genuine and unprovisioned | A counterfeit or pre-initialised unit substituted before it reaches the owner |
The sensing is the solved part. These are what determine whether the deployment is still running in year three.
If the device renders what the host tells it to render, the trusted display is decorative. The device must parse the transaction itself and present its actual effect — which means understanding the payload rather than relaying a description of it. Complex contract interactions make this genuinely difficult, and it is where real devices differ most.
Certified secure elements provide key storage, cryptographic operation and physical attack resistance. They do not decide what gets signed, what the user sees, or how firmware is verified. Most of the security-relevant design sits outside the part everyone names in the datasheet.
A seed that can restore the wallet can steal it. Generation, display, backup guidance and the restore path have to be designed together, and the honest engineering position is that most real-world losses are recovery failures rather than device compromise.
A wallet can be intercepted, opened, modified and repackaged. Tamper-evident construction and an attestation the owner can check at first use are the defence — and the check has to be simple enough that a non-technical owner performs it.
Certified elements resist a defined class of attack for a defined effort. Against an unbounded laboratory attack with physical possession, the correct claim is tamper-evident, not tamper-proof. Any vendor claiming otherwise is describing marketing rather than a threat model.
No device protects a key from someone who compels its holder to use it. Passphrase and duress features change the shape of that problem without removing it, and saying so plainly is part of specifying the product honestly.
The same discipline, wherever a key must not leave the hardware holding it.
Air-gapped or interface-connected devices holding keys for digital assets, with a trusted display and physical confirmation.
Code signing, document signing and administrative credentials where the key must not exist on a networked machine.
Hardware-anchored identity for equipment that must prove what it is across a supply chain.
Phishing-resistant authentication where the credential is bound to the hardware and cannot be copied to a second device.
Not the secure element alone. Keys generated on the device and never exported, firmware verified from an immutable first stage, tamper-evident construction, an attestation the owner can check at first use — and above all a trusted display that renders the actual transaction so the holder can refuse it.
Signing a payload the device cannot interpret and therefore cannot show meaningfully. If the device renders whatever the host describes rather than parsing the transaction itself, the trusted display provides no protection — which makes payload parsing one of the hardest and most security-relevant parts of the design.
No, and that word should be treated as a warning sign. Certified secure elements resist a defined class of physical attack for a defined effort. Against an unbounded laboratory attack with physical possession, the accurate claim is tamper-evident.
Recovery failures rather than device compromise — a seed lost, stored insecurely, or entered into something that captured it. Generation, backup guidance and the restore path deserve as much design attention as the cryptography.
Secure hardware architecture, secure element integration, verified boot, firmware, enclosure and tamper evidence, provisioning and manufacturing transition. Mechanism-level detail and threat modelling are discussed under a non-disclosure agreement.
Silicon-rooted identity and verified boot.
SOLUTIONSmart card SoC and device identity.
TECHNOLOGYProperties, threat model and boundary.
TECHNOLOGYThe verified chain in detail.
CASE STUDYA secure part taken to production.
CAPABILITYBoard and enclosure engineering.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.