Split Microsoft 365 keys
Every key lives as shards on independent nodes. Applications use a familiar KMS interface, and no cloud provider, operator or host ever holds a complete key.
No single point of compromise
One stolen shard cannot sign or decrypt. Two of three shards act together, and the key is never reconstructed.
No hardware to run
No HSM to rack, patch, renew or outgrow. Shards run in one cloud, several clouds or on-premises.
Accountable by design
Every key operation is traceable to a named requester, under the policies and audit trail of the Cockpit.
2-of-3 threshold signing.
A request reaches all three shards; any two produce a valid signature together. The private key is never assembled in memory, on disk or on the network.
- If one node is down or compromised, the key stays usable and unexposed.
- The same model protects signing and decryption.
The key never exists whole, not even at birth.
Independent parties compute their own shard during generation, so no single party, including DuoKey, ever observes the private key.
- Rotation and revocation replace shards without reconstituting the key.
- No export ceremony, no key backup to guard as a single file.
Shards where your policy wants them.
Run the nodes in one cloud, across several, in separate data centres or in a mix of cloud and on-premises, ideally with a different team per node.
- No single administrative team can act alone.
- HSM or software vaults stay available in the same Cockpit when a rule requires them.
Every operation, on the record.
Applications authenticate as named requesters, and every sign, decrypt, rotate and revoke lands in the Cockpit journal.
- Access policies by user, application and context.
- Evidence for DORA, NIS2 and ISO 27001 audits from one place.
How it actually works
2-of-3 threshold signing: the full key is never assembled
A sign request reaches all key shards at once, but only two need to respond to produce a valid signature. No shard, agent, operator or cloud provider ever holds enough of the key to act alone, and the combine step never reconstructs the full private key in memory, on disk, or on the network. Steal one shard and you have nothing usable.
- No single point of compromise: one stolen shard cannot produce a valid signature
- No HSM hardware to rack, patch, renew or run out of capacity
- Works the same way whether the shards sit in one cloud or three
- Every signature traceable to a named requester, not a shared service credential
One key layer behind your cloud, SaaS and databases.
The same MPC keys back the Cockpit integrations, so every external key store and database encryption uses keys no provider holds.
- Microsoft 365 DKE, AWS XKS, Salesforce, Snowflake and Azure EKM.
- SQL Server and Oracle TDE, OpenBao and HashiCorp Vault, KMIP and PKCS#11 clients.
Key features
Distributed key generation
Shards are created independently; the private key is never formed.
Threshold operations
2-of-3 signing and decryption with no reconstruction step.
Familiar KMS interface
Applications call a standard KMS API, KMIP or PKCS#11 instead of handling shards.
Post-quantum keys
ML-KEM and other post-quantum keys managed next to RSA, EC and AES keys.
Policies and quorum
Access policies and M-of-N approval on sensitive key actions.
HSM when required
Keys in an HSM or software vault managed with the same policy and audit trail.
Deploy the KMS your way
The same Cockpit as a service, in your own infrastructure or across both, with the shards wherever your policy requires.
Praxisbeispiele
Wo Teams das einsetzen
Tiefenanalysen
Leitfäden für Ihr Programm
FAQ
MPC KMS, explained
An MPC KMS is a key management system that uses multi-party computation: each key is split into shards held by independent nodes, and the nodes sign or decrypt together. The complete key is never assembled, not at generation and not during use, so no single node, operator or cloud provider can use or leak it alone.
A request reaches all three key shards, and any two of them produce a valid signature together. One shard on its own cannot sign, and the combine step never reconstructs the private key in memory, on disk or on the network. If one node is down or compromised, the key stays usable and unexposed.
A cloud KMS keeps the key under the provider's control, and an HSM keeps the whole key inside one appliance. An MPC KMS removes that single holder: the key exists only as shards spread across independent parties. HSMs still fit where a rule requires a specific certified hardware module.
Yes. Key generation and threshold signing run with MPC, and DuoKey Cockpit can also manage keys held in an HSM or a software vault when a customer needs one, with the same policy and audit trail.
The shards can run in one cloud or across several, in separate data centres, or in a mix of cloud and on-premises nodes, ideally with a different administrative team per node so no single team can act alone.
Keys your cloud never fully holds.
See threshold signing in your own environment, with keys that are never assembled on any side.