Executive Summary
Institutions running stablecoin payments, treasury operations or tokenization workflows need a tested path to continue signing when their primary wallet provider becomes unavailable. Applying multi-cloud thinking to the wallet layer means examining vendor dependencies and preparing a secondary environment that can support critical transactions.
Utila’s business continuity offering enables institutions to mirror supported MPC wallet environments into a dedicated Utila vault, preserving addresses and replicating operational controls. This article examines wallet provider concentration risk, DORA’s relevant requirements, and the direct recovery kit and Station70 integration options available to establish that secondary environment.
Address Dependency In Your Wallet Stack
An unavailable signing service can leave supplier payments pending, delay treasury transfers and interrupt tokenization workflows. When an institution depends on one wallet provider, its ability to resume those activities depends on its recovery arrangements.
Multi-cloud architecture offers a useful principle for this problem: identify which dependencies can interrupt a critical service and prepare an alternative path. Applying that principle to wallet infrastructure requires a secondary environment with usable signing capability and validated approval controls.
A practical continuity plan should establish how your team will access that environment, authorize transactions and resume priority workflows during an incident.
Understand Wallet Provider Concentration Risk
Wallet infrastructure depends on several layers of technology and service delivery. Disruption can originate within the provider, its underlying cloud infrastructure or the systems your own team uses to access and operate wallets.
The October 19–20, 2025 AWS incident illustrates how failures can spread across shared dependencies. AWS’s post-event report describes a disruption spanning approximately fourteen and a half hours, with different periods of impact affecting DynamoDB, EC2 and Network Load Balancer services in its Northern Virginia region. Customer impact varied by service and configuration.
For wallet operations, the practical question is which failures would prevent your team from signing and how an alternative environment would remain available. Assess shared cloud, identity and network dependencies when selecting a secondary provider, alongside the wallet service itself.
Align Continuity Planning With DORA
DORA requires covered EU financial entities to manage ICT third-party risk. For ICT services supporting critical or important functions, Article 28 requires documented exit strategies and sufficiently tested exit plans, reviewed periodically. Article 29 addresses concentration risk and the assessment of alternative arrangements.
These provisions support a clear operational objective: demonstrate how critical activities can continue or transition when a provider relationship becomes untenable. DORA does not impose a blanket requirement to maintain a second wallet provider; the appropriate arrangement depends on the institution’s functions, risks and obligations.
A configured secondary wallet environment can contribute to that continuity strategy. Your team should document its scope, test the recovery process and retain evidence of the results as part of the broader resilience program.
Similar expectations extend beyond the EU. Regulators in the UK, Singapore and the UAE address third-party dependencies through outsourcing and operational resilience frameworks, with expectations for business continuity planning and recovery arrangements. Institutions operating across these markets should include wallet infrastructure in their assessment of critical service dependencies.
Mirror Your Environment Into Utila
Our business continuity offering lets institutions mirror supported MPC wallet environments into a dedicated Utila vault, preserving existing wallet addresses across 100+ blockchains. Your team can continue signing using those addresses while replicating transaction policies, approval workflows and whitelisted counterparties.
You can configure Utila as a standby environment, operate it alongside your primary provider or use it as the destination for a full migration. Before relying on the setup, validate the supported assets and address derivation paths, then test the required transaction workflows and approval rules.
Two recovery routes support different operating arrangements.
Direct Recovery Kit Upload
The direct recovery kit route provides a self-serve flow inside the Utila Console. Utila generates a unique key pair for your migration vault and displays the public key. You use that public key to generate a compatible recovery kit with your existing provider, then upload the encrypted package.
Utila decrypts the server shares inside a trusted execution environment. Your client share is sent to the Utila mobile app, where you decrypt it using your existing provider’s recovery passphrase. The process keeps the full private key from being reconstructed and keeps client-share decryption off Utila’s servers.
This route supports setup without a separate third-party recovery subscription or an offline machine. See the Fireblocks package migration guide for the applicable workflow.
Station70 SWAT Integration
Institutions using Station70 can use our integration with its Secure Wallet Account Transfer, or SWAT, workflow to replicate supported wallet infrastructure into Utila. This provides a recovery route through their existing Station70 arrangement.
Station70 protects backup access through a 3-of-3 encryption scheme, with key shards held in separate environments and a customer-controlled hardware quorum. This protects the recovery package; transaction signing in the resulting Utila environment follows its configured signing and approval controls.
Whichever route you choose, key recovery and operational configuration need to be validated together. Confirm that the secondary environment can execute the transactions your institution needs under the intended controls.
Test The Complete Recovery Workflow
A secondary environment becomes operationally useful when your team can activate and use it under realistic incident conditions. Establish a recovery procedure that covers the following:
Supported transaction scope: Verify the wallets, assets and transaction types required for priority operations.
Controls and access: Validate approval quorums, transaction policies and access for the people responsible for recovery.
Activation and timing: Assign responsibility for initiating failover and measure how long it takes to complete a representative transaction.
Ongoing maintenance: Review the secondary environment after changes to wallets, policies or counterparties, and record the results of recovery exercises.
These checks give operations teams a repeatable process and help risk and compliance teams assess the evidence behind the continuity plan.
Give Teams A Shared Recovery Plan
Business continuity requires coordination across the teams responsible for transactions, infrastructure and oversight. A validated secondary wallet environment gives each team a concrete role:
Treasury and payment operations: Establish a route to resume priority transactions when the primary signing service becomes unavailable.
Security and risk: Assess dependency exposure and maintain a recovery process that can be exercised regularly.
Compliance and regulatory teams: Use documented configurations and test results as evidence within the institution’s broader resilience program.
Executive leadership and boards: Evaluate wallet provider concentration alongside other critical technology dependencies.
“The institutions we work with have spent years engineering out single points of failure in every other critical system. Wallet infrastructure has been the last remaining category where a single vendor is still the default. Our business continuity plan gives them a way to change that without disrupting anything they already run.”
Sam Eiderman, Co-Founder and CTO of Utila
Build A Tested Secondary Environment
As stablecoin and digital asset workflows become part of daily operations, wallet availability belongs in the same continuity planning process as the systems that initiate and reconcile those transactions. The useful outcome is a secondary environment your team has configured, tested and knows how to operate.
Book a business continuity walkthrough to assess compatibility with your current wallet environment, compare recovery options and define the controls your team should validate before failover. Ask for our full BCP deck to support your internal technical and risk review.
