Admin key management for deployers, guardians and upgrade controllers

Who holds the deploy key

Approve a protocol release only when the team can identify what the deployer may still do after deployment. Admin key management is the control of privileged signing authority across creation, operation and recovery. The address that pays deployment gas need not remain the address that upgrades contracts, pauses activity or moves treasury assets.

Begin with the required operating model.

For a protocol that needs upgrades, assign implementation changes to a deliberately governed path. Give emergency operators only the actions they need to contain an incident. If the design is intended to become immutable, define which deployment privileges disappear and verify that removal instead of relying on a public statement about renounced ownership.

The release owner should maintain an authority inventory that another person can read without access to private keys. Record the chain, target, role, controlling account and the process that can replace that account. Include the transaction or state observation supporting the entry. A list of wallet addresses without their reachable capabilities does not establish separation of duties.

Custody and permissions are different questions.

A hardware-backed key may still hold excessive authority, while a carefully limited role may be stored in an unsafe workflow. Review both. The acceptance decision should name the intended capability and the custody process that protects it, then identify who verifies each part.

Do not count addresses as independent operators.

Several addresses can share a device, recovery phrase, administrator or approval interface. Operational independence requires evidence about those dependencies, not a larger signer list. That evidence can describe controls and responsible roles without disclosing sensitive recovery material.

The privileged contract controls guide helps identify hidden authority routes. Use that graph before deciding which keys need which custody controls.

Upgrade authority versus pause guardian

A pause is a containment action with an availability cost.

An upgrade can replace the rules that control assets. Combining those powers may simplify operations, but it also means a compromised emergency signer can do more than stop a suspicious route. The decision should be explicit and reflected in the contract's permissions.

Evaluate the minimum action required during an incident.

A guardian might need to stop new borrowing while preserving repayment, or disable a particular adapter while leaving unrelated activity available. Whether that separation is possible depends on the implementation. A generic pause function may freeze more than the response plan assumes.

Then examine how the guardian can be replaced.

A separate role does not provide durable separation if its administrator can immediately grant itself upgrade authority or replace the controlling wallet. OpenZeppelin's access-control model distinguishes role members from role administrators; that administrative relationship belongs in the inventory.

For ordinary upgrades, a timelock can provide a notice period before execution.

Its value depends on the actual path and on what users can do during the delay. If all exits are frozen, describing the delay as an exit window may be misleading. If an emergency route bypasses it, document the conditions and scope of that route.

Decide who owns the tradeoff.

Engineering should describe the reachable actions, operations should describe the response need and the release authority should accept the residual risk. A label such as guardian is not a technical restriction. Verify the functions that account can call.

OpenZeppelin ownership and role administration provides the contract-level distinctions. Apply them to the deployed authority graph rather than treating the library choice as the finished policy.

What never enters CI

An unrestricted production admin key should not be a general-purpose build secret. The build system needs to produce a reviewable artifact; possession of that artifact does not require possession of the authority to install arbitrary logic in production. If a signing service participates in deployment, constrain what it can authorize and preserve an independently reviewable payload.

Keep recovery phrases and master recovery material out of workflow variables, logs and build artifacts. Logging controls cannot make an unnecessary secret dependency safe. GitHub's hardening guidance warns that automatic redaction is not guaranteed, particularly when a value is transformed. Treat an exposed credential as compromised rather than assuming a masked log line proves it remained private.

Untrusted code is another boundary. A privileged workflow that checks out and executes an untrusted pull request may expose referenced credentials or write permissions. Review the trigger, checkout source and permissions together. An approval step attached to the wrong stage can leave attacker-controlled code running before the intended decision.

Use the least privilege needed for each job. Read-only testing, artifact creation and production authorization have different requirements. Pin the code and dependencies that the signing step consumes, then compare the final payload with the reviewed artifact. A successful test run does not establish that a later job signed the same bytes.

For the surrounding application and delivery process, a scoped assessment should examine hardcoded secrets and the access boundaries reachable with different credentials. Pharos Production describes security testing for secrets and access control that combines source analysis with manual testing of authentication and business-logic paths. Those checks fit the boundary between a workflow credential and the privileged action it can authorize; the engagement still needs your actual workflow and role scope.

1. List every credential available to each workflow job and justify its exact permissions.
2. Remove recovery material and unrestricted production signing authority from general build execution.
3. Trace untrusted inputs through triggers, dependencies and checkout steps before approving the privileged path.
4. Produce an artifact and readable deployment payload that can be verified independently of the signing interface.
5. Preserve the authorization record and compare the resulting deployment with the approved candidate.

GitHub Actions security hardening is the source for the workflow-specific risks. A separate key custody review is still required where signing devices, recovery processes or external services determine production authority.

Rotation and revocation: prove the old route is gone

A rotation is complete when the new authority works and the old authority no longer reaches the protected action. Adding a new signer or transferring one role is only part of that transition. Old accounts may retain a role administrator permission, a wallet module, an allowance or authority over a controller upstream of the target.

Plan rotation while the current authority remains available. For ownership designs that support an explicit acceptance step, verify the recipient can accept and operate the target before relinquishing the old path. OpenZeppelin's Ownable2Step addresses accidental transfers to an account that cannot complete the acceptance. It does not evaluate the recipient's operational independence or custody quality.

