Removing a departing employee from the company directory does not remove that employee's signing address from a multisig wallet. The authority lives in the account configuration. An institution should treat signer turnover as a change to a production control, with evidence that the old authority has ended and the remaining group can still act.
The task is not simply to replace a name on a spreadsheet. Each wallet can have different owners, thresholds and additional execution paths. A person may sign for several funds, treasury accounts or operating entities. Offboarding should discover that scope before the organisation loses access to the people needed to approve the change.
Start with the account's actual owners
Safe's smart account concepts describe owners as addresses held in account storage and the threshold as the number required for ordinary owner-authorised execution. The company's personnel list is an interpretation of those addresses, not the authority record itself.
Build an inventory that maps each signing address to a named custodian of the credential, the entity represented, its operational purpose and every account where it has authority. Check the account state independently. Safe's getOwners reference provides one relevant read for Safe deployments.
Separate control of a key from the person's job title. A shared device, a service-controlled credential or a contract owner may not map neatly to one employee. The turnover review should expose those arrangements. An account with several owner addresses does not necessarily have the same number of independently controlled decision-makers.
Choose replacement, removal and threshold separately
Safe documents swapOwner for owner replacement and removeOwner with a threshold parameter for removal. These are technical options. The institution still needs to approve the desired final owner set and threshold based on its authority policy.
A replacement can preserve the numerical structure while changing who controls a credential. A removal can change availability and separation of duties. Lowering a threshold to keep the wallet usable changes the control itself; it should not be treated as an administrative detail buried in an offboarding ticket.
Consider a hypothetical three-of-five wallet. One signer leaves, another is unavailable and a third has not tested their device in months. The account may still show a valid threshold while the organisation struggles to assemble a usable quorum. The change plan should test availability, rather than infer it from the number of addresses onchain.
Before execution, write the intended final configuration in plain language. Name the new owner, the departing address, the threshold and the accounts covered. Approvers should compare the proposed transaction to that specification. This makes an unintended threshold change easier to spot than asking them to approve an opaque configuration call.
Keep the approval path available through completion
For planned departures, schedule the wallet change while authorised remaining signers are available. The last working day is a poor default change window if several participants are travelling or the replacement has not been onboarded. A completed employment process and a completed authority change can require different lead times.
The incoming signer should demonstrate device access, account identification and signing through the institution's approved workflow. Training should use a safe environment or an appropriately controlled production exercise. A credential generated successfully is not evidence that the person can interpret the proposed transaction, obtain approval and execute it correctly.
If the departure is urgent, use the preapproved emergency change procedure. That procedure should identify who can authorise an accelerated configuration change and how it is reviewed afterward. Urgency should not create an undocumented alternate quorum or a private transfer of a former employee's credential.
This follows the distinction in institutional key management: the technology supplies a mechanism, while the institution supplies the authority structure. Turnover tests whether the two still agree.
Inspect execution paths beyond the owner list
Safe's concepts documentation also describes modules as an additional transaction path and guards as transaction checks. An owner update does not amount to a review of all account capabilities. A turnover review should determine whether the departing person controls a module administrator, recovery mechanism or connected service credential.
The scope should include transaction-service access, proposal rights, relayer credentials, API keys and notification ownership. Losing proposal access and losing execution authority are different changes. Leaving either mapped to a departed employee can create operational confusion, even where the remaining owner threshold prevents unilateral execution.
For custom modules, ask engineering to document the relevant authority and revocation method. Do not assume that the module follows the same owner policy as the account. Where the dependency cannot be verified, retain an open exception and restrict the affected workflow until the organisation has an approved answer.
Review pending instructions without making assumptions
The change plan should inventory outstanding proposals, collected signatures and scheduled activity. Whether a prior signature remains usable depends on the account implementation, transaction state and authorisation checks. The institution should verify this for the actual deployment rather than relying on a general statement that every old signature disappears.
Each pending instruction needs a disposition: continue under the approved configuration, rebuild with current signers, cancel through the supported process or retain as an investigated exception. Record why. Clearing a service interface may hide a proposal from an operator without proving that every related instruction is no longer executable.
For recurring treasury activity, identify jobs that expect the departed signer to approve a batch. Reassign the role and test the next scheduled cycle. A technically successful owner replacement can still cause the first payroll, margin or settlement batch to miss its operational deadline if the workflow routing has not been changed.
Verify state and usable quorum
The completion evidence should include the executed configuration transaction, its result and the observed final owner set and threshold. An approved proposal is not enough. Read the state after the organisation's chosen confirmation standard and retain the block reference alongside the change ticket.
Then test the remaining operational path. The test should demonstrate that the required signers can participate, the destination policy can be checked and the execution can be reconciled. It need not move a large quantity of assets. Its purpose is to prove the account remains usable under the intended controls.
The digital asset disaster recovery discussion makes the same distinction between possession of credentials and demonstrated ability to move. Signer turnover is a smaller change, but it deserves the same attention to usable authority.
Retain both failures and successes from the test. If a replacement signer can approve through one interface but not the institution's required device path, the change has exposed an operating gap. Resolve it before declaring the offboarding complete, or name the temporary restriction and its responsible owner.
The final access review should include the departed signer's notification destinations and the people receiving transaction requests. A valid onchain replacement is less useful if the approval workflow continues sending confidential operating details to an old address. Reconcile the account configuration and its supporting services as two separate checklists with one change owner.
Keep the former address in the historical mapping, marked inactive rather than deleted. Older transactions still need an explanation of who controlled the address when they were authorised. Preserve its effective dates. Removing the mapping can make a completed offboarding process harder to audit months later.
Make future departures less dependent on memory
Integrate the signing-address inventory with staff changes without exposing secrets to the personnel system. The useful record is which authority must be reviewed, not a copy of private keys. A departure trigger should create account-specific work with assigned owners and observable completion conditions.
Periodic reconciliation can compare the personnel mapping with onchain owners and connected control records. Exceptions include an address with no responsible person, a former employee still listed, a threshold changed outside the approved process and a wallet whose operational quorum has not been tested since the last change.
Ask the teams to rehearse two departures occurring close together. This reveals whether the institution depends on a particular person to coordinate all replacements, or on one backup signer to rescue every account. A numerical threshold is only useful when the people and devices behind it remain available under the organisation's actual approval rules.
The closeout should answer two questions with evidence: can the departing signer still exercise any relevant authority, and can the approved remaining group operate the account? Offboarding is complete only when the institution has addressed both the retired authority and the continuity of the control that replaces it.