Moving Beyond HSMs and Master Keys: An IT and CISO Guide to Multi-Party Computation (MPC)
Infrastructure and security leaders do not always know Multi-Party Computation (MPC). Here is how distributed compute and threshold cryptography offer a flexible alternative to expensive HSMs—and remove the single point of failure in critical systems.
Also available in Hebrew.
For decades, infrastructure security rested on a simple axiom: if you have a sensitive encryption key, root password, or business-critical operation, lock it in the strongest vault you can buy. That meant heavy reliance on dedicated Hardware Security Modules (HSMs), strict multi-factor authentication, and rigid role-based access control (RBAC).
As architectures shift toward multi-cloud, hybrid work, and shared data processing, IT leaders and CISOs hit an unavoidable paradox:
- Hardware cost and vendor lock-in: Physical HSMs, complex licensing, and synchronisation across clouds drive high CapEx and operational friction.
- The single point of failure illusion: Even with strong controls, a master encryption key or privileged root/CISO credential can still be exposed—through human error, social engineering, or a malicious insider.
- Limited protection for data in use: Classical encryption protects data at rest and in transit well, but computation, analytics, or signing requires decrypting keys or data into server RAM.
A mature technology that started in academic research and now runs in production at leading organisations offers a different paradigm: Multi-Party Computation (MPC).
What is MPC? (A practical view for infrastructure teams)
Multi-Party Computation lets multiple servers or organisations jointly compute a function over their inputs without any party learning the others’ inputs—and without relying on a trusted third party.
Instead of “store the whole key in one vault,” MPC uses threshold cryptography and secret sharing:
- Secrets are never created or stored as a full key in one place.
- Material is split into independent key shares.
- To sign, approve access, or decrypt, servers run a joint protocol; each contributes only its share.
- Outcome: The operation succeeds, but the full key is never reassembled in any server’s memory.
[AWS server (share A)] <---+
|---> [MPC protocol] ---> [Approved signature / result]
[Azure server (share B)] <--+ (no full key reconstruction)
|
[On-prem server (share C)] <-+
Three scenarios where IT should evaluate MPC
1. A flexible, cost-effective alternative to cloud HSM (virtual cloud HSM)
Many infrastructure teams are stuck with hardware maintenance and licensing. In multi-cloud, it is hard to make one vendor’s HSM (e.g. AWS CloudHSM) talk securely and quickly to apps on Google Cloud or Azure.
The MPC answer:
Software-based distributed KMS. Spread key shares across regions and providers. Security does not depend on a single physical enclosure—it depends on an attacker having to compromise several isolated cloud environments at once.
2. Securing root: what if the CISO password or admin account is compromised?
A core CISO fear is “master key compromise”: a privileged insider, phishing against a network admin, or a stolen session token.
The MPC answer:
Remove the single point of failure with a threshold scheme (e.g. 2-of-3 or 3-of-5):
- No person, admin, or lone server can perform a critical crypto operation alone.
- If an attacker owns a CISO laptop or steals one share, that share alone has no cryptographic value.
- Policy requires additional servers or approvers to participate in the computation.
3. Cross-organisation analytics without raw data leakage
Data and product teams often need to match datasets with partners (e.g. banks detecting shared fraud patterns, or healthcare research on patient records), while GDPR, HIPAA, and privacy law block shipping raw files.
The MPC answer:
Protocols such as Private Set Intersection (PSI) return only the agreed result (e.g. overlap size or a fraud signal) without either party seeing the other’s database.
Technical comparison: traditional HSM vs cloud KMS vs distributed MPC
| Architectural factor | Traditional physical HSM | Single-vendor cloud KMS | Distributed MPC / virtual KMS |
|---|---|---|---|
| Security model | Physical isolation (FIPS) | Cloud provider IAM | Mathematical distribution (threshold crypto) |
| Single point of failure | Yes (hardware breach/loss) | Yes (cloud root account) | Principally eliminated (no full key on one host) |
| Multi-cloud flexibility | Very low; physical coupling | Tied to one provider | Software running on any cloud or on-prem |
| Cost and scale | High CapEx, long lead times | Consumption-based OpEx | Elastic software model |
| Malicious insider | Mostly procedural controls | Mostly IAM policy | Cryptographic quorum required |
Questions infrastructure architects ask about MPC
Doesn’t network latency make MPC too slow?
Early MPC protocols were chatty on the wire. Modern libraries and MPC-based ECDSA and EdDSA signing often complete in milliseconds. For enterprise key management and most signing workloads, latency is negligible compared to resilience and security gains.
How is MPC different from fully homomorphic encryption (FHE)?
FHE lets you compute on encrypted data on one machine but with orders-of-magnitude CPU overhead. MPC splits work across machines; cost is mainly networking, not compute—which is why MPC is production-ready today for many use cases.
Are key shares personal data under privacy regulation?
A properly generated share does not contain full entropy and cannot reconstruct the secret alone. It is generally not treated as PII, and a leak of one share does not by itself breach the organisation.
Summary: practical next steps
If you are planning security architecture for the next few years:
- Map single points of failure: Where do master keys live? Could one compromised account halt the business?
- Review HSM economics: Do renewal and hardware costs match a multi-cloud strategy?
- Pilot virtual, MPC-based KMS: Try distributed key management in staging and compare operational ease with security posture.