Use a revocation worksheet that follows capability, not wallet labels. For each old account, identify direct roles and indirect paths through other contracts. Include emergency permissions and the right to enable modules or replace a guard. A removed multisig owner can still matter if another controlled account retains an authorized module.

After executing the change, read the resulting configuration from the relevant chain. Preserve the observation block and test the expected rejection for the old authority in an isolated environment where appropriate. Deleting a local key file does not revoke an on-chain role. Conversely, revoking a role does not erase copies of a key that may control other assets.

Recovery must also be tested as a process. A sealed backup that nobody can locate during an incident is not equivalent to an available recovery path. The rehearsal should establish who can participate, what approvals are required and which capabilities remain usable while a signer is unavailable. Use test authority and synthetic material for the exercise.

Prepare successor

Verify intended capability.

Change authority

Execute approved transition.

Reject old route

Read back and test denial.

Record any authority that intentionally remains. A maintenance account with a limited residual permission can be acceptable, but the public description and internal response plan should not call it fully revoked.

Multisig and timelock configuration

A multisig threshold is a signature rule for a particular execution path. Safe modules can provide other authorized transaction routes, and guards can restrict execution. The review must cover those extensions together with the owner set. A screenshot showing the owner threshold does not establish the complete authority of the account.

Safe's documentation states that modules can execute transactions through the module interface and warns that a malicious module can take over a Safe. Review who can enable a module, its own authorization checks and the operations it can perform. A module designed for an allowance differs from one with unrestricted execution, even if both appear under the same settings menu.

Guards introduce an availability dependency. A broken guard can block transaction execution, so the recovery mechanism deserves explicit review. The team should understand how to respond if a protection begins rejecting legitimate containment actions. Do not assume that a higher signature threshold can bypass a guard whose logic prevents execution.

For timelocks, document proposer, executor and administrator relationships. Verify the delay that applies to each protected operation and whether a change to the delay itself follows the intended process. Also check whether another controller can replace the timelock or reach the underlying function directly.

The configuration acceptance packet should be readable without trusting a single user interface. Include the chain and wallet address, implementation version, owner and threshold state, enabled modules and guards, then link each item to the intended operating policy. Have the reviewer compare the actual payload with that packet before signing a sensitive operation.

Safe module execution and Safe guard recovery considerations support these distinct review questions.

Our report check: privilege language is widespread, custody evidence is different

The fresh sample contains privileged-role, owner, admin, multisig or timelock wording in 43 of 50 readable reports. That result shows how often this vocabulary appears in the selected documents. It does not measure key custody quality or prove that the described operators are independent.

Method

Retrieved

September 5, 2026

Member frame

23 firms in the fixed research roster, including historical names.

Report frame

155 previously sampled archive entries.

Selection

The first 3 entries per firm from the earlier deterministic archive sample, fetched again for this study. No content-based selection.

Readable denominator

50 selected reports.

Archive coverage

17 sampled archives.

Cap exclusions

105 report entries excluded before reading.

Missing archive coverage

6 firms have no report in this frame.

Signal

Case-insensitive term matching in converted report text. Exact expressions and surrounding text are retained in the output.

Results

Matching text occurs in 16 sampled archives. We did not infer hardware custody, recovery practices or signer independence from contract reports. Those are separate evidence requests for the operating team.

Limits

• The frame includes multiple languages, non-contract assessments and older reports. It is a disclosure sample, not a random sample of deployed protocols.
• A matching term may be a checklist item, a library identifier or a project finding. Only separately reviewed examples support finding-level conclusions.
• Archive ownership does not establish report authorship. Some archives contain outside assessments of the archive owner's software.
• No live exploit was executed. An absent match can reflect terminology or text extraction and cannot establish that a firm lacks the capability.

Reproduction uses seo/research/security-scope-disclosures-survey.py; its dated output is seo/research/security-scope-disclosures-survey-2026-09-05.json. These files remain in the repository and are not published as downloads. The output preserves source responses, retrieval outcomes and the selection rules for later verification.

Incident lessons and the release decision

Ronin's June 28, 2022 reopening account describes a postincident reassessment and a new separation between governors and validators. It also describes withdrawal controls with administrative actions. This is historical evidence of a redesigned control model, not a description of Ronin's current architecture or proof that every bypass was eliminated.

The relevant lesson for an authority review is to inspect the control behind a limit. An administrator who can reset a withdrawal limit has a meaningful capability even when the user-facing description emphasizes the limit itself. Ask whether the response plan assumes that capability is available, delayed or held by a different party.

Public reports provide similarly concrete questions. The QuillAudits 2D3T report describes an owner withdrawal capability affecting vesting positions. The ShellBoxes CAP report discusses governance privileges. These disclosures help identify the operations that need custody and acceptance decisions; their existence is not evidence that those teams mishandled keys.

Make the release decision against the operating model you intend to run. Accept only when each privileged capability has an owner, a justified custody path and evidence for its limits. An unresolved root administrator or unreviewed wallet module should remain a named release question, not disappear inside a general statement that a multisig is configured.

The incident response guide connects this inventory to containment and recovery. Use the member directory and Pharos Production member profile when defining the review team, then commission the contract and operational scope that the actual authority graph requires.