Skip to main content

Applications for the autumn mentorship cohort are open until 30 September. Apply now

DSI
Checklist

DRep Key & Account Security Runbook

An operational security runbook for the specific responsibilities a DRep carries: key custody, backups, recovery planning, device hygiene, and incident documentation.

Type
Checklist
Difficulty
Intermediate
Time
45 min
Version
v1.0.0
Updated
8/9/2026
operationssecurityprocess

What this helps you do

A DRep key is a governance credential. If it is lost, delegated voting power is stranded until the delegators act; if it is stolen, votes can be cast in your name. Both failures are operational rather than technical, and both are preventable with a routine.

This runbook covers custody, hardware wallet use, backups, recovery planning, device security, phishing resistance, account recovery, continuity when you are unavailable, and how to document an incident. It states practices and points at the vendor and standards documentation behind them. It never asks you to record a key, a seed phrase, or any other secret, and no field in the workspace is designed to hold one.

When to use this

  • You are registering as a DRep and setting up custody for the first time.
  • You are running a periodic security review, at least annually.
  • You are changing devices, moving house, or changing the people in your continuity plan.
  • You are documenting an incident after a suspected compromise or a near miss.

When NOT to use this

  • You need to store a seed phrase, private key, or password. Never put a secret in this or any other workspace.
  • You are responding to an active compromise right now. Move funds and rotate credentials first, then document.
  • You need formal security certification or an audit for an organisation. This is an individual practice runbook.

What you'll need

  • An inventory of the devices and wallets you use for governance
  • Your current backup arrangement, wherever it physically is
  • The documentation for the hardware wallet or signing device you use
  • A named contact who knows what to do if you are unavailable

Estimated completion time

45 minutes

Working time for one governance action, assuming the inputs listed here are already to hand.

How to use it

  1. 1Work through the runbook once in full, then repeat it on a schedule rather than only after a scare.
  2. 2Inventory every device and wallet that can sign governance transactions, including ones you rarely use.
  3. 3Confirm your DRep key is held on a hardware signing device, and that the device firmware is current per the vendor advisory page.
  4. 4Verify each backup by testing recovery on a spare or wiped device, not by looking at the backup. An untested backup is a hope.
  5. 5Record where backups are, in general terms only: never the contents, and never a location description precise enough to be useful to an attacker.
  6. 6Separate governance activity from day-to-day browsing, ideally on a dedicated device or profile.
  7. 7Rehearse the phishing scenarios listed here out loud. Recognition speed is the only defence that works under pressure.
  8. 8Write the continuity plan: who is told, what they can and cannot do, and how delegators would learn you are unavailable.
  9. 9Set the review date and keep the dated log of changes and incidents.

The tool

Full checklist - v1.0.0

Key custody

  • DRep key is generated and held on a hardware signing device
  • Signing device firmware version checked against the vendor advisory page
  • Governance key is separate from any key used for routine spending
  • No key material has ever been typed into, pasted into, or photographed on an internet-connected device
  • Passphrase use is a deliberate decision, documented as used or not used
  • Any multi-person arrangement is written down with who holds what

Backups and recovery

  • Backup exists for every credential needed to resume governance work
  • Backup medium is durable and stored apart from the signing device
  • At least two geographically separated copies where the threat model warrants it
  • Recovery has been tested end to end on a wiped or spare device
  • Date of the last successful recovery test recorded
  • Backup contents are never stored in cloud storage, email, password managers, or photos
  • Recovery procedure is written for someone else to follow without needing you

Device and account security

  • Full disk encryption enabled on every device used for governance
  • Operating system and browser patched to current versions
  • Screen lock and strong device credential in place
  • Browser extensions reviewed; unused extensions removed
  • Unique credentials for every governance-related account, held in a password manager
  • Phishing-resistant multi-factor authentication such as a security key on email and social accounts
  • Email account recovery options reviewed, since email is usually the weakest link
  • Every signing request read on the device screen and confirmed against what was intended

Phishing and social engineering

  • Treat unsolicited contact about your DRep status as hostile until proven otherwise
  • Never enter a recovery phrase into any site, support agent, or wallet restore prompt you did not initiate
  • Verify governance tool URLs from a bookmark rather than from search results, links, or messages
  • Assume urgency is a technique: deadline pressure is the most common lever used against DReps
  • Confirm any request to sign, delegate, or move funds through a second channel
  • Report attempts publicly so other DReps recognise the pattern

Continuity and incident documentation

  • Named contact who knows a governance role exists and what to do if you are unavailable
  • Instruction on whether delegators should be told to redelegate, and how that message would be published
  • Plan for extended absence: retire, pause, or delegate the workload
  • Incident log: date, what happened, what was affected, what was rotated, what was published
  • Post-incident review recorded with the change made to prevent recurrence
Fictional Example

Invented for illustration. It does not describe a real governance action, proposal, or organisation.

Fictional review: annual runbook pass

  • Inventory found three devices, one of which was an old laptop with a governance browser profile still signed in. Profile removed and the device wiped.
  • Firmware on the signing device was two releases behind and one release carried a security fix. Updated the same day.
  • Recovery test failed on the first attempt because one backup copy was incomplete. Rewritten and retested successfully on a wiped spare device.
  • Email account used security codes over SMS. Replaced with a hardware security key, second key stored with the backup.
  • Phishing rehearsal: a fictional message offering help with a stuck vote and a link to a lookalike governance tool. Recognised by the URL and by the urgency.
  • Continuity: one named contact briefed, with written instruction to publish a redelegation notice after fourteen days of no contact.
  • Incident log entry: no compromise. Two near misses recorded, both dated, with the corrective action against each.

How to interpret the result

  • A checklist that passes on first attempt usually means the tests were not real. A failed recovery test is the most valuable result this runbook produces.
  • Score the runbook by unresolved items, not by percentage complete. One unbacked key outweighs twenty green ticks.
  • If your continuity plan depends entirely on you being reachable, you do not have a continuity plan.

Limitations

  • This is general operational practice, not a security audit or professional advice, and it cannot account for your individual threat model.
  • Vendor guidance, firmware advisories, and platform recovery options change. Verify against current vendor documentation rather than any dated copy.
  • No part of this resource should ever hold a secret. Seed phrases, private keys, passwords, and recovery codes belong nowhere near a browser workspace.
  • Following the runbook reduces likelihood; it cannot eliminate compromise.

Sources and methodology

Downloads

  • Markdown export: the complete tool, including metadata, instructions, the template, limitations, sources and version history.

No other file formats are published for this resource. We list a format only when the file exists.

Version and governance

Current version
v1.0.0
Published
Not recorded
Last updated
8/9/2026
Next scheduled review
2/9/2027
Licence
CC BY 4.0
Editorial status
Not yet externally reviewed

No named reviewer is shown because no external review has been completed. Attribution appears only once a verified reviewer has signed off.

Changelog

  • v1.0.0 (2026-08-09) - First published edition.
Use This Tool