Multi-Party Threshold Cryptography for Sovereign Key Authority

Multi-party threshold cryptography is a cryptographic protocol family in which a private key is never held in complete form by any single party. Instead, a secret is mathematically split into shares distributed across independent nodes, and a configurable minimum number of those nodes (the threshold) must cooperate to perform any signing or decryption operation. For European public-sector bodies, financial institutions, and healthcare organisations that must keep sensitive data out of reach of foreign jurisdiction, this architecture removes the single point of compromise that makes a centralised key store, whether a cloud-managed HSM or an on-premises appliance, a systemic risk.

Why a Centralised HSM Is Not Enough

A hardware security module provides strong tamper resistance, but the trust model remains centralised: whoever holds administrative credentials, or whoever controls the jurisdiction in which the HSM sits, can compel or coerce a signing or decryption operation. Under the US CLOUD Act, a US-controlled cloud key management service can be served with a warrant that requires disclosure without notifying the data subject. A single on-premises HSM offers no protection against an insider threat with administrative privilege.

Threshold cryptography changes this risk model fundamentally. A (t, n) threshold scheme distributes key shares across n nodes and requires at least t of them to cooperate. If t is set to 3 and n to 5, an attacker or a foreign government must simultaneously compromise three independent, geographically separated nodes under different administrative and legal jurisdictions to extract any cryptographic material. NIST describes the core security property precisely:

“A threshold scheme ensures that the compromise of any single party does not reveal the secret key, and that the scheme remains secure as long as fewer than the threshold number of parties are corrupted.” (NIST, MPTS 2019 Proceedings, https://csrc.nist.gov)

The NIST MPTS 2026 Standardisation Track

NIST’s Workshop on Multi-Party Threshold Schemes (MPTS 2026) is the primary international standardisation effort for threshold cryptography. It directly follows the completion of the post-quantum algorithm suite: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) were all finalised in August 2024. NIST SP 800-227, which provides recommendations for key-encapsulation mechanisms including ML-KEM, accompanies this suite. The threshold extension programme now targets how these algorithms can be used in distributed multi-party settings.

As of mid-2025, NIST has circulated discussion documents on threshold considerations for ML-DSA (FIPS 204) and ML-KEM but has not published a final standard for either. Production-ready threshold PQC standards are broadly expected in the 2026-to-2027 timeframe following the MPTS 2026 workshop. Organisations should not wait: the ENISA guidance on post-quantum cryptography warns explicitly that “adversaries are already harvesting encrypted data today for future decryption,” making hybrid deployments (classical threshold now, PQC threshold layer added once standardised) the prudent approach.

Production-Ready Libraries and Migration Path

Several open-source threshold cryptography libraries have reached a maturity level appropriate for regulated deployments, provided they are paired with an independent cryptographic audit of the specific implementation chosen.

FROST (Flexible Round-Optimised Schnorr Threshold signatures) is codified in IETF RFC 9591 and has multiple audited implementations in Rust and Go. It is a two-round protocol that achieves sub-second signing latency even across geographically distributed nodes when network round-trip times are below 100 milliseconds, making it suitable for document signing workflows in regulated European sectors. Threshold BLS (Boneh-Lynn-Shacham) signatures have been in production use in blockchain infrastructure since 2020 and benefit from an aggregation property that reduces verification overhead. Multi-party ECDSA libraries such as the ZenGo-X implementation have published formal security proofs and are used in production key management contexts.

The migration path toward PQC-safe threshold schemes is a two-stage process. In stage one, organisations deploy a classical threshold scheme (FROST or threshold BLS) today, replacing or supplementing their centralised HSM. This immediately eliminates single-jurisdiction and single-administrator risk. In stage two, once NIST publishes threshold ML-DSA and threshold ML-KEM guidance post-MPTS 2026, the key shares are rotated to the new PQC-based scheme within the same node topology. ISO/IEC 11770-5, which covers group key management mechanisms, provides a formal framework for the key distribution protocols involved in both stages.

Deployment Architecture Across Sovereign Nodes

A practical sovereign deployment for a European regulated organisation typically combines a Swiss-hosted data centre node (benefiting from the revised Federal Act on Data Protection, revFADP, which does not include a CLOUD Act equivalent) with on-premises nodes inside the organisation’s own facilities in one or more EU member states. A fifth node operated by a legally independent Swiss or EU trust service provider completes the quorum without introducing a US-jurisdiction dependency.

Each node stores its key share inside a dedicated PKCS#11-compatible HSM. PKCS#11 v3.0, published by OASIS in 2020, introduced mechanism extensions that allow threshold operations to be exposed through a standard API, enabling interoperability between HSMs from different vendors across nodes. The threshold protocol itself runs as a sidecar process that communicates between nodes over mutually authenticated TLS connections, with traffic protected by a quantum-safe key exchange (ML-KEM) even before the threshold ML-KEM standard is finalised, using a hybrid classical-PQC handshake.

Sub-second signing latency is achievable in this topology. The main latency determinant is the number of protocol rounds and the network path between nodes. FROST requires two rounds of communication; with nodes distributed across Switzerland and two EU locations, round-trip times of 20-40 milliseconds per round are realistic, producing total signing times well under 500 milliseconds. This is sufficient for document signing workflows, certificate issuance, and API request authentication in financial and healthcare systems.

