Identity and Access Management for Crypto and Web3 Organisations

Every crypto incident that is attributed to "access control failure" is, at its root, an identity and access management failure. Shared credentials that should never have existed. A contractor whose access was never revoked after engagement ended. A service account with root-level permissions because no one took the time to scope it correctly. An API key committed to a public repository months ago, still valid, still active. These are not exotic attack vectors. They are the mundane, preventable failures that appear repeatedly in post-mortems across the sector.

Identity and access management (IAM) is the operational backbone of access control for any organisation that handles digital assets, manages infrastructure, or operates in regulated markets. It governs a deceptively simple question: who can access what, and under what conditions? Getting this right in a crypto or Web3 firm is considerably more complex than in a traditional enterprise, for reasons this guide will examine in detail. Getting it wrong creates the conditions for the kind of loss events that have repeatedly demonstrated the sector's operational immaturity.

What Is Identity and Access Management

Identity and access management is the discipline and set of technologies that ensure the right individuals and systems can access the right resources at the right times, and for the right reasons, while keeping all other access blocked. It encompasses the full lifecycle of an identity, from provisioning to deprovisioning, and the policies and controls that govern what that identity can do throughout its existence.

IAM vs PAM: An Important Distinction

IAM and Privileged Access Management (PAM) are related but distinct disciplines. IAM covers all identities in an organisation: standard employees, contractors, service accounts, API integrations, and automated processes. PAM is a specialist subset of IAM that focuses specifically on privileged accounts, those with elevated or administrative access to critical systems, infrastructure, or key material. A developer's standard workstation login is an IAM concern. The infrastructure administrator's root access to the cloud environment, or the key custodian's access to the hardware security module, is a PAM concern. Crypto firms need both, but confusing them often leads to organisations investing heavily in PAM while leaving standard IAM controls in a poor state, or vice versa. Our dedicated guide on privileged access management for crypto firms covers PAM in depth; this post focuses on the broader IAM framework.

The Four Pillars of IAM

A well-structured IAM framework rests on four foundational pillars, each of which must be addressed for the overall programme to be effective.

Identification is the process of asserting who you are. In an enterprise context, this is typically a username, email address, or employee identifier. Every individual and system that interacts with organisational resources needs a distinct, managed identity. Shared identities, where multiple people use the same account, make accountability impossible and are one of the most common IAM failures seen in smaller crypto firms.

Authentication is the process of proving that you are who you claim to be. Passwords alone represent a minimal bar that has been demonstrably inadequate for years. Strong authentication in modern IAM frameworks means multi-factor authentication (MFA) as a baseline, with hardware-backed FIDO2 keys for high-risk systems and privileged access. The strength of authentication controls is one of the most direct indicators of an organisation's access control maturity.

Authorisation is the process of determining what an authenticated identity is permitted to do. This is where the principle of least privilege is operationalised: each identity should have access to precisely the resources it requires to perform its defined function, and no more. In practice, this requires a defined role structure, regular access reviews, and a process for managing exceptions.

Accountability is the ability to reconstruct what any identity did, when, and to what resource. This requires comprehensive audit logging of access events, authentication attempts, and access changes, combined with the ability to query and analyse those logs in a timely manner. Without accountability, detecting compromise, investigating incidents, and demonstrating compliance are all severely impaired.

The IAM Challenge in Web3

Implementing robust IAM in a Web3 firm is more complex than in a conventional enterprise, and the gap between the two is often underestimated until an incident forces the issue.

Pseudonymous Culture vs Enterprise Security Requirements

Much of the Web3 ecosystem evolved from an open-source, pseudonymous culture where conventional corporate identity frameworks were not just absent but philosophically resisted. Contributors worked under pseudonyms, repositories were public, and the concept of a managed corporate identity directory was alien to many founding teams. As firms scale, seek regulatory authorisation, and handle significant funds, this cultural legacy creates friction with the IAM controls that the organisation genuinely needs. Bridging this gap requires leadership commitment and a clear articulation of why these controls exist, not just a mandate to comply.

Contractor-Heavy Teams

Web3 firms frequently operate with a core permanent team supplemented by a large and fluid contractor workforce: auditors, developers, community managers, integrators, and marketing specialists, often working across multiple jurisdictions. Each contractor represents an identity that must be provisioned with appropriate access, monitored, and deprovisioned promptly when the engagement ends. In firms without a mature IAM process, contractor accounts accumulate silently, creating a growing population of stale identities that represent persistent access risks.

DevOps and CI/CD Service Accounts

Modern software delivery pipelines generate a significant number of non-human identities: service accounts, deployment tokens, pipeline credentials, and API keys. In fast-moving development environments, these are often created informally to solve immediate problems and never formally governed. The result is a growing inventory of machine identities, many overprivileged, with credentials that have never been rotated and access that has never been reviewed.

