# 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, Palisade 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](/assets/key-refreshing.84c552b69c6e7eb3213fc38c3022d96d1c41e4dfa78b2d1cbe9236e844d1380c.0ba50ef8.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 (Palisade) 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 Palisade 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 Palisade support and confirm the expected signing availability for affected wallets.
4. Make sure the required quorum devices are online if Palisade requires device participation.
5. After Palisade confirms completion, create a new backup for the affected quorum.


Device availability
Palisade 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 Palisade 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](/products/wallet/user-interface/security-controls/key-restructuring) – Change quorum participants while preserving the key
- [MPC quorums](/products/wallet/user-interface/security-controls/mpc-quorums) – Create and manage quorums
- [Understanding MPC-TSS](/products/wallet/introduction/understanding-mpc-tss) – How MPC-TSS works
- [MPC terminology](/products/wallet/introduction/mpc-terminology) – Key terms and definitions