Synced Passkeys vs Hardware Keys for Your Identity Vault

Synced passkeys and hardware keys both unlock your CardanoWall identity vault, but they optimize for different things. A synced passkey is usually the better daily choice, because it follows you to a new phone or laptop through your passkey provider. A hardware key is usually better for high-value identities, because it is device-bound and physically controlled.

Either works as a vault unlock factor when your browser, operating system, and authenticator support the WebAuthn PRF extension. And in both cases the unlock factor is convenience, not custody: your real identity is the Identity Seed.

What is a synced passkey?

A synced passkey is a passkey that your provider makes available across your devices.

That provider might be built into your operating system, your browser, your password manager, or a platform account. The benefit is obvious: get a new device, sign in to the same provider, and the passkey is already there.

For CardanoWall this makes daily use easy. You sign in, approve the passkey prompt, and the encrypted identity vault opens — no typing the Identity Seed.

The tradeoff is that you inherit the security and recovery model of whatever provider syncs the passkey. Its account protection, its multi-device recovery, and its failure modes become yours.

What is a hardware key?

A hardware key is a physical authenticator — a USB, NFC, or BLE security key you hold in your hand.

A device-bound hardware key does not sync to new computers on its own. To unlock with it, you need the physical key present. That is the point: the credential cannot quietly exist somewhere you did not put it.

Hardware keys are a good fit for sensitive identities:

newsroom or whistleblower intake identities;
legal and evidence identities;
high-value company identities;
production API or gateway-operator identities;
any identity that should not depend on consumer cloud sync.

The tradeoff is operational. Lose the key, and you fall back to another registered factor or to the Identity Seed.

One practical caveat: PRF support for roaming USB/NFC keys is less uniform than for platform passkeys. As of early 2026, Safari on macOS and iOS does not reliably pass PRF data to roaming authenticators, so on Apple devices a hardware key may not be usable as a vault factor even when a platform passkey is. Expect to test a hardware key before relying on it, rather than assuming it will work everywhere.

Which one is more secure?

It depends on your threat model — there is no single winner.

Synced passkeys are excellent at resisting phishing and password-database breaches, and they reduce the chance you lose access when a device dies. Hardware keys give stronger control over where the credential can exist, which suits teams that need physical custody, asset tracking, key ceremonies, or a clear policy about who can unlock a shared identity.

Both convenience and control are security properties. Losing access is a security failure too. The best choice is the one you can actually operate correctly under pressure.

How does CardanoWall use them?

As vault unlock factors — never as the identity itself.

Your CardanoWall identity is the Identity Seed: one 32-byte secret from which every key is derived. A passkey or hardware key does not replace that seed. It unlocks the encrypted vault that holds it for your account, so you can sign in on a new device without re-typing the seed each time.

The vault is one age-encrypted ciphertext, addressed only to your WebAuthn-PRF factors — one stanza per registered passkey or hardware key. There is no password-derived stanza to brute-force and no public-key stanza for a future quantum attack to target; the relevant exposure is Grover-style search against 256-bit symmetric keys, which leaves roughly a 128-bit effective margin. The service holds the ciphertext but cannot decrypt it. If a factor can produce the required PRF output during the browser ceremony, it can open the vault; if it cannot, CardanoWall should not enroll it. For more on what that design protects against, see how passkeys protect your identity vault.

This is why capability detection matters before you commit to a factor.

Why does PRF support matter?

Because not every passkey can unlock an encrypted vault.

Plain WebAuthn can prove who you are to a website. Opening the vault needs more: the authenticator must hand the browser key material to decrypt the local ciphertext. That extra capability is the WebAuthn PRF extension, and support for it varies across browser, operating system, and authenticator.

CardanoWall feature-detects PRF before enrolling a factor rather than guessing from the browser name, and it will route you to the seed-only path if your setup can't do PRF. That path is not a degraded mode — it is the portable foundation. The Identity Seed works on any device, in any conformant tool, with no provider and no service in the loop.

What should normal users choose?

Usually a synced platform passkey.

For an everyday personal identity, a synced passkey is the best tradeoff: easy to use, easy to recover across devices, and it keeps you from pasting your seed all the time. A sensible setup looks like this:

save the Identity Seed in a password manager or a secure offline place;
add one synced platform passkey;
add a second factor if you use several devices;
avoid unlocking high-value identities on machines you don't trust — if you must, use a public-computer mode that persists nothing.

The passkey is convenience. The seed is recovery and portability. Save the seed regardless of which unlock factor you pick.

What should teams choose?

Hardware keys plus documented seed custody.

Teams usually care less about casual convenience and more about control. A team identity may be shared on purpose, but shared-on-purpose is not the same as easy-to-copy-silently. A reasonable team setup:

two hardware keys held by different responsible people;
a printed Identity Seed in a safe;
a written access policy;
a rotation procedure for when custody changes;
a separate identity per major workflow;
deactivation of identities that should no longer sign.

One honest limit for shared identities: anyone who holds the seed can sign and decrypt as that identity. Hardware keys protect vault access on a given device; they do not make a shared seed partial or revocable. If the seed itself has been handed around, control over it is gone — that is a property of the seed, not of the unlock factor.

What happens if you lose one?

Use another factor, or fall back to the seed.

If you lose a synced device but still have the passkey provider on another device, you can usually carry on. If you lose a hardware key, remove that factor: the vault re-encrypts to your remaining factors and the old ciphertext is hard-deleted. If every factor is gone, the Identity Seed is the recovery path. And if all of them are gone, future use of that identity is gone too — but everything it already published still verifies forever from public data alone.

Removal is real revocation for the current vault, but it is not retroactive — it is service-layer control, not a time machine. If a factor may have been stolen and used before you removed it, treat the situation as a possible seed compromise: removing the factor stops it from opening the re-encrypted vault, but it cannot undo any prior use. The right response to a suspected seed compromise is a new identity plus deactivating the old one, not a reset. The lifecycle for that — active, deactivated, deleted — is its own topic.

The short version

Synced passkeys are convenient and roam across devices. Hardware keys are more controlled and stay where you put them. CardanoWall can use either as a vault unlock factor when WebAuthn PRF is available.

For everyday personal use, a synced passkey is usually right. For high-value or team identities, hardware keys can be worth the extra ceremony — where PRF works with them. In every case, save the Identity Seed: the passkey unlocks the vault, but the seed is the identity.