Multi-Chain Infrastructure

Operating across multiple blockchain networks means managing access to multiple sets of infrastructure, each potentially with its own access model, key management requirements, and tooling. Without a unified IAM approach that abstracts across these environments, organisations end up with a fragmented patchwork of access controls that is impossible to audit comprehensively and easy to misconfigure.

Remote-First Teams

Virtually all Web3 firms operate with distributed, remote-first teams. This eliminates the implicit physical access controls that office-based working provides and means that network perimeter-based access controls offer limited value. Identity becomes the primary perimeter, making robust IAM not just important but structurally essential to the organisation's security architecture.

Core IAM Components for Crypto Firms

A mature IAM programme for a crypto firm requires a set of core technical and process components. Each of these represents a layer of control that, taken together, creates a defensible access management posture.

Directory Services

A centralised identity directory is the foundation of any IAM programme. Whether implemented via a cloud identity provider (such as Okta, Azure Active Directory, or Google Workspace) or an on-premises directory service, this is the authoritative source of truth for all identities in the organisation. Every user account, service account, and contractor identity should be managed through this directory, enabling centralised provisioning, lifecycle management, and deprovisioning.

Single Sign-On (SSO)

SSO allows users to authenticate once, with strong credentials, and access all authorised applications without re-authenticating individually. For security purposes, SSO is valuable because it concentrates authentication through a single, strongly governed gateway, making it practical to enforce MFA universally and to revoke access across all connected applications simultaneously when an employee leaves or an account is compromised. For user experience, it eliminates the password fatigue that drives insecure workarounds like password reuse and credential sharing.

Multi-Factor Authentication and FIDO2

MFA is the single most impactful access control that most crypto firms can implement. The choice of second factor matters significantly. SMS-based OTP is the weakest form of MFA and is vulnerable to SIM swapping, a documented attack vector specifically targeting crypto professionals. Authenticator app-based TOTP is substantially stronger. FIDO2 hardware security keys represent the strongest available option: authentication is cryptographically bound to the legitimate origin of the login request, rendering it immune to phishing and SIM swapping. For high-risk roles and privileged access, FIDO2 should be considered the minimum standard.

Role-Based Access Control and Least Privilege

Role-based access control (RBAC) structures access around defined roles rather than individual permissions, making access management scalable and auditable. Each role should be defined with the minimum permissions required to perform its associated function. Departures from this principle, where individuals are granted access beyond their role definition for convenience or expediency, should require formal exception processes and periodic review. Regular access certification reviews, where managers attest to the continued necessity of each team member's access, are the process mechanism that keeps RBAC from drifting over time.

Service Account Governance

Service accounts require a governance framework that mirrors the framework applied to human identities. Each service account should have a defined owner, a documented purpose, scoped permissions, and a rotation schedule for its credentials. Service accounts that are no longer required should be deprovisioned. Service accounts with excessive permissions should be scoped down. Service account credentials should never be embedded in code, configuration files, or environment variables accessible to multiple people; they should be stored in a dedicated secrets management system.

API Key Management

API keys are non-human identities that carry significant risk in the crypto context. Keys with broad permissions represent high-value targets for attackers. A disciplined API key management approach requires: unique keys per service or integration, minimum-necessary permission scoping, defined expiry periods with enforced rotation, storage in a secrets vault, audit logging of key usage, and immediate revocation capability. Automated scanning of code repositories and CI/CD pipelines for accidentally committed secrets should be a standard control.

Contractor and Vendor IAM

All contractor and vendor identities should be provisioned through the same directory and subject to the same IAM controls as internal employees, with one important addition: time-limited access that automatically expires at the end of the engagement. Waiting for a manager to request deprovisioning creates a systematic risk of stale accounts. Automated expiry, combined with a formal renewal process for extended engagements, is a more reliable control.

"In Web3, identity is the perimeter. Every stale contractor account, every overprivileged service account, and every shared credential is an open door waiting to be found by the adversary that is actively looking for it."

IAM for Blockchain Infrastructure

IAM principles apply to blockchain-native infrastructure, though implementation differs from conventional IT systems. This is an area that many crypto firms handle poorly, treating blockchain infrastructure access as categorically different from enterprise access management when the underlying risk principles are identical.

Node Operator Access

Access to blockchain node infrastructure, whether validator nodes, archive nodes, or full nodes supporting application infrastructure, should be governed through the same IAM framework as any other server infrastructure. This means individual accounts with strong authentication, least-privilege access rights, full audit logging, and a defined process for access reviews. Shared SSH keys are a common and serious failure mode in this area.

Validator Key Access

