What Is MPC Authentication? Multi-Party Computation Explained for Banks

Multi-party computation, or MPC, is a cryptographic technique that lets several parties jointly compute a result without any of them ever seeing the whole secret involved. Applied to authentication, it means this: the private key that proves a user's identity is split into shares, the shares are held separately, and a complete key never exists anywhere, at any moment, including while authentication is happening.

That last clause is the one to sit with. Not "the key is encrypted at rest," not "the key is stored in protected hardware." The key, as a complete object, never exists. There is nothing whole to steal.

The intuition, without the math

Picture the two-operator launch key from every submarine movie. Two keys, two people, physically separated, and the system only fires when both turn together. Neither operator can act alone, and stealing one key gets an attacker nothing.

MPC authentication works on the same principle, with one improvement the movies never had: the two shares never combine into a single key, even at the moment of use. The computation itself is joint. Each side contributes its share to a cryptographic protocol, and the correct signature comes out the other end without either side, or any point in memory, ever holding the assembled secret.

Why this matters for authentication specifically

Every credential system has to answer one hostile question: where does the secret live, and what happens when that place is compromised?

Password systems answered "in the user's head and the server's database," and decades of breaches graded that answer. Device-stored keys answered "in one protected place on the device," which is far better, but it concentrates everything on one location staying unbroken. History is not kind to single locations.

MPC changes the shape of the question. A device share alone is useless. A server share alone is useless. An attacker now needs to simultaneously compromise separately held shares, across separately controlled environments, within the same authentication window. The single point of theft that every previous architecture had, in some form, is gone from the design rather than defended harder.

MPC in Passkeys+: how ZSM applies this

Passkeys+ uses MPC as the foundation of device binding, running on ZSM, Ideem's Zero-Trust Secure Module. When a passkey is enrolled, the private material is split at the moment of creation. There is never a pre-split, complete key that must be protected during some vulnerable setup phase; the credential is born divided.

The result is a phishing-resistant, cryptographic credential with a property standard passkeys do not have: it is mathematically tied to the enrolled device. A share copied off the device authenticates nothing, because its counterpart will not compute with an impostor. And because the guarantee is mathematical rather than physical, it holds on any device, without depending on any single component of that device being present or unbroken.

To the user, none of this is visible. Enrollment and authentication feel like an ordinary passkey ceremony: unlock, done. The cryptography is the invisible kind, which is the only kind users tolerate.

And for the evaluators who need more than a description: the MPC claim in ZSM is not self-attested. ZSM is FIPS 140-3 certified, the same NIST standard used to validate hardware security modules, which means an accredited laboratory examined the cryptographic implementation itself rather than taking the architecture diagram's word for it. It carries that validation as pure software, delivering hardware-grade key protection on any device with no dependence on a secure enclave being present or trustworthy, and it operates under SOC 2 controls. When a bank's security team asks whether the split-key story survives independent scrutiny, the certification is the answer, and it is on the table before the first architecture call.

What to ask any vendor claiming MPC

MPC has become a fashionable word, and fashionable words attract loose usage. Questions that separate substance from decoration (there is a broader version of this exercise in how banks vet passkey providers):

Does a complete key ever exist, even transiently? Some implementations assemble the key briefly at signing time. That moment of assembly is exactly the attack surface MPC is supposed to eliminate. The correct answer is never.

What does one compromised share yield? The correct answer is nothing usable, with a mechanism for share rotation if a compromise is suspected.

Is the MPC protecting the credential, or something off to the side? Some products use MPC for internal secrets while the user credential itself sits whole somewhere. Ask specifically what is split.

What happens on a lost or replaced device? Re-enrollment should run through the institution's own verification stack, not through a cloud account's recovery flow. (Institutions that enroll credentials during onboarding via the KYC Passkeys pattern already have that verification moment defined.)

A vendor with real MPC underneath will enjoy these questions. That is a useful signal by itself.

The short version

MPC authentication removes the assumption every breach depends on: that somewhere, there is a whole secret to find. Split the key at birth, never assemble it, and the attacker's job changes from finding one thing to simultaneously defeating separate environments that were designed never to meet. For the full picture of how this powers device binding in Passkeys+, see What's Actually Inside Passkeys+, or see it running live: book a demo. If you want the evidence first, start with the security report.