Ask a crypto firm's security engineer whether the organisation has access control, and the answer will almost always be yes, followed by a description of an identity provider, single sign-on configuration, and a set of permission groups in the cloud console. Ask for the written access control policy that defines why those specific groups exist, who is authorised to approve a new privileged grant, and how often access is reviewed, and the answer changes considerably. Many firms have never written this document at all. The technical controls exist because someone configured them at some point, generally under time pressure, and have simply accumulated since without a governing standard behind them.
This is a people and process failure dressed up as a technology function. Access control technology enforces whatever policy you give it, and if you have never written the policy, the technology is enforcing whatever configuration happened to be convenient at the time it was set up, which is a materially different thing. This guide covers how to design, write and enforce an access control policy specifically for a crypto or Web3 operations environment, building on the conceptual grounding in our identity and access management guide but focused here on the practical mechanics of the policy document and the review process behind it.
Access Control Policy Foundations: What the Document Must Cover
An access control policy is not a description of your current technical configuration. It is a standard that your technical configuration is meant to satisfy, and it should be written so that it remains valid even as the underlying tools change.
Scope and applicability
The policy should state explicitly which systems, environments and asset classes it governs: cloud infrastructure, source code repositories, custody and signing systems, internal applications, and any third-party platform holding client or protocol data. A common gap is a policy written with cloud infrastructure in mind that never explicitly addresses custody and signing systems, leaving the highest-risk category of access entirely uncovered by the written standard.
Roles and responsibilities
Name the specific roles responsible for granting access, approving privileged access requests, conducting reviews, and revoking access on departure. Vague ownership, such as "the security team", tends to dissolve into no one being accountable in practice. The policy should name a role, not necessarily an individual, so it survives personnel changes.
Access request and approval workflow
Every access grant should follow a documented request and approval path, with the approver defined by the sensitivity of the system in question rather than a single blanket approval process for everything from a documentation wiki to a production signing key. The policy should specify who can approve what, and explicitly note that no individual can approve their own access request.
Classification of systems by sensitivity
Not every system warrants the same control rigour. The policy should define at least three tiers, for example standard, sensitive, and critical, with critical covering anything touching funds movement, key material or production infrastructure, and specify the control requirements attached to each tier explicitly rather than leaving this to individual judgement.
Role-Based Access Control for Crypto Operations Teams
Role-based access control (RBAC) structures permissions around defined job functions rather than granting access to individuals on an ad hoc basis, and it is the practical foundation most crypto operations teams should build on.
Defining roles around function, not organisational title
Roles should map to what a person actually does operationally, such as "transaction approver" or "infrastructure deployer", rather than to job titles like "senior engineer", which tell you nothing about what access is actually required. A senior engineer working exclusively on a public-facing website has no operational need for signing authority, regardless of seniority.
Core roles in a typical crypto operations team
Common roles include read-only observers who can view dashboards and metrics without any write access, transaction initiators who can propose but not approve transactions, transaction approvers who hold signing or multisig co-signing authority, infrastructure administrators with the ability to modify production systems, and policy administrators with the authority to alter access control settings themselves, a role that should be held by the smallest possible number of people given its self-referential power.
Mapping roles to systems explicitly
For each defined role, document precisely which systems and permission levels it includes. A role definition that says "infrastructure administrator" without specifying which cloud accounts, which environments, and which specific permission sets is not actually enforceable, since it leaves interpretation up to whoever provisions the account.
Avoiding role sprawl
Left unmanaged, RBAC systems tend to accumulate an ever-growing number of custom, one-off roles created to solve individual access requests, until the role structure itself becomes as opaque as unmanaged individual permissions. Periodically consolidate roles and retire ones that exist for a single legacy use case, and require any new role proposal to be justified against the existing set before it is created.
Least Privilege Enforcement: From Principle to Practice
Least privilege is one of the most widely cited and least consistently enforced principles in security. Stating it in a policy document changes nothing on its own. It has to be built into the actual provisioning process.
Default deny as the starting position
New accounts, whether for employees, contractors or service integrations, should start with no access and have specific permissions added based on demonstrated need, rather than starting from a broad template and having access removed later. Removal after the fact rarely happens with any consistency, which is precisely how over-permissioned accounts accumulate.
Time-bound access for temporary needs
Where a contractor, auditor, or employee needs elevated access for a specific, time-limited task, grant that access with an automatic expiry rather than a manual reminder to revoke it later. Automatic expiry removes the dependency on someone remembering to act, which is the single most common reason temporary access becomes permanent.
Just-in-time elevation for privileged actions
Rather than granting standing privileged access, mature access control programmes use just-in-time elevation, where a user requests temporary elevated permissions for a specific task, the request is logged and, where warranted, approved by a second party, and the elevation expires automatically once the task window closes. This significantly reduces the standing attack surface represented by permanently privileged accounts.
Regularly challenging existing grants
Least privilege is not a one-time provisioning decision. Existing access should be periodically challenged with the question of whether the current holder still has an active operational need, not simply whether they had a legitimate reason when the access was first granted months or years earlier.
Most crypto firms have implemented technical access controls in their cloud infrastructure but have never written the policy behind them. This means there is no baseline to audit against, no defined process to enforce periodic review, and no evidence of control to show a regulator or institutional counterparty who asks how access decisions are actually made.
Privileged Account Controls: Admin Keys, Signing Authority and Root Credentials
Privileged accounts represent a disproportionate share of the risk in any access control programme, and crypto operations introduce categories of privileged access, such as signing authority, that traditional IT security frameworks were never built to address directly.
Cloud root and administrative credentials
Root or organisation-level administrative credentials for cloud providers should never be used for routine operations, should be protected by hardware-based multi-factor authentication, and should have their use logged and alerted on independently of standard account activity. Day-to-day administrative work should be performed through scoped roles that fall well short of full root access.
Signing authority and multisig co-signers
Every individual holding signing or multisig co-signing authority represents a direct line to fund movement, and this authority should be governed by the same rigour as any other privileged credential: documented assignment, independent verification of every transaction before signing, and immediate revocation on any change in role or employment status. This connects directly to the broader principle of separation of duties, since no single signer should also control the infrastructure that presents transactions for approval.
HSM administrator access
Hardware security module administrative access, covering key policy changes, quorum configuration and firmware updates, should require multi-party authorisation for any change, with every action logged to a location the HSM administrators themselves cannot alter. Treating this access with the same rigour applied to the keys the HSM protects is essential, since HSM administration is itself a path to compromising those keys.
CI/CD and deployment credentials
Credentials used by automated deployment pipelines to push code or infrastructure changes to production are frequently under-governed relative to their actual power, since a compromised deployment credential can be used to introduce malicious code directly into production systems. These credentials warrant the same scrutiny as a human privileged account: scoped permissions, rotation on a defined schedule, and monitoring for use outside expected pipeline windows.
A dedicated privileged access management layer
Organisations with more than a handful of privileged accounts benefit from a dedicated privileged access management platform that vaults credentials, enforces just-in-time elevation, and provides a single point of audit for every privileged session, rather than relying on each system's native access controls independently.
The Quarterly Access Review Process
A policy that defines roles and privilege levels correctly at the moment of writing will drift out of alignment with reality within months unless a review process actively catches and corrects that drift.
Full access inventory as the starting point
Each review cycle should begin with a complete, exported inventory of every user, service account and role assignment across every system in scope, not a review limited to whichever systems come to mind. Automating this export, rather than compiling it manually each quarter, materially improves both accuracy and the consistency of the review over time.
Manager and system owner attestation
For each access grant, the relevant manager or system owner should explicitly attest that the access remains necessary, rather than the review defaulting to "no objection raised" as implicit approval. Silence should never be treated as confirmation in a review process this consequential.
Differentiated review frequency by risk tier
Standard access can reasonably be reviewed quarterly, but privileged and signing-related access, given its direct financial consequence, warrants a monthly cadence at minimum. The review frequency should be tied explicitly to the system sensitivity tiers defined earlier in the policy.
Closing the loop on findings
Every review that identifies stale, excessive or unexplained access needs a tracked remediation action with an owner and a deadline, not simply a note in a spreadsheet. A review process that identifies problems but has no mechanism to enforce their resolution provides limited practical value beyond satisfying an audit checkbox.
Access Control in Onboarding and Offboarding
Access control policy is tested most directly at the two moments when a person's relationship with the organisation changes: joining and leaving.
Role-based provisioning at onboarding
New joiners should be provisioned according to the pre-defined role their position maps to, not according to an ad hoc replication of a colleague's existing access, which tends to propagate historical over-permissioning to every new hire indefinitely. Confirm that any access requiring vetting or security clearance, particularly for roles touching sensitive systems, is validated as part of the broader employee security vetting process before provisioning occurs, not after.
Immediate revocation on departure
Access revocation on departure needs to be immediate and comprehensive, covering every system, credential and key ceremony the individual touched, not limited to the primary email and single sign-on account. This is where employee offboarding security and access control policy intersect directly, and firms should maintain a documented checklist covering every system category so that revocation does not rely on memory.
Special handling for privileged and signing roles
A departing employee who held signing authority or multisig co-signer status requires a specific, higher-priority offboarding path, including reconfiguration of the relevant multisig or quorum structure, not merely disabling their account login. An account can be disabled while a cryptographic key share the individual retains offline remains entirely usable, so offboarding for these roles must address the key material itself.
Role changes as a trigger for review
Internal role changes, promotions and team transfers should trigger an access review with the same rigour as offboarding, since access accumulated in a previous role frequently persists unnoticed after an internal move, creating exactly the kind of unexplained, undocumented privilege that a quarterly review is designed to catch.
Policy Documentation Standards for Regulatory Compliance
A verbal understanding of access control, however well followed in practice, provides no evidence to a regulator, auditor or institutional counterparty conducting due diligence. Documentation standards matter as much as the underlying practice.
Version control and change history
The policy document itself should be version controlled, with a dated change history showing what was amended and why. Auditors specifically look for evidence that a policy is a living document reviewed and updated over time, rather than a static file created once to satisfy an initial compliance requirement and never revisited.
Evidence of enforcement, not just intent
Alongside the policy document itself, maintain evidence that it is actually being enforced: access review records, approval logs, and revocation timestamps tied to offboarding events. A policy with no supporting evidence trail invites the reasonable question of whether it reflects genuine practice or exists purely as a paper exercise.
Alignment with regulatory frameworks
For firms operating under DORA or MiCA, the access control policy should explicitly reference the governance and ICT risk management provisions those frameworks require, making the connection between the internal document and the external regulatory obligation clear and auditable rather than something a reviewer has to infer.
Accessible ownership and review cadence stated in the document
State plainly, within the policy itself, who owns the document, how often it is formally reviewed, and when it was last updated. This small piece of self-referential documentation is frequently what an auditor checks first, since it signals whether the organisation treats its own policy as a genuinely maintained control or as an artefact produced once and forgotten.
Frequently Asked Questions
What is the difference between an access control policy and an IAM system?
An IAM system is the technical infrastructure that enforces access, such as your identity provider, single sign-on, and permission groups. An access control policy is the written document that defines what those technical controls should actually enforce: which roles exist, what each role can access, how privileged accounts are governed, and how access is reviewed and revoked. Firms frequently have the technology without the policy, which leaves them unable to demonstrate that access was granted according to any defined standard.
How often should a crypto firm review user access permissions?
A full access review should be conducted at least quarterly, covering every user, service account and role assignment across critical systems. Privileged and signing-related access, including any role with transaction approval authority, warrants a more frequent review cycle, typically monthly, given the direct financial consequence of an unauthorised or stale privileged grant.
What counts as a privileged account in a Web3 organisation?
Any account or key holder with the authority to move funds, sign transactions, deploy or upgrade smart contracts, modify infrastructure configuration, or grant access to others. This includes cloud root credentials, HSM administrator accounts, multisig signing keys, CI/CD deployment credentials, and any account with the ability to alter access control settings themselves.
Why do regulators care about access control policy documentation specifically?
Regulators and auditors need to verify that access controls exist as a matter of design, not merely as an accidental byproduct of how a cloud console happens to be configured today. A written policy provides the baseline against which actual access can be audited, demonstrates that reviews are a required and repeated process rather than a one-off exercise, and gives supervisors documented evidence of governance over one of the highest-risk areas in crypto operations.
How does access control policy connect to employee offboarding?
Offboarding is where access control policy is tested most directly, since a departing employee retaining any live credential, key share, or system permission represents an immediate and avoidable risk. A well-designed policy specifies exact revocation timelines and a checklist covering every system, service and key ceremony a departing employee touched, removing reliance on memory or informal handover notes.