Employee offboarding is one of the most underappreciated security risks in the crypto industry. When an employee, contractor, or co-founder leaves an organisation, they do not automatically lose access to anything. They retain whatever credentials, keys, permissions, and devices they held during their time at the firm until someone actively revokes them. In a traditional business, a departed employee with lingering access to the CRM or email system is an inconvenience and a compliance issue. In a crypto or Web3 organisation, a departed employee retaining access to private keys, multisig positions, exchange accounts, or cloud infrastructure can mean complete and irreversible asset loss.
The insider threat window created by poor offboarding is measurable and alarming. Research across traditional industries consistently finds that the average time between an employee departure and the complete revocation of their access is over 70 days. For crypto firms, where access to a single private key can be sufficient to drain a treasury, that window is not a compliance gap, it is an open door to catastrophic loss. This guide covers every dimension of secure offboarding for crypto and Web3 organisations: from the immediate response on day one of a departure decision, through cryptographic key rotation and hardware recovery, to building a programme that functions reliably across all departures, including the ones that turn hostile.
This is a people-and-process gap that Security4Web3 specialises in closing. Our team brings direct experience from the defence industry, where personnel change procedures are treated with the seriousness the stakes demand, combined with deep operational knowledge of the specific access vectors that make crypto offboarding categorically different from any other industry.
Why Offboarding Is a Security Crisis in Crypto
The security consequences of poor offboarding in crypto are not theoretical. They trace directly to a set of structural factors that distinguish crypto from virtually every other industry when it comes to the risk profile of departing personnel.
Irreversible Losses from Stale Access
Blockchain transactions are irreversible. When a departing employee with stale access to a hot wallet initiates an unauthorised transfer, there is no recall mechanism, no fraud team to contact, and no dispute resolution process that can recover the funds. The irreversibility of the execution layer means that the entire security burden falls on prevention, and offboarding is one of the primary preventive controls. A stale access incident in crypto does not look like a recoverable data breach: it looks like a permanent, irrecoverable balance sheet event.
The 72-day average revocation window that security researchers observe in traditional organisations is unacceptable in any organisation holding digital assets. A former employee who retains access to a cloud IAM role for 72 days has had 72 days to enumerate the infrastructure, copy configurations, identify vulnerabilities, and position themselves for an attack. A former employee who retains a multisig signing key for 72 days is a latent threat to every treasury transaction processed during that period.
Crypto's Unique Access Vectors
The access vectors that must be addressed during crypto offboarding go significantly further than anything a traditional IT offboarding checklist covers. They include: private keys to hot and warm wallets; hardware wallets and the seed phrases associated with them; multisig signing positions on Gnosis Safe or equivalent governance platforms; exchange API keys with withdrawal permissions; cloud IAM roles with access to infrastructure hosting keys or secrets; GitHub repository access including CI/CD deploy keys; DeFi protocol governance roles; and access to DNS and domain registrar accounts that control the organisation's web presence. Any one of these, if not revoked, constitutes a meaningful risk. The combination of several creates a very serious ongoing exposure.
The Co-Founder and Senior Access Problem
Co-founder and senior employee departures are the highest-risk offboarding scenarios in crypto. Co-founders often hold original wallet seed phrases, were present at multisig setup, hold signing authority across governance platforms, and have broad, sometimes undocumented access to infrastructure and accounts that grew organically during the founding period. When a co-founder departure occurs, particularly an acrimonious one, the assumption must be that their access scope is broader than any formal record suggests, and the revocation process must be correspondingly comprehensive.
For guidance on how to structure access rights and separation of duties to reduce the risk that any single person accumulates unchecked authority in the first place, see our guide to separation of duties in crypto organisations.
Real Consequences: The Insider Threat Window
The insider threat created by delayed offboarding is not a hypothetical. Documented cases across the crypto industry include former employees who accessed exchange admin panels weeks after departure to modify withdrawal limits; contractors who retained GitHub access and pushed malicious commits to live repositories after their engagement ended; and departed team members who retained API keys to trading platforms and used them to place unauthorised orders. In each case, the organisation believed the access had been revoked because no formal offboarding process existed to verify it. The assumption that access ends automatically when employment ends is consistently wrong, and consistently costly.
"In crypto, offboarding is not an HR function with a security component. It is a security function with an HR component. The moment a departure decision is made, it must trigger an immediate, structured security response. The cost of getting this wrong is measured in irreversible asset loss, not in compliance penalties."
The Offboarding Security Checklist: People and Process
A reliable offboarding security process begins with a structured checklist that is triggered the moment a departure decision is made, not on the employee's last day, not after exit paperwork is signed, and certainly not in the weeks following departure when access reviews might eventually catch the gap. The checklist must be owned by a specific named role, tested periodically, and applied consistently regardless of the circumstances of departure.
Step 1: HR Notification to Security Team on Day of Departure Decision
The single most important process control in offboarding is the notification handoff from HR to the security team the moment a departure decision is confirmed, regardless of whether it is a voluntary resignation, a redundancy, a disciplinary dismissal, or a contract non-renewal. Every day between the departure decision and the security team's knowledge of it is a day of unnecessary exposure. The notification should include: the employee's name, role, start date, and last working day; the circumstances of departure (voluntary, involuntary, hostile, or standard); a preliminary list of known access categories based on their role; and a flag indicating whether emergency procedures are required.
Step 2: Immediate Access Freeze for Hostile Departures
For involuntary or hostile departures, all access must be suspended simultaneously at the moment the departure is communicated, or ideally before. This means coordinating across IT, the security team, and any platform administrators to execute revocations concurrently. The employee should not be informed of their departure before access has been frozen. This is not about distrust of any specific individual: it is a structural control that applies to all involuntary departures, precisely because it removes the incentive for a reactive response from a person who has just received difficult news.
Step 3: Standard 24-Hour Revocation for Friendly Departures
For voluntary departures on good terms, a 24-hour revocation window from the employee's last day is the target standard. This allows a structured, orderly handover of responsibilities and access while maintaining a tight enough window to prevent accidental or deliberate misuse after the relationship formally ends. The 24-hour window begins from the last working moment of the last day, not from when someone gets around to processing the paperwork.
Step 4: Asset Return
The physical asset return process must be documented and tracked. Assets to be returned include: all hardware wallets; all hardware security keys (YubiKeys, similar devices); all company laptops, workstations, and mobile devices; any physical access tokens or keycards; and any written materials containing credentials, seed phrases, or security configurations. Each item should be logged against a serial number or unique identifier in the device inventory. Receipt of return should be confirmed in writing. Assets not returned by the agreed date trigger an escalation process.
Step 5: Exit Interview
The security-focused exit interview is distinct from an HR exit interview. Its purpose is to identify access scope that may not be fully documented: shared credentials the employee knows; systems they accessed that may not appear in formal provisioning records; any keys, seed phrases, or credentials they have stored locally or in personal password managers; and any third-party services they set up using personal accounts on behalf of the organisation. The exit interview should not be adversarial, but it should be systematic. Its output is a supplementary access revocation list that feeds directly into the revocation process.
Step 6: NDA Reminder, IP Assignment, and Separation Agreement Reference
A legally valid offboarding process includes a written reminder of the departing individual's ongoing obligations under any non-disclosure agreement, intellectual property assignment provisions, and non-compete or non-solicitation clauses if applicable. For crypto organisations, IP assignment is particularly important: smart contract code, protocol design documents, and key generation processes may constitute valuable intellectual property that the departing individual might otherwise assert a claim over. The separation agreement should reference these obligations explicitly and be signed before final payroll.
Cryptographic Key Revocation and Rotation
Cryptographic key management during offboarding is the most technically demanding component of the process and the one most frequently done incorrectly or incompletely. The central principle is straightforward: any key that a departing employee had access to must be treated as potentially compromised from the moment their departure is confirmed, regardless of how trusted they were. Keys are not revoked because the individual is distrusted: they are rotated because the organisation cannot be certain that the key was not copied, cached, or stored in a personal credential manager at any point during the individual's tenure.
Revoking Signing Authority from Multisig Wallets
If the departing employee held a signing position on a Gnosis Safe multisig or any equivalent governance wallet, that signer must be removed from the multisig arrangement immediately. This typically requires a threshold of the remaining signers to approve a configuration transaction that removes the departing signer and adds a replacement if required. The new threshold should maintain or increase the M-of-N ratio: a 2-of-3 multisig that loses one signer becomes a 2-of-2, which is fragile and should be immediately expanded to a 2-of-3 or 3-of-5 with a new keyholder. All pending transactions in the multisig queue should be reviewed and re-validated before execution following any signer change.
Rotating Shared Keys
Any symmetric key, shared secret, or password that the departing employee had access to must be rotated on departure. This includes shared encryption keys for internal data stores, shared admin credentials to any platform, and any key material included in documentation or runbooks the employee had access to. The rotation must be completed before the employee's last day wherever operationally possible. Document every rotation: what was rotated, who performed the rotation, and when.
Rotating Exchange API Keys
Exchange API keys held by the departing employee or created under their exchange account must be revoked on the exchange platform and replaced. Any automated systems using those keys for trading, balance monitoring, or fund management must be updated to use the new credentials. Do not assume that deleting an employee's exchange account sub-user revokes API keys created under that account: verify directly on each platform that the keys are invalid. Test the revocation by attempting an authenticated call with the old key.
Rotating Cloud IAM Credentials
Cloud IAM credentials associated with the departing employee, including AWS access keys, GCP service account keys, and Azure service principal credentials, must be deactivated and then deleted. Deactivation before deletion allows a brief verification period to confirm that no production systems depend on those credentials before they are permanently removed. Any role assignments, group memberships, or permission boundaries associated with the individual's identity must also be removed. Review for any instance profiles or service accounts that were created by the departing employee and may be running with their associated permissions.
Rotating CI/CD Secrets and Deploy Keys
CI/CD pipeline secrets, GitHub Actions secrets, deploy keys, and any environment variable credentials that the departing employee had access to must be rotated. This is frequently overlooked because the credentials belong to the pipeline rather than the individual, but if the individual had visibility of those secrets during their tenure, the rotation remains necessary. Rotate all pipeline secrets associated with repositories the employee contributed to.
Rotating Smart Contract Governance Roles
If the departing employee held an admin, owner, or governance role in any deployed smart contract, that role must be transferred or revoked through the contract's access control mechanism before their departure is finalised. For contracts using OpenZeppelin's AccessControl or similar role-based systems, this means revoking their assigned role and confirming the transaction on-chain. For contracts with a single owner address, the ownership transfer should be initiated well before departure to allow the necessary lead time for multisig approvals.
For a broader framework on managing access rights and privileges in crypto organisations, see our guide to privileged access management for crypto firms.
Documentation of What Was Rotated and When
Every key rotation and revocation event should be logged in the offboarding record with: the credential type and identifier; the system or platform it belongs to; the date and time of revocation; the name of the person who executed the revocation; and confirmation of successful revocation (test results, platform screenshots, or audit log entries). This documentation serves as both an internal audit trail and evidence for regulatory compliance purposes.
Hardware Wallet and Device Recovery
Physical device recovery is a critical component of crypto offboarding that requires dedicated processes distinct from a standard IT asset return. The stakes are fundamentally different: a laptop can be remote-wiped if not returned, but a hardware wallet containing custody over live funds cannot simply be re-imaged.
Recovering Hardware Wallets from Departing Employees
Hardware wallets should be returned on or before the employee's last day and inventoried against the device register. The wallet should be inspected for physical integrity and then assessed against the offboarding record to confirm which addresses and signing positions it was associated with. Even if the wallet is returned intact and appears unmodified, the associated keys should be treated as potentially exposed and a key rotation initiated as described above. The hardware wallet itself can be factory-reset and reassigned, but the addresses it previously controlled should be retired from active use.
What to Do If a Hardware Wallet Is Not Returned
If a hardware wallet is not returned, treat it as a confirmed security incident rather than a property dispute. Initiate an immediate funds movement from all addresses associated with that device to new addresses on a freshly provisioned wallet. Remove the device's associated key from any multisig arrangements immediately. Notify relevant stakeholders, including any custodians or counterparties with whom those addresses are registered. Begin legal proceedings to recover the device under the terms of the employment contract while simultaneously completing the cryptographic remediation. Do not delay the cryptographic response pending legal action.
For guidance on physical security controls covering hardware wallets, devices, and their storage environments, see our post on physical security for crypto organisations.
Recovering Laptops and Performing Remote Wipes
Company-issued laptops should be returned in person or via tracked courier within a defined window. All laptops should have mobile device management (MDM) enrolled before they are issued, enabling remote wipe capability. If a laptop is not returned within the agreed timeframe or the circumstances of departure make return uncertain, a remote wipe should be initiated immediately. The wipe confirmation should be logged in the offboarding record. Laptops should also be assessed on return for any security tool tampering, bootloader modifications, or signs of keylogging hardware before being reassigned.
Device Inventory Audit Triggered by Offboarding
Every offboarding event should trigger a review of the device inventory for all assets assigned to that individual. The inventory must be reconciled against the return record. Any discrepancies, including undocumented devices that the employee was found to have been using, should be investigated and documented. In larger organisations, it is common to discover that employees were using personal devices for work purposes, which creates a shadow access category that the formal offboarding checklist may not capture. The exit interview is the primary mechanism for surfacing this.
Recovering YubiKeys and Hardware Tokens
Hardware second-factor authentication tokens, including YubiKeys and FIDO2 tokens, must be returned and removed from all accounts on which they were registered as an authenticator. Simply revoking the employee's account access on a platform does not automatically deregister a hardware token: on most platforms the token registration must be explicitly removed. If a hardware token is not returned, the associated accounts must be re-enrolled with new authentication credentials, and any recovery codes or backup authenticators registered by the departing employee should be invalidated.
Cloud and Infrastructure Access Removal
Cloud and infrastructure access removal in a crypto context must cover a broader and more granular scope than a standard IT deprovisioning checklist. Crypto infrastructure frequently spans multiple cloud providers, multiple account structures, and a variety of purpose-built access control layers that all require independent revocation.
Cloud IAM Role Removal: AWS, GCP, Azure
Remove the departing employee's IAM user, group memberships, and role assignments across every cloud account. This includes not just production accounts but staging, development, and sandbox environments. Audit the IAM audit log for any access keys, console sessions, or role assumptions that occurred in the final weeks before departure, looking for unusual activity. For AWS, specifically check for any IAM policies attached directly to the user rather than through groups, as these are frequently overlooked in standard deprovisioning steps.
GitHub Organisation and Repository Access Removal
Remove the departing employee from all GitHub organisations, repositories, and teams. Pay particular attention to any deploy keys or personal access tokens they may have created, which persist independently of their organisation membership and must be revoked explicitly. Review the repository's collaborator settings and any branch protection rules that reference the individual. For repositories containing smart contract code or infrastructure-as-code, rotate any secrets stored in repository settings that the employee would have had access to.
CI/CD Pipeline Access
Remove access to CI/CD platforms, including GitHub Actions, CircleCI, Jenkins, and any equivalent systems. Check for any API tokens or service accounts created by the departing employee within these platforms. Review pipeline configurations for any steps that explicitly reference the individual's credentials. Rotate secrets as described in the key revocation section above.
Monitoring Dashboard and Observability Access
Remove access to monitoring and observability platforms such as Datadog, Grafana, PagerDuty, and equivalent tools. These platforms frequently contain sensitive operational data about system architecture, transaction volumes, error rates, and alert thresholds. A former employee retaining access to monitoring infrastructure has a detailed ongoing view of operational activity and vulnerability indicators.
VPN Certificate Revocation
Revoke the departing employee's VPN certificates or credentials. For certificate-based VPN configurations, add the certificate serial number to the certificate revocation list (CRL). For credential-based configurations, remove the account from the VPN user directory. Test that the revocation has taken effect before closing the offboarding record. VPN access provides a route to internal network resources that may not be accessible from the public internet, and its revocation is as important as any direct application access removal.
DNS and Domain Registrar Access
DNS and domain registrar access is frequently overlooked in offboarding checklists but is a high-consequence access category. An individual with access to a domain registrar can redirect the organisation's web presence, intercept email, and in a crypto context redirect users to phishing sites mimicking the protocol's interface. Remove the departing employee from all domain registrar accounts and review the DNS records for any recent changes.
Cloud Secret Manager Access
Cloud secret managers such as AWS Secrets Manager, HashiCorp Vault, and GCP Secret Manager hold some of the most sensitive credentials in the infrastructure. Remove the departing employee's access policies to all secret stores. Rotate any secrets they had direct access to, as documented in the secret access audit log. Review audit logs to identify which specific secrets were accessed in the period leading up to departure.
Audit Log Confirmation
For each access removal step, obtain and preserve an audit log entry confirming the change. Cloud providers log IAM changes with timestamps and actor identity. These logs serve as evidence of timely revocation for compliance purposes and as a baseline for any subsequent investigation. Do not rely on memory or informal confirmation: the offboarding record should contain documented evidence of every revocation step.
Application and Service Access Removal
Beyond cloud infrastructure, departing employees in crypto organisations typically hold access to a wide range of application and service accounts that must each be individually addressed. The breadth of this category is often underestimated, particularly in fast-growing teams where tool adoption has outpaced access governance.
Communication Channels: Slack, Discord, Telegram
Remove the departing employee from the organisation's Slack workspace, Discord server, and any Telegram groups used for operational or team communications. For Discord and Telegram channels where the individual held admin or moderator privileges, transfer those roles to other team members before removing access. Verify that the individual is not a member of any private channels or groups they may have set up or been added to informally. For crypto protocols with community-facing Discord servers, also remove any special roles or permissions the individual held in community spaces.
Project Management Tools: Notion, Linear, Jira
Deactivate the departing employee's accounts on project management and documentation platforms. For Notion, ensure that any personally owned workspaces or pages containing company data are transferred to organisational ownership before the account is deactivated. Review for any API integrations or automations the individual may have set up using their account credentials, as these may continue to operate after account deactivation unless explicitly removed.
Email Account Deactivation and Mailbox Forwarding
Deactivate the departing employee's corporate email account on or before their last day. Do not allow the account to remain active in any capacity. Where business continuity requires that incoming email to the individual's address be handled, configure a non-delivery bounce notification or redirect to a generic mailbox monitored by the team, rather than leaving the account active. Preserve the mailbox contents according to your data retention policy and any applicable legal hold obligations. Remove the account from all distribution lists and shared mailboxes.
Exchange and Trading Platform Access
Remove the departing employee from all exchange accounts, OTC trading platforms, and custody platforms. For sub-account structures common on institutional exchange platforms, verify that all sub-accounts and API keys associated with the individual are deactivated. For custody platforms, update the list of authorised signatories and notify the custodian of the personnel change in writing.
DeFi Protocol Governance Roles
If the departing employee held voting power or delegation in any DeFi governance process, either directly through token holdings or through a delegated role, this must be reviewed as part of offboarding. Company-owned governance tokens held in accounts controlled by the individual should be recovered and moved to organisational custody. Delegated voting authority should be revoked through the relevant governance platform. This is a frequently overlooked category with significant protocol governance implications.
Multisig Governance Platforms: Gnosis Safe
As covered in the key revocation section, remove the departing employee's signing address from all Gnosis Safe instances and equivalent multisig governance platforms. Review pending transactions in each Safe to confirm they were initiated and approved under the appropriate access controls. Notify any co-signers of the personnel change so they can independently validate the identity of remaining signers before co-signing future transactions.
Social Media Account Access
Review and revoke access to all corporate social media accounts. This includes Twitter/X, LinkedIn company pages, YouTube channels, and any community platforms where the individual managed content on behalf of the organisation. Change passwords on all shared social media accounts and review any scheduled posts the departing employee may have queued. Remove their access from any social media management platforms used to coordinate posting.
For a comprehensive framework on managing all identity and access categories across an organisation, see our guide to identity and access management for Web3 organisations.
Contractor and Third-Party Offboarding
Contractor and third-party offboarding is systematically worse than employee offboarding in most crypto organisations, for one simple structural reason: there is no automatic HR trigger. Employees have a defined employment end date that HR must process. Contractors have a project end or contract renewal date that may pass without anyone initiating a formal offboarding review. The result is that contractors routinely retain access to systems, repositories, and communication channels long after their engagement has formally concluded.
Why Contractor Access Lingers Longer
Three factors combine to extend contractor access beyond the end of an engagement. First, no centralised offboarding trigger exists: access provisioning for contractors is often handled ad hoc by the project team rather than through a formal HR process. Second, contractors frequently have broader access than their role technically requires, because access was provisioned quickly at the start of an engagement without a thorough least-privilege review. Third, the access categories that contractors accumulate, particularly repository access, communication platform membership, and API credentials, are often not tracked in a central inventory that would surface the gap at engagement end.
Project-End Access Revocation Checklist
A project-end access revocation checklist for contractors should be initiated at the point a contract end date is known, not after the engagement concludes. It should cover all the same categories as an employee offboarding: cloud IAM, repository access, CI/CD, communication platforms, project management tools, and any keys or tokens provided. Contractors with access to private keys, multisig signing authority, or exchange credentials require the same key rotation treatment as departing employees: the fact that the relationship was contractual rather than employed does not reduce the cryptographic risk.
Third-Party Vendor Access Review on Contract End
Third-party vendors with ongoing system access, including security tool providers, monitoring services, and development agencies, should have their access reviewed at every contract renewal point and fully revoked if the contract is not renewed. Vendor access should be scoped to the minimum necessary, time-limited by default, and logged centrally so that contract end events automatically surface an access review requirement. For comprehensive guidance on managing third-party security risk, see our post on vendor risk management for Web3 organisations.
Stale Access Detection
Periodic stale access reviews should be run at least quarterly, specifically targeting accounts that have not had recent login activity. Many identity and access management platforms support automated detection of dormant accounts. For cloud IAM, AWS IAM Access Analyser and equivalent tools in GCP and Azure can identify unused credentials and roles. GitHub provides last-active-date data for organisation members. These tools should be configured as a backstop to catch any contractor offboarding that slipped through the primary process.
Hostile Departures: Emergency Offboarding
Emergency offboarding for hostile, involuntary, or acrimonious departures follows a fundamentally different logic from standard offboarding. The standard process is sequential and systematic: notification, checklist execution, revocation over 24 hours. Emergency offboarding must be simultaneous and immediate. The sequence in which access is revoked, and the sequence in which the departing individual is informed, are security-critical decisions.
Immediate Simultaneous Revocation
For hostile departures, the sequence is: execute simultaneous access revocation across all categories, then inform the individual of their departure. This is not about treating the individual as a criminal: it is a structural control that applies to all involuntary separations. The logic is straightforward. A person who learns they are being dismissed before their access is revoked has a window, however brief, during which they retain both the motivation and the means to act against the organisation's interests. Closing that window requires that access revocation and the departure notification are decoupled, with revocation happening first.
Simultaneous revocation across all access categories requires advance preparation: you cannot coordinate a multi-system revocation in real time without a prepared runbook, pre-assigned roles for each revocation task, and a tested communication channel among the revocation team. The emergency offboarding runbook should designate who is responsible for cloud IAM, who handles repository access, who manages exchange and custody platforms, who contacts communication platform administrators, and who coordinates hardware recovery. Each person executes their task on a confirmed signal, not sequentially.
Legal Hold on Company Data
As soon as a hostile departure is confirmed, a legal hold must be placed on all company data associated with the departing individual. This means preserving email archives, Slack message history, Notion and documentation platform records, and any other data stores the individual had access to. Legal holds prevent the accidental destruction of evidence in subsequent legal proceedings. The hold should be implemented before any device wipe or account deactivation that might destroy data, and the hold itself should be coordinated with legal counsel.
Forensic Imaging of Devices
For hostile departures where data exfiltration is suspected, corporate devices should be forensically imaged before being wiped and reissued. A forensic image preserves the full disk contents at the time of departure and can be analysed subsequently to determine whether sensitive data was copied, whether communications were deleted, or whether any malicious software was installed. Forensic imaging should be performed by a qualified professional using accepted forensic procedures to ensure the evidence is legally defensible. For guidance on crypto-specific forensic investigation and evidence preservation, see our post on blockchain forensics and crypto investigation.
Monitoring for Data Exfiltration in Final Weeks
In many insider threat cases, data exfiltration begins before the formal departure event, particularly in cases where the employee may have anticipated their dismissal or made a decision to leave before formally notifying the organisation. Data loss prevention (DLP) tools, email gateway logs, USB device activity records, and cloud storage access patterns should be reviewed for the period leading up to the departure decision. Anomalous patterns such as bulk downloads, unusual after-hours access, large email attachments sent to personal addresses, or mass repository cloning are indicators that require investigation.
Involving Legal Counsel
Legal counsel should be involved in any hostile departure from the outset. They advise on the legal hold requirements, the terms of the separation agreement and any additional provisions required given the circumstances, the enforceability of NDA and IP assignment provisions, and any obligations to notify regulators or counterparties of personnel changes. In cases where a co-founder or senior officer is departing under contentious circumstances, legal counsel should also advise on the corporate governance implications, including any board resolutions required to remove signing authority or directorship.
Building an Offboarding Programme
Reactive offboarding, where a process is improvised each time a departure occurs, is not a programme. A programme is documented, tested, owned, and consistently applied. For crypto organisations, the investment in building a real offboarding programme is justified by the catastrophic cost of a single offboarding failure.
The Offboarding Runbook
A documented offboarding runbook is the foundational artefact of an offboarding programme. It sets out every step of the offboarding process in sequential order, designates the responsible owner for each step, specifies the timeline within which each step must be completed, and identifies the evidence that must be collected to confirm completion. The runbook must be version-controlled, reviewed at least annually, and updated whenever a new system or access category is added to the organisation's environment. It should have a named owner, typically the head of security or CISO, who is responsible for its currency and its execution on every departure event.
Role-Specific Offboarding Checklists
High-privilege roles require supplementary checklists beyond the standard offboarding process. A developer departing requires additional repository access checks, code review of recent commits, and rotation of any deploy keys or CI/CD secrets. A treasury signer departing requires multisig reconfiguration, exchange credential rotation, and a review of any pending transactions they initiated. A system administrator departing requires a comprehensive cloud IAM audit, VPN revocation, and a review of any automation or scheduled tasks running under their credentials. An exchange trader departing requires removal from all trading platforms, API key revocation, and a review of any open positions. Role-specific checklists prevent the standard runbook from missing access categories that are specific to specialised roles.
Offboarding Audit Trail
Every offboarding event should generate a complete audit trail: when the departure decision was made and communicated to security; what was revoked; when each revocation was executed; who executed it; and what evidence confirms each revocation was successful. The audit trail should be stored in a tamper-evident system, separate from the systems being managed during the offboarding. For ISO 27001 compliance, this audit trail is direct evidence for Annex A Control 6.5 on responsibilities after termination.
Periodic Stale Access Reviews
Even a well-executed offboarding programme will occasionally miss an access category. Periodic stale access reviews, run at least quarterly, are the backstop that catches what the primary process missed. These reviews should identify any accounts with no recent login activity, any API keys that have not been used recently, and any role assignments that do not map to current employees. Any access identified in a stale access review that cannot be attributed to an active, authorised user should be revoked immediately and investigated to determine whether it represents a missed offboarding step.
Offboarding Simulation as Part of Security Testing
Periodic offboarding simulations, similar to the tabletop exercises used in business continuity planning, are an important mechanism for validating that the programme works under real conditions. A simulation selects a hypothetical departed employee, executes the offboarding runbook against their actual access profile, identifies any gaps that the process would have missed, and tests the coordination and timing of the revocation team. Simulations should be documented and their findings fed back into runbook improvements. An offboarding programme that has never been tested is an untested control, and untested controls consistently underperform under real-world conditions.
Building a strong offboarding programme is inseparable from building a security-conscious organisational culture. For a broader framework on embedding security awareness and process discipline across an organisation, see our guide to building a security culture in Web3 organisations.
Regulatory Requirements
Formal offboarding security processes are not merely best practice: they are increasingly required by the regulatory frameworks affecting crypto and digital asset firms across European and international markets. Demonstrating a documented, consistently applied offboarding programme is a compliance requirement under multiple frameworks simultaneously.
DORA Article 5: ICT Risk Governance and Personnel Changes
The Digital Operational Resilience Act, which applies directly to crypto asset service providers (CASPs) regulated under MiCA, requires that ICT risk governance frameworks address personnel changes affecting access to ICT systems. DORA's regulatory technical standards on ICT risk management require that financial entities maintain procedures for revoking access rights promptly when personnel roles change or employment ends. Departure events must be treated as ICT risk events triggering a defined response. For a full analysis of DORA requirements for crypto firms, see our guide to DORA compliance for crypto and digital asset firms.
ISO 27001 Annex A.6.5: Responsibilities After Termination
ISO 27001:2022 Annex A Control 6.5 specifically addresses information security responsibilities and duties that remain in force after employment termination or change. It requires organisations to communicate ongoing obligations to departing personnel, revoke access rights promptly, and maintain documentation of the revocation process. Auditors assessing ISO 27001 conformance will specifically request evidence of offboarding procedures and sample offboarding records to confirm consistent application. The control complements Annex A.5.15 (access control) and Annex A.5.18 (access rights management) to form a complete access lifecycle framework. For guidance on the certification pathway, see our post on ISO 27001 certification for crypto organisations.
MiCA Operational Risk Management
MiCA's operational risk management requirements for CASPs include obligations to maintain adequate governance over personnel with access to critical systems and assets. A CASP that cannot demonstrate a documented offboarding process covering access to custody systems, trading platforms, and client data faces a material gap in its operational risk management framework. National competent authorities assessing CASP authorisation applications will scrutinise personnel governance arrangements including offboarding procedures.
GDPR Considerations for Departed Employee Data
GDPR obligations interact with the offboarding process in two directions. First, the departed employee themselves is a data subject: their personal data held in HR and payroll systems must be retained only for legally required periods and then deleted. Second, any accounts or data stores the departed employee administered may contain the personal data of customers or other employees. These must be transferred to organisational custody and managed under the organisation's data governance framework. The deactivation of a departed employee's account must not result in the deletion of personal data that the organisation is required to retain, and must not leave personal data accessible via a dormant account that lacks active governance.
Frequently Asked Questions
How quickly should access be revoked when an employee leaves a crypto firm?
For friendly departures, access should be fully revoked within 24 hours of the employee's last working day. For hostile or involuntary departures, all access should be revoked simultaneously and immediately at the moment the departure decision is made, before the employee is informed. In crypto, any delay creates a window during which a departing employee retains the ability to exfiltrate data, copy keys, or in the worst case move funds from a wallet to which they retain access. The standard 72-day average revocation delay observed in traditional organisations is unacceptable in a crypto context.
What happens if a departing employee refuses to return a hardware wallet?
If a hardware wallet is not returned, treat it as a confirmed security incident rather than a property dispute. Initiate an immediate funds movement from all addresses associated with that device to new addresses on a freshly provisioned wallet. Remove the device's associated key from any multisig arrangements immediately. Notify relevant stakeholders, including any custodians or counterparties with whom those addresses are registered. Legal remedies can be pursued in parallel, but they must never delay the immediate cryptographic remediation. The unreturned device must be treated as compromised from the moment it fails to be returned.
Do contractors need the same offboarding process as employees?
Yes, and in practice contractor offboarding requires more active management than employee offboarding because there is no automatic HR trigger at the end of a contract. Contractors frequently retain access to systems, repositories, and communication channels for weeks or months after their engagement ends because nobody initiates a formal offboarding process. A contractor offboarding checklist should be triggered at project completion or contract end date, covering all the same access categories as an employee: cloud IAM, GitHub, communication channels, VPN, and any keys or devices provided. For contractors with access to private keys or multisig signing authority, the standard is identical to that for an employee: immediate revocation and key rotation on departure.
What should a crypto firm do if it suspects a departing employee has already copied sensitive data?
Immediately involve legal counsel and initiate a legal hold on all company data associated with that individual. Engage a forensic investigator to image the employee's device before it is wiped, to preserve evidence of any data exfiltration. Review data loss prevention logs, email gateway records, USB activity, and cloud storage access logs for the period leading up to departure. If private keys, seed phrases, or exchange API keys may have been copied, treat it as an active incident: rotate all affected keys immediately and do not wait for the forensic investigation to conclude before taking cryptographic remediation steps.
Which regulatory frameworks require a formal employee offboarding security process?
Several major frameworks impose obligations that directly require or imply a structured offboarding security process. DORA Article 5 requires that ICT risk governance includes controls over personnel changes. ISO 27001:2022 Annex A Control 6.5 explicitly requires that information security responsibilities and duties remain enforceable after termination and that access rights are removed promptly. MiCA operational risk management requirements include governance over personnel with access to critical systems. GDPR also requires consideration of departed employee data, including the deactivation of accounts holding personal data. Firms pursuing ISO 27001 certification or DORA compliance should document their offboarding process as a formal control with evidence of consistent application.