Google’s new MPC service combines distributed signing, transaction policies and recovery tools, with commercial availability targeted for early 2027. The central security question is whether
Google is bringing multi-party computation to institutional cryptocurrency custody, but the security of its new service will depend on more than splitting private keys across separate systems.
The company is previewing Google Multi-Party Compute (MPC) at its October 28 digital-assets symposium in New York. The product combines distributed signing, transaction approval policies and recovery capabilities. Several unnamed financial institutions are testing it, while Alphabet has begun using the technology to protect assets on Ethereum and Solana.
Commercial availability is targeted for early 2027, with pricing undisclosed, according to CoinDesk.
For banks, the unresolved issue is whether a managed cloud platform can deliver the same administrative independence that distributed cryptography is designed to provide.
MPC allows several participants to jointly generate a transaction signature without reconstructing the complete private key in one location.
In a hypothetical two-of-three configuration, an attacker who compromises one signing share cannot independently authorize a transfer. Compromising two participants, however, could defeat that threshold if no additional controls intervene.
The arrangement becomes more complicated when all participants share an administrative environment.
Imagine a bank running three signing services under one cloud administrator. Although each service holds a separate cryptographic share, an attacker obtaining sufficiently broad administrative privileges could potentially compromise multiple participants or interfere with the systems enforcing approval rules.
This is an architectural risk scenario, not a reported vulnerability in Google’s product.
The stronger test is whether customers can isolate signing participants across independently controlled environments and prevent a single administrator from changing transaction policies or recovery procedures.
Google’s earlier Confidential Space architecture provides relevant context. It describes protected execution environments and arrangements involving independent co-signers, including systems outside Google Cloud.
However, those earlier technical designs do not establish which deployment options, share ownership models or administrative boundaries are available in the new managed service.
Google is competing with providers that already offer distributed signing, custody infrastructure and transaction governance.
Fireblocks documents an MPC-based architecture in which customers can retain signing shares and configure approval policies. Its published materials also describe hybrid, on-premises and multi-cloud deployment options.
BitGo offers qualified custody alongside wallet infrastructure, including multisignature and MPC configurations. Fordefi focuses on MPC wallets, transaction simulation and policy controls for institutional blockchain operations.
These offerings are not interchangeable. Qualified custody concerns the legal and operational responsibility for holding assets, while MPC describes a cryptographic signing method. A bank can use MPC infrastructure without outsourcing legal custody, or engage a qualified custodian that uses several security technologies.
DIGITAL ASSET SECURITY / RESEARCH NOTE Who Controls the Signature? Comparing HSM custody, established enterprise MPC and Google’s proposed managed signing service. HSM Hardware custody MPC Enterprise providers GOOGLE Managed MPC 01 / KEY STORAGE Protected within secure hardware. Shares distributed across participants. Distributed signing; share placement undisclosed. 02 / TRUST BOUNDARY Hardware protection and access controls. Threshold cryptography and node isolation. Managed controls; administrative independence unconfirmed. 03 / TRANSACTION POLICY Typically managed by surrounding custody software. Configurable approval and transaction rules. Integrated policy checks before signing. 04 / CLOUD DEPENDENCE On-premises or cloud-based deployments. Deployment options vary by provider. Independent signing options not fully documented. EDITORIAL NOTE This is an architectural comparison, not a security ranking. HSMs and MPC can operate together. Google’s precise implementation remains subject to further disclosure. Google’s potential advantage is integration. Banks may be able to procure signing, policy enforcement and recovery through one managed platform rather than assembling separate components.The trade-off is the need to establish who can authorize transactions when the cloud provider, customer administrators or recovery systems are compromised.
Chainalysis reported that private-key compromises accounted for 43.8% of cryptocurrency stolen in 2024, when total hacking losses reached approximately $2.2 billion.
Applying that percentage to the rounded total produces an indicative figure of roughly $964 million. It is not an estimate of losses that MPC would necessarily have prevented.
The distinction becomes clearer when considering a fraudulent institutional withdrawal.
A signing system could correctly enforce a two-of-three threshold while two authorized employees approve a malicious transfer. Alternatively, attackers might obtain enough administrative privileges to change approved destinations before the signing process begins.
Cryptographic protection, transaction authorization and administrative governance must therefore be assessed separately.
For a bank evaluating Google MPC, the most useful security evidence would include an independently assessed threat model, details of participant isolation, policy-change authorization and recovery procedures. None of those product-specific findings has been publicly established.
Google also plans to introduce post-quantum capabilities, although no product-specific release date has been confirmed.
The challenge involves the underlying signature algorithms, not simply the distribution of key shares.
ECDSA and Ed25519 rely on elliptic-curve cryptography, which a sufficiently capable future quantum computer could threaten. Distributing the signing process through MPC does not remove that underlying exposure.
Post-quantum algorithms such as ML-DSA, standardized by NIST, use different mathematical constructions and larger signature formats. ML-DSA-44 signatures are 2,420 bytes, compared with 64 bytes for a conventional Ed25519 signature.
That difference can affect transaction size, network fees and compatibility with blockchain verification rules. Building a distributed signing protocol for a post-quantum scheme also requires separate cryptographic engineering; existing threshold-ECDSA implementations cannot simply be relabeled quantum-resistant.
For Ethereum and Solana, compatibility ultimately depends on the signature mechanisms supported by the relevant blockchain and account architecture. A custody provider cannot independently make an unsupported on-chain signature scheme valid.
Google’s post-quantum roadmap is therefore relevant to its longer-term custody ambitions, but it does not resolve today’s questions about signing authority.
Alphabet’s reported use of the technology provides an internal deployment reference, not independent proof of security or operational resilience.
Before commercial launch, institutional buyers need concrete answers about customer-held signing shares, administrative separation, recovery authority and service availability during a cloud outage.
Those disclosures would make it possible to compare Google with Fireblocks, BitGo and other providers on measurable control boundaries rather than branding or cryptographic terminology.
Google has established a commercial timetable. The evidence needed to judge whether its managed architecture genuinely reduces institutional custody risk is still incomplete.
The post Google’s Crypto Security Push Raises a Key Custody Question appeared first on ETHNews.
