# Key resharing

**Key resharing** in MPC is a process similar to secret rotation in software. It refreshes key shares without changing the underlying private key. This can enhance security while keeping the cryptographic identity unchanged.

## Overview

In Threshold Signature Schemes (TSS), key resharing involves generating **a new set of key shares** among participants while keeping the original private key consistent. This process ensures that even if some key shares were previously compromised, they become obsolete after resharing, **mitigating long-term exposure risks**.

Importantly, Wallet-as-a-Service performs key resharing in a fully distributed manner. The system **never reconstructs the private key** at any point during the resharing process.

This process is also commonly referred to as:

- Key share rotation
- Proactive secret sharing
- Key refresh


Regardless of the terminology, the goal remains the same: to **enhance breach resilience, adapt to changes in an organization's quorum structure, and refresh cryptographic material** over time.

## Security benefits

Key resharing provides several important security benefits:

| Benefit | Description |
|  --- | --- |
| **Breach mitigation** | Previously compromised key shares become obsolete |
| **Long-term security** | Reduces risk from persistent threats |
| **Key continuity** | Private key remains unchanged and wallet addresses stay the same |
| **Compliance** | Supports key rotation requirements |


## How key resharing works

During a coordinated reshare, the system refreshes each participant's key share into a new share. The mathematical relationship between shares changes, but the underlying private key remains the same.

### Example: 2-of-3 quorum

Consider a 2-of-3 quorum with the following devices and shards:

**Before resharing:**

1. CloudSign 1 holding shard `Sa1`
2. CloudSign 2 holding shard `Sa2`
3. CloudSign 3 holding shard `Sa3`


**After resharing:**

1. CloudSign 1 now holds shard `Sb1`
2. CloudSign 2 now holds shard `Sb2`
3. CloudSign 3 now holds shard `Sb3`


![Key resharing diagram](../images/key-refreshing.svg)

The old shards (`Sa1`, `Sa2`, `Sa3`) no longer sign transactions. Only the new shards (`Sb1`, `Sb2`, `Sb3`) can participate in signing.

## When to use key resharing

Consider coordinating key resharing in these scenarios:

- **Security policy** - Rotate key shares when your internal security policy requires it.
- **Suspected compromise** - Invalidate potentially exposed shares.
- **Personnel changes** - Review resharing needs when users with device access leave the organization.
- **Compliance requirements** - Meet regulatory key rotation mandates.
- **Security incidents** - Include resharing in your incident response plan when appropriate.


## Coordinate key resharing

Wallet-as-a-Service doesn't currently expose a customer-initiated key resharing action in the console, and it doesn't run key resharing automatically on a schedule. If you need to reshare key shards, contact Ripple support or your account team.

Before a coordinated reshare:

1. Identify the quorum and wallets that require resharing.
2. Confirm the business reason, such as a security incident, personnel change, or compliance requirement.
3. Schedule a maintenance window with Ripple support and confirm the expected signing availability for affected wallets.
4. Make sure the required quorum devices are online if Wallet-as-a-Service requires device participation.
5. After Wallet-as-a-Service confirms completion, create a new backup for the affected quorum.


Device availability
Ripple support confirms which devices must be available during a coordinated reshare. If a required device is unavailable, the resharing may fail or require manual intervention.

## Critical warning: Backup compatibility

IMPORTANT: Backup compatibility
Use **key resharing** carefully with **key share backups**.

**Restoring a key share from an older backup**—created before the most recent resharing operation—on a single MPC node causes a **mismatch between key shares** across the quorum, **rendering the key unusable**.

To prevent this:

- **Option 1:** Avoid using local key share backups with resharing
- **Option 2:** Create a new backup **immediately after each resharing event**


Failure to follow these guidelines can result in **permanent loss of access to funds**.

### Backup best practices with key resharing

If you use key share backups:

1. **Document resharing events** – Keep a log of when resharing occurs
2. **Invalidate old backups** – Mark pre-resharing backups as obsolete
3. **Create new backups immediately** – After Wallet-as-a-Service confirms a reshare, create fresh backups
4. **Verify backup compatibility** – Before restoring, confirm that you created the backup after the last resharing
5. **Consider backup-free approach** – For maximum safety, rely on quorum redundancy instead of backups


## Related topics

- [Key restructuring](/pt-br/products/wallet/user-interface/security-controls/key-restructuring) – Change quorum participants while preserving the key
- [MPC quorums](/pt-br/products/wallet/user-interface/security-controls/mpc-quorums) – Create and manage quorums
- [Understanding MPC-TSS](/pt-br/products/wallet/introduction/understanding-mpc-tss) – How MPC-TSS works
- [MPC terminology](/pt-br/products/wallet/introduction/mpc-terminology) – Key terms and definitions