What's Actually Inside Passkeys+

Passkeys+ is a composite authenticator: MPC-based device binding as the foundation, and a standard passkey built on top of it. That is the whole product in one sentence, and the order of those two layers is the point. This post makes every word concrete: what the binding foundation does, what the passkey layer adds, why multi-party computation is the mechanism underneath, and which failure modes each layer does and does not close.

"We deployed passkeys" has become one of the least informative sentences in security. The protocol is phishing-resistant and cryptographic, and that part is real. But two deployments of the same protocol can have wildly different security properties depending on what the credential sits on. The plus is the foundation underneath.

The foundation: MPC-based device binding

Device binding means a credential is cryptographically tied to one specific device and cannot be exported, synced, shared, or replayed from anywhere else. In Passkeys+, binding is the base layer, and it is built on multi-party computation, running on ZSM, Ideem's Zero-Trust Secure Module.

The idea, without the math: the cryptographic secret is split into shares held by separate parties, and the complete key never exists anywhere, at any point, including during authentication. The device holds a share. The share is useless alone. Authentication is a joint computation between the shares, and it only succeeds when the genuine, originally bound device participates.

What the foundation buys, concretely:

No complete key to steal. Malware that fully compromises the device still cannot extract a whole private key, because a whole private key never exists on the device.

No sync path. A bound credential cannot travel through a cloud keychain, so cloud account recovery is not a route to the credential.

No sharing path. A bound credential cannot be handed to another person or added to another phone. This matters more than it sounds, and the next section is about why.

No replay from other hardware. A credential copied byte-for-byte off the device does not authenticate from anywhere else, because the counterpart share will not compute with an impostor.

What distinguishes ZSM from a generic MPC library is that it delivers this as a certified module, not a math technique. ZSM is FIPS 140-3 certified, the standard used to validate hardware security modules, and it provides hardware-grade key protection as pure software on any device, without depending on a secure enclave being present, accessible, or trustworthy on that device. Dedicated secure chips try to make key extraction physically impossible; ZSM makes it mathematically impossible, on every device your users actually own, and carries the certification to prove it. The full architecture is on our technology page.

The passkey on top

On that foundation sits a passkey exactly as the WebAuthn standard defines it. A public-private key pair replaces the password. The private key never crosses the network and cannot be typed into a fake login page, so credential stuffing, password reuse, and harvest-and-replay phishing pages are eliminated as categories. The server stores only the public key, which is useless to steal.

Because the passkey is built on the bound foundation rather than on a cloud keychain, it inherits the foundation's properties. The key material lives as MPC shares from the moment of creation. There is never a complete, portable credential that binding gets applied to after the fact. The credential is born bound.

This is what composite authenticator means: not a passkey with a feature bolted on, but a passkey whose key material is generated, held, and exercised inside the binding layer. The user sees an ordinary passkey ceremony. Relying parties see standard WebAuthn. The foundation is invisible at the moment of use, which is exactly where security infrastructure should be invisible.

The gap this closes: passkeys can be shared

Here is the uncomfortable fact about standard synced passkeys that most passkey marketing skips: they are shareable by design. Consumer platforms let a user send a passkey to another person or add it to another device. The recipient then authenticates with their own face or fingerprint, because the biometric in a passkey ceremony proves that a person is present on the device holding the credential. It has never proven which person.

Play that forward in a fraud scenario. An attacker does not need to phish the passkey. They need to convince the account holder to share it, or to take over the cloud account it syncs through and receive it on hardware they control. Both of those are social engineering problems, and social engineering is the one attack category the passkey protocol does nothing about. Once the credential lands on the attacker's device, every subsequent login is cryptographically flawless and completely fraudulent. The ceremony is phishing-resistant. The credential was simply given away.

For a consumer streaming account, shareability is arguably a feature. For a bank account, it is the gap. We have written about the synced passkey tradeoff from the control angle and in a direct banking comparison; the short version is that a credential that can travel inherits the weakest link of everywhere it can travel to, including the judgment of a customer on the phone with a convincing scammer.

Device binding as the foundation closes this completely. A Passkeys+ credential cannot be shared, cannot be AirDropped, cannot sync to a device the attacker controls, and cannot be surrendered even by a fully cooperative victim. There is nothing to hand over. The social engineering attack does not fail; it never becomes possible.

What the plus does not claim

Boundaries, stated plainly, because a security audience should trust nothing that claims everything.

Device binding does not verify identity. It guarantees the credential only works from the bound device; who enrolled that device is a question for your onboarding and verification stack. If you want the credential's issuance tied to your strongest verification moment, that is the KYC Passkeys pattern: enroll the passkey during onboarding itself, while your SNA provider's possession check is fresh.

Binding does not make the rest of your deployment correct. Fallback flows, recovery paths, and relying-party configuration still determine real-world security, and weak recovery can undermine strong credentials. Independent researchers tested 103 live passkey deployments and found that deployment decisions, not the protocol, are where security is won or lost. We ran our own deployment against the same standard and published what we found, including the findings that were not flattering, in the security report.

The one-sentence version, again

MPC-based device binding removes the credential's ability to exist anywhere except the device you bound it to. The passkey on top removes the password and the phishing surface. Passkeys+ is both, as one composite authenticator, and the plus is the difference between deploying the protocol and deploying it the way high-stakes accounts require.

If you want to see the binding layer running, book a demo. If you want the evidence first, the security report is the unvarnished version.

Deep dives on each layer: What Is Device Binding, and Why Passkeys Don't Include It by Default and What Is MPC Authentication? Multi-Party Computation Explained for Banks.