A passkey held by your auth vendor isn't really yours.
The day you leave — keys invalidated, every user re-enrolls from zero.
Own your passkeys from the start — and keep your options open.
A passkey is a public/private key pair that replaces a password. What varies — enormously — is where
the private key lives, whether it can leave the device, and who can copy it.
TwinShield supports all three and lets your policy decide which is allowed for which action.
Generated inside the device's secure hardware. The private key is non-exportable — it cannot be copied, synced, or extracted, even by the operating system. Bound to one device, released only by on-device biometric.
Held in the operating system's keystore rather than secure hardware. Stays on one device and is not synced — but it is software-held, so it does not carry the hardware guarantee that the key can never be extracted.
The convenient one — synced across a user's devices through a cloud account (Google Password Manager, iCloud Keychain). Easy to recover, easy to share. But the key now lives wherever that cloud account reaches, and its security inherits that account's.
No two businesses share the same security needs. TwinShield's policy approach lets each app owner design their own security level — passkeys included: three types, your call.
An outsourced auth provider can register passkeys for your users — and many do. The detail rarely made obvious: those passkeys are registered to the vendor's domain and stored in the vendor's system. They work beautifully — right up until you want to leave.
A passkey is cryptographically tied to the relying party it was created for. Register through a vendor, and migrating off means every user must re-enroll — across your entire base.
That is the quiet lock-in. Not a contract clause — a property of where the credential was rooted. The more users adopt passkeys under a vendor, the more expensive leaving becomes.
A credential you cannot take with you was never fully yours. TwinShield roots every passkey inside your environment.
TwinShield issues passkeys under your relying-party identity, verified against keys held on your auth server. The hardware-bound type is rooted in the device's secure hardware; the public key sits in your vault. No vendor relying party sits in the middle.
Because the policy engine decides which passkey type satisfies which action, you are not forced to pick one model for the whole app. High-value transfer — require Type 01. Routine login — accept Type 03. Change the rule with a policy toggle, not an app release.
The result: passkeys with the convenience users expect, the hardware strength a regulated app needs, and none of the lock-in that comes from letting someone else own the keys.
If you are evaluating passkeys for a mobile product — and want to keep the credentials yours — we should talk.
Talk to us →