I’d like to raise a security concern regarding the Passport Prime Vault that I think deserves attention.
Currently, access to the Vault is protected only by the device PIN. There is no additional authentication layer specific to the Vault itself (dedicated password, separate passphrase, etc.).
If successful, all seeds imported into the Vault are directly accessible
The native Bitcoin wallet already offers the option to hide the wallet behind a BIP39 passphrase as an additional layer of security, which is excellent. However, no equivalent protection exists for seeds and passwords stored in the Vault.
I understand Foundation positions the Seed Vault for low-value wallets, which is consistent with this level of protection. However, this limitation deserves to be communicated more clearly in the official documentation, to prevent users from storing critical seeds there under the assumption they benefit from the same protection as the device’s native seed.
I propose this three-tier architecture:
Tier 1 — Device PIN
Access to basic Passport Prime functions
Tier 2 — Dedicated Seed Vault password
Access to imported seeds
Clear decoupling between wallet access and seeds/password access
Second factor physically decoupled from the device
Even if the Passport Prime is stolen, the Vault remains inaccessible without the external FIDO key
Critical point on FIDO: using the virtual YubiKeys built into the Passport Prime itself does not provide meaningful additional security for this use case — if the device is stolen, the FIDO is stolen too. Only an external FIDO key that is physically separate creates a real decoupling.
My questions:
Is a dedicated Vault password planned in an upcoming KeyOS firmware update?
Is support for an external FIDO key as a second factor for Vault access on the roadmap?
Thanks for your work on this device — it remains very promising.
I understand your concern but Tier 2 doesn’t make sense to me: you might as well just use that stronger password as access to the Prime itself rather than just the vault.
What would make sense is adding support for the passphrase in the vault which would then unlock the hidden entries like it does on a wallet. This would also have the benefit of deniability since not everyone would have a passphrase.
Ideally (down the line) I’d like Prime version 2 to have an ultrasonic fingerprint reader. Then you can use pin and fingerprint combination as well.
On Tier 2, I see where you’re coming from, but I think there’s a distinction worth keeping: the device PIN protects everything on the Prime (2FA, security keys, native wallet, camera…). A dedicated Vault password would only protect the seeds and passwords stored in the Vault. If an attacker gets the PIN through coercion or shoulder surfing, everything is compromised at once. Two separate credentials mean two separate extractions needed, that’s a meaningful difference.
On the passphrase in the Vault, that’s a great idea. Inspired by BIP39 or VeraCrypt-style hidden volumes, it could create a separate encrypted space, invisible without the right key, applicable not only to HD wallets but also to entries in a seed manager, password manager, and file storage. Without a passphrase, the Vault and Files appear empty or harmless. With a passphrase, the real entries appear. I’m not sure if it’s technically feasible in that context, but if so it would be a real added value.
On biometrics, my main concern is physical coercion. A PIN can be forgotten, denied, or made useless via a duress code. An external FIDO key can be hidden. A BIP39 passphrase can leverage plausible deniability. A fingerprint or a face can’t be denied, an attacker just has to point the device at your face or force your finger onto it. No need to convince you of anything.
I don’t see why a passphrase to reveal passwords isn’t possible.
Regarding biometrics, that’s why I said a combination. Then they’d have to have you and force you to enter a PIN. If they can get your PIN and fingerprint I think you have bigger issues that a YubiKey won’t solve. Interesting, a passphrase may also work even here.
Passphrase for hidden entries seems like the lowest hanging fruit!
You’re right, and it’s probably the most elegant solution. My point was really just to ask whether enhanced security for the Vault and Files is on the roadmap. The passphrase approach would be the ideal answer to that.
However, if in your escenario an attacker could socially engineer you to obtain your Prime unlocking code, what prevents it from also socially engineering you from obtaining yotu vault unlocking password? Like, adding more layers of the same stuff doesn’t really add protection if your assumption is that one can be bypassed. Because if one can be broken, two can as well, right?
If you think you can add a solid password to protect your vault, why not make that your Prime unlocking code? Remember it’s not mandatory to set up a numeric PIN, you can define an alphanumeric password that can be as long as you want. So just move that protection layer upwards one level?
I mean I’m not against adding extra layers of protection, I guess each app could optionally be password protected? I added a backlog item for us to explore this (SFT-7094), though I can’t promise it will make it into any short term version for now.
This is why I suggested a passphrase. Passphrase in the seed sense that can be entered but isn’t prompted for and each one would show the contents of a different vault. This way if it isn’t entered there’s no knowing that things are still hidden.
Right, the problem with that is that people could forget about their passphrase, and then they would be screwed, our customer support inbox full with complaints and the user would end up having a terrible experience. I don’t think we will want to offer anything where we open the door for users to shoot themselves in the foot.
With the password protection there could still be some way out, like passwords for apps not being backed up to the Magic Backup for example. So if you really screw up and forget about your app passphrase you can always factory reset the device and restore from magic backup (granted you have not lost access to the keycards) that restores everything but removing the password locks for the apps. I guess to your point the same could be done about the passphrase? Ignore the flag in the magic backup and show everything upon restore? But then again, this would open another can of worms: your passphrase protected apps are no longer protected if someone has access to your master seed. I don’t know, it’s not an easy one to solve!
I understand the concern around the risk of forgetting and the impact on customer support. However, I think this feature could be offered in “expert” mode, with a clear warning:
“This protection is irreversible. If you lose your passphrase, the contents of your hidden vault and hidden files will be permanently inaccessible.”
This model is already well accepted in the crypto ecosystem. Advanced users targeted by this feature understand and accept this type of risk, this is not comparable to a regular user shooting themselves in the foot.
If a passphrase is not the preferred approach, a VeraCrypt-style password would work equally well. The risk of loss is exactly the same. VeraCrypt has been using this model for years with its hidden volumes: two different passwords reveal two different contents, with no indication that a hidden volume even exists. Nobody complains that VeraCrypt doesn’t offer recovery. It is assumed and documented. The real question is whether we trust advanced users to take ownership of that choice, and in the crypto ecosystem, the answer is generally yes.
However both approaches raise an important architectural question:
• A seed-style passphrase works through cryptographic key derivation (BIP39): each passphrase is mathematically valid and generates different content, providing total plausible deniability
• A VeraCrypt-style password works through volume encryption (AES-256): the hidden vault is physically nested inside the main volume, nothing reveals its existence.
The real architectural question is therefore: are we encrypting a data volume or deriving cryptographic keys? Both provide solid plausible deniability, but the implementation would be fundamentally different.
I agree with @Flailmower that the “shooting themselves in the foot” isn’t a good argument. Anyone who uses cold storage crypto has some level of responsibility (they can send funds to non-existent wallets). I also suggest this feature be an “expert” feature with warnings and not in the standard process (just like passphrase for the main wallet). If it works for the main wallet, why can’t we apply it to other apps?
If I understand correctly, KeyOS works a bit like QubesOS right? Each app in its own isolated container. With the difference that the master key, stored in the Secure Element, generates a different key for each app, kind of like BIP32?
If that’s the case, could the passphrase intervene directly in the derivation of the master key upstream, before the child keys are even generated for each app? And therefore the hidden vault would benefit from the same level of protection as the Bitcoin wallet. So one single passphrase for both the Bitcoin wallet and the apps?
Good instinct, and your mental model is close. KeyOS does isolate each app, and every app’s key is deterministically derived from the device master key held in the secure element, so it’s the same “one master secret, many child keys” idea you’re describing (we use an HMAC-based derivation rather than literal BIP32, but the structure is the same).
The Bitcoin wallet’s passphrase today is applied within the wallet itself, as a standard BIP39 passphrase, rather than upstream of that per-app derivation. So your idea, mixing a passphrase in at the master-key level so it cascades to every app at once, is plausible on the surface and would in principle give the Vault and other apps the same deniability the wallet gets. It’s something we may explore down the line.
The honest caveat is that it would be a significant lift, not a small toggle: it touches the core derivation path, has to keep the Bitcoin wallet’s passphrase BIP39-standard so wallets stay portable, and each passphrase would produce a fully separate persona with its own backup (and no recovery if the passphrase is lost). So no promises, but it’s an interesting direction for us tom think about.
I’d like to come back to your concerns about backup and forgotten passphrases. I’m not sure why this would be more of a problem than it already is with the Bitcoin wallet.
If the backup is performed with the passphrase active, the Keycards encode the complete device state including the content derived with the passphrase. At restore time, it would simply require an optional passphrase field:
Correct passphrase entered = full restore, hidden vault included
Field left empty = normal restore with seed only, hidden vault absent
I’m aware this is not a trivial change, but I believe, like @Mason.99999, that it would be of tremendous value.
In any case, congratulations on your work. This hardware wallet is a really beautiful device, and I’m convinced it will become far more powerful than it already is.