What Is Device Binding, and Why Passkeys Don't Include It by Default

Device binding is the property that a credential is cryptographically tied to one specific device: it cannot be exported, cannot sync to other devices, and cannot be used from any hardware except the device it was created on. A bound credential stolen byte-for-byte is worthless anywhere else.

Most passkeys deployed today do not have this property. That is not an oversight. It is a deliberate ecosystem choice, and understanding the choice is the fastest way to understand when you need to override it.

The choice the ecosystem made

When passkeys replaced passwords, the designers faced a real problem: if the credential lives on exactly one device, losing that device means losing the account. For billions of consumer users, that failure mode is worse than the security it buys. So the major platforms made passkeys syncable. Create a passkey on your phone and it propagates through your cloud keychain to your laptop, your tablet, and any future device you sign into.

For consumer accounts, this was the right call. Recovery is graceful, adoption is easier, and the authentication ceremony itself remains phishing-resistant and cryptographic on every device the passkey reaches.

But notice what the credential's security now depends on: the cloud account it syncs through. The keychain's own recovery flow. Every device the credential lands on, including the old tablet with the outdated OS. The credential is only as secure as the weakest point in its travel itinerary.

Why attackers love portable credentials

A synced passkey cannot be phished at the login page. So attackers stopped attacking the login page.

The productive target is now the sync fabric itself, and above all, account recovery. Social-engineer a cloud account reset, add an attacker-controlled device to the account, and the keychain helpfully delivers the synced credentials to it. No cryptography was broken. Every individual component worked as designed. The system as a whole handed the keys to the wrong person, because the system was designed to hand keys to new devices smoothly.

For a streaming account, this risk is acceptable. For an account that can move money, approve transactions, or change a customer's registered contact details, the calculus inverts. High-stakes accounts need the credential itself to be immovable, not just unphishable.

What binding changes

A device-bound credential collapses that entire attack surface:

Nothing to sync. The credential never enters a cloud keychain, so keychain recovery flows are not a path to it. The most productive attack route against synced credentials does not connect to anything.

Nothing to export. The credential cannot be backed up off the device, copied to a new phone during migration, or extracted by anything that reads device storage.

Nothing to replay. Even a perfect copy of the credential's bits does not authenticate from other hardware. The binding is not a policy flag that well-behaved software respects; it is a cryptographic property of how the credential operates.

The trade, honestly stated: bound credentials require a deliberate answer for device loss and replacement, because the graceful consumer sync path is intentionally gone. Institutions handle this with re-enrollment flows tied to their own verification stack, which puts recovery back under the institution's control rather than the cloud provider's. For a bank, that is usually the point rather than a drawback: recovery becomes an event the institution verifies, not one a platform's support flow decides. (Tying enrollment itself to the institution's strongest verification moment is the KYC Passkeys pattern.)

How Passkeys+ does binding: MPC instead of a chip

The traditional way to bind a credential is to lock the private key inside a dedicated secure element on the device. It works, but it ties your security to specific hardware being present, current, and unbroken, and it still means a complete private key exists in one physical place.

Passkeys+ binds credentials with multi-party computation instead, running on ZSM, Ideem's Zero-Trust Secure Module. The private material is split into shares at the moment the credential is created, and a complete key never exists anywhere, at any point, including during authentication. The device holds a share that is useless alone; authentication is a joint computation that only succeeds when the genuinely bound device participates.

The practical consequences: malware that fully compromises the device still has no complete key to steal, because one never exists there. The credential works on any device, with no dependence on any single hardware component. And the result remains a phishing-resistant, cryptographic credential that behaves like a normal passkey to the user: unlock, done, nothing to type.

When binding matters

Device binding is not a universal requirement, and claiming otherwise would be the kind of vendor absolutism this topic attracts too much of. The question is what the account can do.

Accounts that move money, approve high-value transactions, hold sensitive balances, or serve as the recovery root for other accounts need credentials that cannot travel. Banking, payments, brokerage, crypto custody, and the internal tools of institutions in those businesses are the obvious list. If a compromised login costs real money within minutes, the credential should be bound.

For everything else, synced passkeys remain a large upgrade over passwords, and deploying them is still the right move.

The one-line summary

Standard passkeys made credentials unphishable. Device binding makes them immovable. High-stakes accounts need both, and the second one does not come by default.

For the full picture of how binding fits into the rest of the architecture, see What's Actually Inside Passkeys+. To see a bound credential enrolled and authenticated live, book a demo, or start with the evidence in the security report.

REVIEWER NOTES (delete before publish): 1. [GRAPHIC A2-1] goes after "Why attackers love portable credentials": two-panel comparison, synced passkey traveling through cloud to many devices vs. bound credential tied to one device. 2. Links added across the CMS: missing-layer post, convenience-vs-control, device-bound-vs-synced banking comparison, KYC Passkeys, A1, A3, technology page, invisible-immutable post, demo, security report. A1 (/post/whats-inside-passkeys-plus) and A3 (/post/mpc-authentication-explained) are still unpublished drafts, so those two links 404 until they go live. 3. ZSM spelled out as Zero-Trust Secure Module for consistency with A1. 4. No external stats by design; if we later cite recovery-flow attacks it must be a verifiable named source.