Executive Summary: The accounts that can move funds, deploy contracts, reconfigure infrastructure, and control validator keys are the accounts that adversaries target most aggressively. Across the majority of major crypto thefts, the attack path ran through a privileged user or a privileged system: not through a cryptographic break. Privileged access management (PAM) is the discipline that protects these accounts. It is standard practice in defence, financial services, and critical infrastructure. It is almost entirely absent from crypto firms. This post explains what PAM is, why the crypto context makes it particularly urgent, how nation-state actors exploit the gap, and how to implement a practical PAM programme in a firm of five to fifty people.
What Is Privileged Access Management
Privileged access management is the set of policies, processes, and technologies that govern which individuals and systems can access high-value accounts, under what conditions, for how long, and with what degree of oversight. In traditional enterprise security, the most common PAM use cases involve domain administrator accounts, database administrators, root access to servers, and firewall or network infrastructure credentials. In a crypto firm, the definition of "privileged" must be substantially expanded to reflect the unique asset profile.
A privileged account in a crypto context is any account whose compromise could result in material financial loss, reputational damage, or loss of operational control. That includes: treasury multisig signing keys, smart contract deployer wallets with upgrade or admin authority, validator key material and withdrawal credentials, exchange API keys with withdrawal permissions, infrastructure administrator accounts with access to production nodes or signing infrastructure, and configuration access to bridges, oracles, and other protocol components. The common thread is that unauthorised use of these accounts has immediate, irreversible financial consequences.
PAM addresses three fundamental problems. The first is the breadth of access problem: too many people have access to too many privileged accounts, with no mechanism to limit scope or duration. The second is the visibility problem: no audit trail exists of who used a privileged account, when, from where, and what they did. The third is the credential security problem: privileged credentials are stored insecurely, shared informally, or not rotated after personnel changes. PAM programmes address all three simultaneously through a combination of People (roles, responsibilities, training), Process (access request workflows, approval gates, periodic reviews), and Technology (PAM tooling, session management, credential vaulting).
Why Crypto Firms Are High-Risk Targets
The risk profile of privileged accounts at a crypto firm is qualitatively different from that of a traditional financial institution, for several reasons that compound each other.
Transaction irreversibility. Unlike a bank transfer, a blockchain transaction cannot be recalled. There is no fraud department to call, no chargeback mechanism, and no regulator who can instruct a counterparty to return funds. Once a privileged account is used to authorise a malicious transaction, the loss is permanent. This dramatically raises the stakes of every privileged access decision.
Direct bearer asset control. In most industries, privileged access grants administrative control over systems that hold assets. In crypto, privileged access frequently grants direct cryptographic control over the assets themselves. The signing key is the asset. There is no additional layer of institutional controls between the key and the funds: whoever controls the key controls the money.
Absence of institutional controls. A traditional bank clerk with payment initiation access operates within a web of institutional controls: dual authorisation requirements, transaction limits, fraud monitoring, reconciliation processes, and regulatory oversight. A crypto treasury signer at a DeFi protocol may have no comparable surrounding controls. The multisig threshold is the entire control structure, and everything rests on the integrity of the individuals holding the keys.
High-value, low-maturity targets. Nation-state actors and sophisticated criminal organisations understand that crypto firms combine extremely high asset values with security practices that lag years behind comparably valued traditional financial institutions. Lazarus Group has exploited this gap systematically for nearly a decade. The expected value of targeting a crypto firm is far higher than attacking an equivalent-value bank, because the defences are weaker and the payoff is immediate and irreversible.
Remote-first, distributed teams. Most crypto firms operate with fully remote, internationally distributed teams. This creates a privileged access problem that traditional perimeter-based security cannot address: privileged accounts are accessed from home networks, shared workspaces, and multiple device types, with no consistent security baseline across the team.
The Privileged User Problem in Web3
The most dangerous misconception in Web3 security is that multisig provides comprehensive protection for treasury and governance operations. Multisig is a cryptographic access control mechanism: it requires multiple private key signatures to authorise a transaction. What it does not provide is any of the following: control over who has access to the signing keys, detection of whether a signer's device has been compromised, verification that the transaction being signed is the transaction the signer believes they are signing, or an audit trail of the signing process itself.
The February 2025 Bybit hack is the definitive case study. As documented in the Bybit hack analysis, Lazarus Group did not break the Safe multisig cryptography. They compromised the interface through which signers reviewed and approved transactions, so that signers were shown a routine transfer while actually authorising a delegatecall that replaced the Safe's implementation contract with attacker-controlled logic. The three signers who approved the transaction did so in good faith. Their keys were not stolen. They were used as intended: by the account holders themselves, who had no way of knowing they were signing a malicious transaction.
This is a PAM failure. The signing process lacked controls that would have detected or prevented the attack: independent transaction hash verification through an isolated channel, hardware wallet confirmation on a tamper-evident display, integrity monitoring of the signing interface, and session recording that would have captured anomalous behaviour. These are all PAM controls. None of them are provided by multisig itself.
"Multisig distributes the custody of signing keys. Privileged access management controls the conditions under which those keys are used, monitored, and protected. One without the other leaves half the problem unsolved."
The privileged user problem in Web3 extends well beyond treasury signers. Smart contract deployer accounts are frequently held by individual developers with no formal access controls around their use. Protocol upgrade authority is often vested in a single team multisig with no documented approval process for when upgrades are appropriate. Validator key material is sometimes stored on internet-connected systems with no HSM protection. Infrastructure admin accounts for nodes, RPC providers, and cloud hosting may be shared across team members with no individual accountability.
In each of these cases, the privileged account represents a direct path to material harm: protocol upgrades that introduce vulnerabilities, validator slashing or withdrawal key theft, infrastructure compromise that enables transaction manipulation. The Lazarus Group's operational playbook is specifically designed to identify and exploit these privileged users: through targeted social engineering, supply chain compromise, and persistent access to developer environments.
Core PAM Controls for Crypto Organisations
A mature PAM programme is built on five foundational control categories. Each is applicable to crypto firms of any size, with implementations scaled to the team's complexity and risk profile.
1. Privileged Account Discovery and Inventory
You cannot manage what you cannot see. The first step in any PAM programme is a comprehensive inventory of all privileged accounts across the organisation: on-chain (signing keys, deployer wallets, multisig membership), off-chain infrastructure (cloud administrator accounts, node access credentials, CI/CD pipeline credentials), and SaaS platforms (exchange API keys, custody platform admin access, communication tool administrator accounts). This inventory should document the account owner, the systems or assets it can affect, the current storage mechanism for credentials, and the last review date.
Most crypto firms that undergo this exercise for the first time discover significantly more privileged accounts than they expected, including orphaned accounts from former team members, shared credentials used across multiple individuals, and API keys with broader permissions than operationally necessary. The inventory process itself frequently surfaces critical vulnerabilities before any technical controls are deployed.
2. Principle of Least Privilege
The principle of least privilege holds that every user, service, and system should have the minimum access necessary to perform its function, and no more. In practice, crypto firms routinely violate this principle by default: developers have production deployment access they rarely use, team members hold signing authority on multisigs even after their operational role no longer requires it, and infrastructure administrators hold root access to all systems regardless of which subset they actively manage.
Implementing least privilege requires a role-based access model in which access rights are tied to job function rather than individual preference. Treasury signing authority belongs to designated roles (CFO, treasury committee members) rather than to "whoever happens to have the key". Production infrastructure access belongs to designated infrastructure roles, not to all developers. Smart contract upgrade authority belongs to a defined governance process, not to the deployer's personal wallet. Each role is defined with its minimum required access, and access outside that scope requires a formal exception process.
3. Just-In-Time Access
Standing privileged access: where a user holds continuous, unrestricted access to privileged systems: is one of the highest-risk configurations in any security environment. If that user's credentials are compromised, the attacker inherits standing access and can use it at a time of their choosing, potentially weeks or months after initial compromise. Just-in-time (JIT) access eliminates standing access by design: privileged access is requested for a specific purpose, approved by a designated authority, granted for a defined time window, and automatically revoked when that window expires.
In a crypto context, JIT access is particularly powerful for infrastructure administration. Rather than holding continuous root access to production nodes, an infrastructure administrator requests access for a specific maintenance task, receives time-limited credentials that expire after the task window, and has their session recorded throughout. Any access outside this workflow is immediately anomalous and detectable. The blast radius of a compromised infrastructure admin account is dramatically reduced because there are no standing privileged sessions to inherit.
4. Session Recording and Monitoring
All privileged sessions should be recorded: keystrokes, commands, and where applicable, screen activity. This serves two purposes. The detective purpose is that recorded sessions provide an audit trail that enables forensic investigation following an incident: understanding exactly what was accessed, what commands were run, and what data was exfiltrated. The deterrent purpose is that users who know their privileged sessions are recorded are less likely to engage in careless or malicious behaviour, and social engineering victims who are compromised via their privileged session will generate a record that enables faster detection and response.
For signing operations specifically, session recording should capture the full context of each signing event: the transaction parameters as presented to the signer, the device and network from which the signing occurred, and any anomalous activity in the session immediately preceding the signature. Integrating this with out-of-band verification (see below) creates a comprehensive audit trail for every treasury operation.
5. Credential Vaulting and Rotation
Privileged credentials should not be stored in team password managers, shared documents, Slack messages, or any location accessible outside a dedicated privileged access vault. Credential vaulting ensures that privileged passwords, API keys, and SSH keys are stored in an encrypted, access-controlled repository with individual authentication required for each retrieval. All retrievals are logged. Credentials are automatically rotated on a defined schedule or immediately following any security event that may have exposed them.
For on-chain signing keys specifically, credential vaulting must be combined with hardware security module (HSM) protection: the private key material never exists in software or memory outside the HSM boundary. This applies equally to treasury keys, smart contract deployer keys, and validator withdrawal credentials. Any signing key that can be exported to a software environment is a signing key that can be stolen by malware.
Out-of-Band Verification for High-Value Transactions
The Bybit attack vector: transaction parameter manipulation via a compromised signing interface: is defeated by out-of-band verification. Before any high-value signing event, signers should independently verify the transaction hash and critical parameters through a channel that is entirely separate from the primary signing workflow: a dedicated hardware wallet display, a separate device with a separate network connection, or a real-time voice confirmation with other signers. This ensures that even if the primary signing interface has been compromised, the verification channel remains trustworthy.
Out-of-band verification should be a documented, mandatory process for all transactions above a defined threshold. The threshold should be set conservatively: the overhead of verification is trivially small compared to the consequences of a compromised signing event. A protocol that loses $1.4 billion because signers trusted a compromised interface would have been well served by a thirty-second verification call.
PAM and Regulatory Compliance
For firms operating within European regulatory frameworks, PAM is not merely best practice: it is a compliance obligation. Understanding the specific requirements helps align PAM implementation with existing compliance programmes and strengthens the regulatory case for the investment.
DORA (Digital Operational Resilience Act). DORA's ICT risk management requirements mandate that in-scope firms implement access control policies based on the need-to-know and least-privilege principles, maintain audit logs of privileged operations, conduct periodic reviews of access rights, and ensure that critical ICT systems have appropriate monitoring in place. The DORA compliance framework applies to crypto-asset service providers regulated under MiCA, as well as to traditional financial institutions with digital asset operations. PAM controls directly address multiple DORA technical requirements, including privileged access governance, session logging, and periodic access rights review.
MiCA (Markets in Crypto-Assets Regulation). MiCA's governance requirements for crypto-asset service providers include organisational requirements around the management of conflicts of interest, information security, and operational resilience. The MiCA compliance requirements for CASPs include maintaining adequate internal controls over digital asset custody and ensuring that access to client assets is appropriately restricted. PAM directly supports these requirements by formalising the controls around who can access custody infrastructure and under what conditions.
ISO 27001 and NIST frameworks. ISO 27001 Annex A.9 provides a comprehensive access control framework that explicitly covers privileged access, with controls for privileged utility programmes, system administrator accounts, and the management of privileged access rights. NIST SP 800-53 provides the AC (Access Control) and AU (Audit and Accountability) control families, which together define a full PAM control baseline applicable to any organisation handling high-value digital assets. Aligning PAM implementation with these frameworks provides a recognised benchmark against which to assess maturity and demonstrate compliance to institutional investors and regulators.
How to Implement PAM Without Disrupting Operations
The most common reason crypto firms defer PAM implementation is the perceived disruption cost: concern that formalising access controls will slow down operations, create friction in an agile development environment, or require tools and processes that the team lacks the capacity to manage. This concern is understandable but overweighted. A phased approach allows PAM controls to be introduced incrementally, with each phase delivering security value while the operational impact of subsequent phases is understood and managed.
Phase 1: Discovery and Quick Wins (Weeks 1-4)
Conduct a full privileged account inventory across all on-chain and off-chain systems. Document findings in a privileged access register. Immediately remediate critical findings: remove former team members from multisig structures and shared credential stores, revoke API keys with broader permissions than necessary, and enforce phishing-resistant MFA (hardware security keys, not SMS or authenticator apps) on all privileged accounts. Eliminate all shared credentials by creating individual accounts where possible. Establish a basic access review process: at minimum, a quarterly review of who has access to what and whether that access remains appropriate.
Phase 2: Process and Policy (Weeks 4-8)
Document a Privileged Access Policy that defines which accounts are classified as privileged, the approval process for granting privileged access, the maximum duration of any privileged access grant, the session recording and logging requirements for privileged sessions, and the process for revoking access when no longer required. Document a Treasury Signing Protocol that specifies the out-of-band verification process for all transactions above defined thresholds, the communication channel for signing coordination, and the escalation path if a signing event is anomalous. Train all individuals with privileged access on the policy requirements and on the social engineering tactics used to target privileged users.
Phase 3: Technology Implementation (Weeks 8-16)
Deploy a PAM tool appropriate to the team's scale and complexity. For infrastructure credential management, HashiCorp Vault provides enterprise-grade secret management and is widely used in the Web3 infrastructure space. For broader PAM including session recording and JIT access, BeyondTrust or CyberArk provide comprehensive capability. For smaller teams, Teleport provides open-source infrastructure access management with session recording and audit logging at lower operational overhead.
Implement HSM-based key management for all critical signing keys. Hardware security modules ensure that private key material never exists in software memory: the HSM performs signing operations internally and the key can never be exported. For validator key management and treasury operations, HSM integration is non-negotiable in a mature security programme.
Phase 4: Continuous Improvement
PAM is not a one-time deployment: it requires continuous improvement as the organisation evolves, the threat landscape changes, and new privileged accounts are created through product development. Establish quarterly privileged access reviews as a standing process. Include PAM maturity in your annual security assessment. Conduct tabletop exercises that simulate privileged account compromise to test whether detection, response, and containment processes work as designed.
The blockchain security audit framework should incorporate PAM assessment as a core component: auditors evaluating a protocol's security should assess not only the smart contract code but the access controls around the accounts that govern it. A protocol with a perfectly audited codebase but an uncontrolled admin key is not a secure protocol.
Sizing PAM for Small Teams
A common objection is that PAM frameworks are designed for enterprise environments with dedicated security teams, not for a five-person startup. This is partially true of the tooling complexity, but not of the underlying principles. Least privilege, JIT access, out-of-band verification, and session recording are principles that can be implemented procedurally before any PAM tooling is deployed. A five-person team can implement a PAM programme using documented processes, hardware security keys, individual accounts replacing shared credentials, and a simple access register maintained in a secured document. The tooling adds efficiency and enforceability, but the principles are tool-agnostic.
The appropriate question is not whether a small team can afford PAM, but whether they can afford not to have it. A five-person team holding $50 million in protocol treasury funds is not a small target. It is a high-value target with a small security team: exactly the combination that Lazarus Group's operational profile is optimised to exploit. The man-in-the-middle attack surface in crypto extends directly into the privileged access layer, making PAM an essential part of a comprehensive defence posture regardless of team size.
Building the Defence-Grade Mindset
The teams that consistently protect high-value accounts in demanding environments share a common orientation: they treat privileged access as a liability to be minimised, not a convenience to be maximised. Every privileged account that exists is a risk. Every minute of standing privileged access is an exposure window. Every signing event that occurs without independent verification is a potential attack surface.
This mindset is standard in defence and critical infrastructure environments, where the consequences of privileged account compromise are measured in national security terms. The consequences of privileged account compromise in crypto are measured in hundreds of millions of dollars and the destruction of protocols that users depend on. The stakes justify the same degree of rigour. The People who hold privileged accounts must be trained, vetted, and monitored. The Processes around privileged access must be documented, enforced, and regularly tested. The Technology must make privileged sessions visible, controllable, and auditable. Together, these three dimensions define a PAM programme that is proportionate to the threat.
Frequently Asked Questions
What is privileged access management in the context of crypto firms?
Privileged access management (PAM) in crypto firms refers to the policies, processes, and technologies used to control, monitor, and audit access to high-value accounts and systems: including treasury signing keys, infrastructure admin accounts, smart contract deployer wallets, validator key access, and exchange API credentials. PAM ensures that only authorised individuals can access these assets, that access is time-limited and purpose-bound, and that all privileged activity is logged and reviewable.
Is multisig the same as privileged access management?
No. Multisig is a cryptographic access control mechanism that requires multiple private key signatures to authorise a transaction. PAM is a broader discipline covering who has access to those signing keys, under what conditions, with what oversight, and with what audit trail. The Bybit hack demonstrates the gap: the multisig architecture was functioning correctly, but the signing process lacked the PAM controls (out-of-band verification, session integrity monitoring, signing interface integrity checks) that would have detected or prevented the attack.
What is just-in-time access and why does it matter for crypto security?
Just-in-time access is a PAM principle in which privileged access is granted only for the specific period it is needed for a specific task, then automatically revoked. In a crypto firm context, this means an infrastructure administrator does not hold standing access to production systems: they request access, the request is approved with a defined time window, and access is automatically removed after that window expires. JIT access dramatically reduces the blast radius if a privileged user's credentials are compromised, because there are no permanently active privileged sessions to inherit.
Which regulatory frameworks require PAM controls for crypto and financial firms?
The EU's Digital Operational Resilience Act (DORA) mandates privileged access management as part of its ICT risk management requirements, requiring firms to implement access controls based on the need-to-know and least-privilege principles, maintain audit logs of privileged operations, and periodically review access rights. MiCA's governance requirements extend these obligations to crypto-asset service providers. ISO 27001 Annex A.9 covers access control comprehensively and references privileged access specifically. NIST SP 800-53 provides detailed PAM control families applicable to any organisation handling high-value digital assets.
How do we implement PAM in a small crypto team without disrupting operations?
Start with discovery: catalogue all privileged accounts, credentials, and access paths. Then implement quick wins: enforce phishing-resistant MFA on all privileged accounts, remove shared credentials, and eliminate standing access to production environments. From there, introduce a PAM tool (CyberArk, BeyondTrust, or HashiCorp Vault for infrastructure secrets) to centralise credential vaulting and session management. Phase implementation to avoid disruption: begin with the highest-risk accounts (treasury signers, infrastructure admins) before expanding. Pair each technical control with a documented process so that the people dimension of PAM is addressed alongside the technology.