Validator keys represent some of the highest-value secrets in a Proof-of-Stake blockchain operation. Access to these keys should be subject to hardware-level protection, multi-party authorisation for key usage, full audit logging of every key operation, and strict physical and logical access controls. The number of individuals with any form of access to validator key material should be minimised, documented, and regularly reviewed. This connects directly to PAM controls, but the identity governance layer, determining who is authorised to have this access at all, is an IAM function.

RPC Endpoint Authentication

Remote Procedure Call (RPC) endpoints that provide access to blockchain node functionality are frequently left with insufficient authentication controls, relying on IP allowlisting alone or, in worse cases, left entirely open. Every RPC endpoint used for privileged or operational purposes should require authenticated access with logged requests. API key management principles apply here in full.

Smart Contract Deployer Account Governance

Accounts with the authority to deploy or upgrade smart contracts represent some of the highest-risk identities in a DeFi or Web3 protocol firm. The governance framework for these accounts must address: who is authorised to hold deployer keys, what approval process is required before deployment, how deployment actions are logged and reviewed, and how deployer keys are secured when not in active use. Multisig controls at the contract level are valuable, but IAM governance of the individual signer identities is a separate and equally necessary layer.

Multisig Signer Identity Management

Multisig wallets are a widely used security control for treasury and protocol management. However, the security of a multisig arrangement depends entirely on the security of the individual signer identities. If a signer's private key is compromised, or if a signer's corporate device is taken over through a social engineering attack, the multisig structure provides limited protection. IAM governance of signer identities should include: identity verification and vetting of all signers, strong authentication requirements for signing workstations, documented procedures for signer changes, and regular review of the signer set to ensure it reflects current and trusted personnel.

Privileged Identity Management vs PAM

Privileged Identity Management (PIM) and Privileged Access Management are closely related concepts that are sometimes used interchangeably but have a meaningful distinction in enterprise IAM architecture.

PIM focuses on the governance of privileged identities themselves: who holds privileged accounts, how those accounts are provisioned and managed, and how just-in-time access elevation works for users who require temporary privileged access. PAM encompasses PIM but also includes the broader set of controls around privileged access: session recording, credential vaulting, workflow-based access approval, and real-time monitoring of privileged sessions.

For crypto firms, both concepts are relevant. The IAM programme should govern which individuals are eligible for privileged access, under what conditions it can be granted, and how the lifecycle of privileged identities is managed. The PAM programme, covered in our dedicated post on privileged access management for crypto firms, then provides the technical controls that protect and audit the exercise of that privilege.

A common failure in smaller organisations is to focus on PAM tooling for a subset of privileged accounts while leaving the broader IAM framework underdeveloped. This creates a situation where the crown jewels are in a vault, but the rest of the building has no locks. Both layers are required.

IAM and Zero Trust

Zero trust is an architectural philosophy rather than a product or technology: the principle that no identity, whether inside or outside the traditional network perimeter, should be trusted by default. Every access request must be authenticated, authorised, and continuously evaluated, regardless of where it originates.

IAM is the foundational operational layer that makes zero trust achievable. Without robust identity verification, contextual authentication, and granular authorisation, zero trust remains an aspiration rather than a reality. The practical implementation of zero trust in a crypto firm requires: a centralised identity directory covering all identities; universal MFA for all access; policy-based authorisation that evaluates device health, location, and behavioural signals alongside identity; microsegmentation that limits lateral movement once access is granted; and continuous monitoring of access patterns to detect anomalies.

Identity becomes the new perimeter in a zero-trust architecture. This is especially relevant for remote-first crypto firms, where there is no meaningful network perimeter to speak of and where access comes from an enormous variety of devices and locations. For a comprehensive treatment of zero-trust architecture in the Web3 context, see our guide on zero-trust security for Web3 organisations.

Common IAM Failures in Crypto Hacks

Post-incident analysis across the crypto sector reveals a recurring set of IAM failures that appear as root or contributing causes in the majority of significant access-related breaches. Understanding these failure modes is the first step in ensuring your organisation does not replicate them.

Shared Credentials

Shared credentials remain common in crypto firms, particularly for operational tooling, exchange API access, and node infrastructure. When multiple individuals share a single set of credentials, accountability is impossible. If an incident occurs, investigators cannot determine which individual's actions led to the breach. More critically, shared credentials mean that a single social engineering success or phishing compromise potentially exposes access that was intended to be held by multiple people under separate controls.

Stale Accounts

Accounts belonging to former employees, contractors whose engagements ended, and service integrations that are no longer active represent persistent access risk. These accounts are rarely monitored, often forgotten by the teams responsible for access management, and represent an attractive target for an attacker who has obtained the associated credentials through a breach of an external system where the same password was reused. Regular access reviews and automated deprovisioning workflows are the primary controls against stale account accumulation.

Overprivileged Service Accounts

