Accountability sits with the organisation that controlled the customer assets, the operating identities, and the wind-down plan. Regulators may set the deadline, but the firm owns the execution. That means leadership, compliance, IAM, and operations need a shared closure model that proves services can be suspended or transferred without leaving access behind.
Why This Matters for Security Teams
When a crypto firm loses its right to operate, the issue is not only legal closure. The real security question is who can still move assets, call APIs, sign transactions, or export records after the business is no longer authorised to do so. That makes operating identities, custodial keys, and service-account permissions part of the shutdown problem, not a separate technical detail. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is exactly the kind of gap that turns a licence loss into a control failure.
For security teams, the accountability chain has to include executive ownership, compliance oversight, identity administrators, and platform operators. Regulatory deadlines may define when a wind-down begins, but they do not revoke access on their own. The firm must prove that privileged access is removed, secrets are retired, and customer-facing services can be suspended or transferred without leaving dormant credentials behind. That is why closure planning belongs in the same governance model as access management and incident response. The NIST Cybersecurity Framework 2.0 treats governance and risk management as operational duties, not paperwork after the fact. In practice, many security teams encounter leftover signing keys only after a regulator, acquirer, or forensic reviewer asks who could still act on behalf of the firm.
How It Works in Practice
Accountability starts with ownership of the shutdown plan. The organisation should define which identities, keys, wallets, and automated workflows must be disabled, which records must be preserved, and which actions require dual control during the wind-down. In a crypto environment, that usually includes exchange admin accounts, treasury signing roles, custody-system credentials, API keys used by bots, and emergency access paths held by operations or vendors.
A workable model combines governance, inventory, and technical enforcement:
- Maintain a live inventory of all non-human identities, including service accounts, bots, and signing credentials tied to production systems.
- Classify each identity by business function so the closure team can revoke high-risk access first.
- Use just-in-time access for any remaining operational work, with short TTLs and automatic expiry.
- Revoke or rotate secrets before suspension, then verify that no backup process can reintroduce old credentials.
- Transfer or escrow records in a controlled state, with audit logs preserved for regulators and insolvency teams.
This approach aligns with the control logic in NIST Cybersecurity Framework 2.0, especially governance, access control, and recovery planning. It also reflects the lifecycle and offboarding emphasis in Ultimate Guide to NHIs, where the key question is whether machine identities can be discovered, constrained, and retired before they become an orphaned path to customer assets. A firm that cannot enumerate its NHIs cannot credibly claim it has controlled its closure exposure. These controls tend to break down when trading, custody, and DevOps teams each manage their own secrets store because no single owner can confirm complete revocation.
Common Variations and Edge Cases
Tighter shutdown control often increases operational friction, requiring organisations to balance rapid suspension against customer recovery, forensic preservation, and regulatory reporting. That tradeoff becomes harder when the firm is insolvent, under emergency supervision, or handing off assets to an administrator or acquirer. Current guidance suggests that accountability does not disappear in those scenarios; it shifts to the party formally responsible for the wind-down, but the original firm still owns the integrity of its access history and the completeness of its revocation steps.
One edge case is partial continuity, where customer portals remain available while internal trading or settlement systems are shut down. Another is third-party dependency, where cloud, wallet, or custody providers still hold privileged keys after the firm has lost operating status. In both cases, the closure model must distinguish between service continuity and authority to act. Best practice is evolving here, but the rule is simple: if a system can still sign, transfer, or disclose on behalf of the firm, someone remains accountable for that access. The NIST Cybersecurity Framework 2.0 supports that operational view by tying risk ownership to concrete protective actions, not corporate status alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Covers lifecycle offboarding and revocation of machine identities during closure. |
| NIST CSF 2.0 | GV.RM-01 | Governance requires clear risk ownership for shutdown and access retirement. |
| NIST CSF 2.0 | PR.AA-03 | Access management is central to disabling signing and administrative privileges. |
Inventory and revoke every non-human identity before wind-down completes, then verify no dormant access remains.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