Key Ceremonies, Quorum Revocation and Long-Term Validity

A threshold key ceremony distributes the generation event itself. Using a verifiable distributed key generation (DKG) protocol, each node generates its own share independently, and the shares are combined into a public verification key without any node ever holding the complete private key. The ceremony requires the cryptographically verified or physically witnessed participation of at least one custodian per node and must produce a verifiable secret sharing transcript that proves shares were generated correctly. This transcript is a primary audit artefact.

Quorum-based revocation requires t nodes to agree before a signing key can be revoked and replaced. This prevents a single rogue administrator or a single legal order directed at one node from silently invalidating the organisation’s cryptographic infrastructure. The revocation policy should be encoded in a written quorum agreement that names custodians, substitution rules, and the notification chain required under NIS-2 Article 21 incident reporting obligations.

For long-term cryptographic validity of digitally signed records, European regulations including eIDAS 2.0 and sector-specific archiving obligations in healthcare and finance require that signatures remain verifiable for periods measured in decades. Threshold signing with a PQC-ready migration plan directly addresses this: as algorithms age, the node topology can issue long-term validation tokens (LTV) or timestamp authority countersignatures using the then-current algorithm, without re-signing legacy documents. ISO/IEC 11770-5 group key management provisions support the structured key refresh needed to maintain this continuity.

Evidencing Threshold Key Authority in NIS-2 and DORA Audits

NIS-2 (Directive 2022/2555), DORA (Regulation 2022/2554, applicable from January 2025), and GDPR Article 32 each require that organisations demonstrate technical measures proportionate to risk for protecting sensitive data. A threshold key authority directly addresses the access-control and supply-chain integrity requirements of NIS-2 Article 21(2)(e) and the ICT risk management framework mandated by DORA Article 9.

The audit evidence package for a threshold deployment should contain: the DKG ceremony transcript with verifiable secret sharing proofs, the signed quorum agreement, network topology diagrams showing node jurisdictions, PKCS#11 v3.0 API logs demonstrating that no out-of-band private key export occurred, HSM attestation certificates for each node, and penetration test results covering the inter-node communication channels. This evidence set allows a compliance officer or external auditor to verify that no single administrator, jurisdiction, or hardware failure can compromise the organisation’s root cryptographic trust, which is precisely the claim that NIS-2 and DORA supervisory authorities will scrutinise.

The financial case for investing in this architecture is supported by the scale of breach costs. According to the IBM Cost of a Data Breach Report 2024, the global average cost of a data breach reached USD 4.88 million, the highest figure in the report series. ENISA’s Threat Landscape 2023 found that ransomware and data theft together accounted for more than 50 percent of all significant cyber incidents reported across EU member states. Threshold key authority directly reduces the blast radius of a node-level compromise, limiting exposure to a fraction of what a centralised key store breach would cause.

FAQ

Does threshold cryptography replace an HSM, or does it work alongside one?

Threshold cryptography and HSMs are complementary. Each node in a threshold scheme ideally stores its key share inside a dedicated HSM, so the architecture combines the tamper-resistance of hardware security modules with the distributed trust of a threshold protocol. No single HSM, and therefore no single administrator with access to it, can unilaterally perform a sensitive cryptographic operation.

How many nodes are typically needed for a production threshold deployment in a regulated European organisation?

A 3-of-5 configuration is a common starting point: five nodes spread across at least two jurisdictions (for example, a Swiss data centre plus two on-premises nodes in the organisation’s EU offices plus two operated by a trusted third party), requiring any three to cooperate. This tolerates the simultaneous failure or compromise of two nodes without losing availability, while ensuring no minority coalition can sign or decrypt independently.

Is FROST production-ready and suitable for regulated use today?

FROST (Flexible Round-Optimised Schnorr Threshold signatures) has a published IETF specification (RFC 9591) and several audited open-source implementations. It is considered production-ready for Schnorr-based signing, which covers use cases including digital document signing and code signing. Regulated organisations should pair deployment with a formal risk assessment and an independent cryptographic audit of the chosen implementation.

When will NIST publish production standards for threshold ML-DSA and ML-KEM?

NIST’s Workshop on Multi-Party Threshold Schemes (MPTS 2026) is the primary standardisation venue. As of mid-2025, NIST has published initial discussion documents but has not released a final standard for threshold extensions to FIPS 204 (ML-DSA) or FIPS 203 (ML-KEM). Production guidance is broadly expected in the 2026-to-2027 timeframe, though organisations can begin hybrid deployments using classical threshold schemes alongside PQC algorithms today.

How does a threshold key ceremony differ from a conventional HSM key ceremony, and what documentation is needed for a NIS-2 audit?

A conventional HSM key ceremony involves one or more custodians generating a master key inside a single device. A threshold key ceremony distributes this event: each node generates its own key share using a verifiable distributed key generation protocol, no complete key is ever assembled in one place, and the ceremony requires the cryptographically verified participation of custodians from each node jurisdiction. For a NIS-2 or DORA audit, organisations should produce a written ceremony script, witnessed logs of each node’s share generation, a quorum agreement specifying revocation rules, and verifiable secret sharing transcripts. This evidence package directly addresses the supply-chain and access-control obligations under NIS-2 Article 21.