“Passport Prime: Great Concept, Poor Execution

I get the idea behind the product, but in reality it feels far from mature.

There are many “security-oriented” features, but the user experience doesn’t really support them — it ends up feeling more complicated than usable.

Also, requiring Envoy for core usage kind of defeats the purpose of a sovereign device, doesn’t it?

Waiting almost a year for the hardware and then seeing slow software progress is quite frustrating.

Overall, the UX and workflow feel confusing and not fully thought through. Hopefully this improves over time.

Hi @Ke_James,

We did have to strip out some functionality to meet our extended deadline. We have roadmap plans to get all of this into the software ASAP. These include:

  • BIP85 password generation
  • Item imports to the Vault
  • Bulk 2FA importing
  • Full FIDO2 support (Yubikey parity)
  • Password sharing from Prime to external device (this is further out than the rest)

Please do let us know what else you want to see. Your feedback really can help shape the software trajectory.

Also, requiring Envoy for core usage kind of defeats the purpose of a sovereign device, doesn’t it?

After setup you can remove the Envoy connection entirely if you like. But the ‘liveness’ offered with the QL connection is a requirement for things like displaying the BTC price, generating 6 digit TOTP code. Looking ahead to third part integrations and app-installs, these will also be leveraging QL and Envoy for discovery and app features.

If you’re happy to not use those features and go for the more air-gapped approach, Passport Prime can.

Further down the line we plan to add manual FW updates and potentially a completely manual onboarding to remove Envoy entirely, but the above caveats around diminished functionality remain and its certainly not a priority for us right now.

Overall, the UX and workflow feel confusing and not fully thought through. Hopefully this improves over time.

Would love some more specifics on what you’re getting confused by. Again, your feedback really does help us shape how we build.

I think there is a fundamental contradiction here.

If this is positioned as a security-first device, then incomplete core functionality becomes a paradox. Security products are expected to be more complete and self-contained, not less.

Many of us are long-time users of Passport Core, and we see Prime as the next-generation evolution. Core did not depend on Envoy for essential usage — even features like backups were fully user-controlled. We could export and store backups independently on secure media.

With Prime, that level of user sovereignty is reduced. And the justification that Envoy / QL is required for things like displaying BTC price or generating TOTP codes feels… honestly, a bit hard to accept. Those don’t seem like strong enough reasons to introduce such a dependency layer.

From the outside, it feels like the product is being shaped around the QuantumLink / Envoy architecture, rather than around first principles of self-custody and sovereignty.

I understand there is a bigger vision here — especially around integrations and apps — but it seems like the foundation is being compromised in the process.

For many of us, the expectation is simple:
the device itself should be fully usable, verifiable, and complete — even in a fully offline, air-gapped context — without meaningful trade-offs.

Right now, it feels like that baseline hasn’t been met yet.

Another key concern is execution speed.

The roadmap sounds great, but the actual delivery has been slow. If many of these issues are “just software,” then they should be resolved much faster — especially when they affect core functionality.

At the end of the day, you’re asking users to trust this device with highly sensitive security data. That kind of trust cannot be built on plans or promises — it has to come from a product that is already complete and reliable today.

Otherwise, it’s hard to justify moving critical data onto a platform that still feels unfinished.

As the saying goes: people don’t judge by what is promised, but by what is delivered.

On the Core-as-baseline framing

Prime isn’t the next generation evolution of Core. It’s the next device we’ve built, but it’s intentionally a different product with a different architecture, threat model, and target user. We wrote about exactly this transition, and why we moved on from QR air-gapping, in our blog. Worth reading in full for the reasoning, but the short version: QR air-gapping is strong security that asks a lot of the user, and that friction is a meaningful reason self-custody adoption stays where it does.

Prime is a different beast. It’s built around the premise that some users want capabilities a pure air-gapped device categorically cannot provide, like simple ‘one-tap’ recoverability, an app surface, and account-style integrations. QuantumLink exists because those features exist and you’re absolutely right that we intentionally shaped the architecture like this. QL itself is designed to give you airgap-like security over a wireless channel, with a dedicated Bluetooth chip physically isolated from the security processor and quantum-resistant encryption on everything that crosses it. We are only just scratching the surface of what this combo can achieve. We continue to operate on open standards for seeds, Shamir Sharing, and continue our unrelenting dedication to open source and reproducibility.

On your point that the device should be fully usable, verifiable, and complete in an offline air-gapped context: it is, with the exceptions I mentioned where the protocol simply doesn’t allow for an air-gapped equivalent. 2FA is the obvious example. TOTP requires synchronised time and a shared secret exchanged with a remote service, that’s how the protocol works, there’s no air-gapped version of it. Same logic applies to anything else that depends on a connected channel by definition. But for the operations that don’t have that constraint, signing, multisig, seed handling, address verification, you can use Prime fully offline. That path is intact and supported.

On execution speed:

Fair to hold us to delivery, and fair to be impatient, but when you build entirely new operating systems, communication layers, and hardware, all with a small team, things take time.

We had to make some tough decisions to postpone certain features in order to get Prime shipped. The alternative was holding the launch indefinitely, which would have been the wrong call. The device in people’s hands today is a stronger foundation to iterate on than chasing the carrot of perfection.

As a user, I don’t think it’s necessary for me to debate product direction or architecture choices.
I simply want to understand a few practical things:

  1. At the current stage, how can users perform backup and recovery without relying on Envoy?
    Is there a way to export the backup file (e.g. settings.tar) and store it independently on a secure medium, similar to how Core handled backups?

  2. Is it possible to perform backup without relying on NFC cards at all?
    In other words, can the entire backup and recovery flow be fully user-controlled and hardware-independent?

  3. Also, why isn’t a standard, well-audited encryption format used for backups — for example something like 7z with AES-256 encryption?
    From a user perspective, that would be more transparent, verifiable, and interoperable.

From a security standpoint, backup and recovery are foundational, so I’d really appreciate clarity on how this is intended to work today.

For a security-first product, this part feels more critical than any higher-level features.

  1. Backup and offline storage, yes. Menu > Backups > Advanced Backups > Settings & Data Backup. Recovery via this manual method is currently scheduled for v1.3.0 release.
  2. Yes. Choose the advanced option during onboarding and choose ‘Seed Words’.
  3. Prime backups use AES-256 (CBC mode) for encryption, so the underlying cipher is the same industry standard you’re suggesting. The key is deterministically derived from your device seed using SHA-256, a fresh random IV is generated per backup, and the AES operations run through the device’s dedicated hardware crypto engine for better security isolation. The reason we use this approach rather than something like 7z is that the encryption key is tied to your seed, so any device restored from the same seed can decrypt the backup automatically without you needing to create or remember a separate password.