Service accounts created with broad permissions for convenience represent a systemic risk. An attacker who compromises a service account with administrative-level access to cloud infrastructure, key management systems, or deployment pipelines can cause significantly greater damage than one who obtains a standard user credential. Every service account in the inventory should have its permission set reviewed against its actual operational requirements, with excess permissions revoked.

API Key Leaks in Public Repositories

API key exposure through public code repositories is one of the most preventable and most frequently occurring security failures in the software industry, and the crypto sector is not immune. Developers commit keys accidentally, configuration files with embedded secrets get added to repositories, and environment variable files intended to be excluded from version control end up included. Automated secret scanning tools integrated into CI/CD pipelines and repository checks can detect and alert on this class of exposure before it becomes an incident. For a broader view of operational risk controls, see our guide on operational risk management for crypto firms.

Missing Access Reviews

Even organisations that provision access correctly at the point of onboarding frequently fail to review access over time. Employees change roles, responsibilities evolve, and projects end, but access rights acquired in previous roles persist. Without periodic access certification reviews, the cumulative drift between current access rights and current role requirements creates an ever-expanding pool of unnecessary access that an attacker can exploit.

Implementing IAM: A Phased Approach

Implementing a mature IAM programme in an organisation that lacks one is a multi-phase initiative. Attempting to deploy all controls simultaneously is rarely feasible and often counterproductive. The following phased approach allows organisations to make meaningful, measurable progress while managing operational disruption.

Phase 1: Identity Inventory

The first phase involves building a comprehensive inventory of all identities in the organisation. This covers human identities (employees, contractors, and service providers) and non-human identities (service accounts, API keys, deployment credentials, and integration tokens). For many organisations, this inventory exercise will surface a significant number of unmanaged or unknown identities. The output of this phase is a registry that becomes the baseline for all subsequent IAM work. Connecting this to the Security Operations Centre function creates visibility for monitoring; see our guide on the security operations centre for crypto firms for how these functions integrate.

Phase 2: Directory Consolidation

If identities are currently managed across multiple disconnected systems, they should be consolidated into a single identity provider. This creates the centralised governance layer that makes all subsequent controls scalable. SSO integration for all major applications should be completed during this phase, channelling all authentication through the central identity provider and enabling universal policy enforcement.

Phase 3: MFA Enforcement

Universal MFA should be enforced for all identities accessing organisational systems. Roll out in priority order: privileged accounts and access to high-risk systems first, then all remote access, then all internal systems. Mandate FIDO2 hardware keys for privileged and high-risk access. Communicate clearly with the workforce about the reasons for MFA requirements and provide practical support for the transition.

Phase 4: RBAC Rollout

Define the role structure for the organisation, mapping each role to the access rights required to perform its associated functions. Apply roles to all existing identities and conduct an immediate access review to identify and remediate excess access. Establish the exception management process for cases where standard role access is insufficient. Build access certification reviews into the operational calendar on a quarterly basis.

Phase 5: Continuous Monitoring

The final phase operationalises ongoing access management. This includes automated deprovisioning workflows triggered by HR events, continuous monitoring of access patterns to detect anomalies, automated scanning for secret and credential exposure, regular penetration testing of IAM controls, and metrics reporting to leadership on access control health indicators such as MFA coverage, stale account rates, and access review completion.

Regulatory Requirements

IAM is not simply a security best practice for crypto firms operating in regulated markets. It is an explicit regulatory requirement under several applicable frameworks.

DORA Article 9

DORA requires financial entities, including those providing crypto-asset services, to implement access control policies covering identification, authentication, and authorisation for all ICT systems and users. Article 9 specifically requires the use of strong authentication mechanisms for privileged access and for access to sensitive systems and data. This translates directly into requirements for MFA enforcement, privileged access management, and documented access control policies with regular review. Our guide on DORA compliance for crypto and financial firms covers the full set of Article 9 obligations.

MiCA Operational Resilience

MiCA's operational resilience requirements for crypto-asset service providers encompass access control as a component of the ICT risk management framework that authorised CASPs must maintain. The European Banking Authority's technical standards provide additional detail on the expected access management controls, including requirements for authentication strength, access reviews, and the management of privileged access. Our guide on MiCA compliance for crypto firms addresses these requirements in full.

ISO 27001 Annex A.5.15 to A.5.18

ISO 27001:2022 Annex A contains four controls directly addressing identity and access management. A.5.15 (Access control) requires a documented access control policy based on business and information security requirements. A.5.16 (Identity management) requires the full lifecycle management of identities. A.5.17 (Authentication information) governs the management and protection of authentication credentials. A.5.18 (Access rights) requires formal processes for granting, reviewing, and revoking access rights. Together, these four controls represent a comprehensive IAM framework requirement that maps directly to the components described in this guide. For a full treatment of ISO 27001 implementation for crypto firms, see our dedicated guide on ISO 27001 certification for crypto organisations.

Frequently Asked Questions