Summary: This piece explains zero trust identity and access management for web3 protocols, with a focus on IAM design, SSO, onchain roles, and how Spearbit approaches identity audits.
Modern crypto infrastructure spans cloud accounts, CI systems, key management services, and onchain admin roles. Most breaches still involve identity and access abuse in some form: misused credentials, overprivileged service accounts, or admin keys that are easier to reach than expected. For a protocol that wants institutional adoption, zero trust identity and access management is a core security layer, not a convenience.
Why zero trust IAM fits web3 infrastructure
Traditional perimeter models assume that once a request comes from the right network segment it can be trusted. That assumption breaks quickly when staff work remotely, infrastructure is hosted across multiple providers, and protocol control sits in wallets and contracts rather than a single internal system.
Zero trust identity and access management starts from different assumptions:
- Every request is authenticated and authorised, regardless of network location
- Access is granted with least privilege and for a limited duration
- Compromise is assumed, so controls are designed so that no single account or device can change the system in unrestricted ways
- Every decision is logged and can be reconstructed later
In a web3 setting, that applies just as much to smart contract owners, multisignature signers, and deployer keys as it does to cloud admins and CI users.
Where identity and access commonly fail
A zero trust design has to address specific failure patterns.
Long lived access everywhere
Admin accounts in cloud consoles, CI tools, or vendor dashboards often have broad rights that never expire. Legacy keys and tokens stay valid for years. Onchain, a lone externally owned address may retain upgrade or pause privileges long after the original operator has left.
Fragmented identity stores
Identity lives in multiple places: the corporate directory, individual cloud accounts, Git hosting, CI users, secrets managers, and onchain wallets. There is rarely a single view of which human can influence which part of the system.
Weak authentication
Password only access remains common in older systems and smaller internal tools. MFA is inconsistent. High value functions, including protocol parameter changes and treasury transactions, are still authorised by seed phrases stored in browser extensions.
Orphaned machine identities
Service accounts and API keys are created to “get something working” and never revisited. These machine identities often have high privileges and are not subject to the same reviews as human users.
Onchain roles that do not match offchain reality
Upgrade roles, pause roles, and protocol treasury control may sit in wallets that are not clearly tied to accountable owners in the organisation. Incident response becomes hard because no one is completely sure who can do what.
Designing zero trust IAM for web3 protocols
Strong authentication and device posture
For infrastructure and protocol operators:
- Use hardware security keys for administrators, CI operators, and anyone managing keys or production systems
- Prefer passkeys where possible and restrict SMS based second factors
- Phase out password only access to consoles, dashboards, and critical tools
For onchain control:
- Require hardware wallet or secure enclave based signing for any address that can upgrade contracts, change parameters, or move funds
- Keep signing devices dedicated to that purpose, not shared with general browsing
Least privilege mapped to actual workflows
Start by mapping out workflows that touch sensitive systems:
- Deploying a new version of the protocol
- Changing risk parameters
- Upgrading or pausing contracts
- Moving funds from treasuries or reserves
For each workflow, capture which steps must be performed and by whom. Then:
- Create IAM roles in cloud and CI that map to those steps, with narrow permissions and no extras
- Reflect these roles onchain by separating admin functions into distinct roles for upgrades, parameters, and treasury
- Remove broad “admin everywhere” roles and legacy accounts that no longer map to any current responsibility
Automated lifecycle and recertification
Manual account management falls behind quickly.
- Integrate joiner and leaver flows with the identity provider so that cloud accounts, SaaS tools, and VPN access are created and removed automatically
- Attach onchain role changes to explicit governance or operational processes, not to ad hoc key handoffs
- Run regular access reviews where managers attest to their team’s access and onchain role ownership is reverified
Unifying web2 and web3 identity
You should be able to answer, for any privileged onchain address, which person or group is responsible for it.
- Maintain a registry that maps staff identities to protocol admin addresses, multisignature participants, and MPC key shares
- For smart contract wallets, use EIP 1271 or similar mechanisms to bind organisational identity to wallet operations and key rotation
- Log changes to roles and signers in both onchain events and internal audit systems
Web3 specific identity patterns
Identity issues show up differently in web3 environments.
- Smart contract access control must be explicit. Functions that change core parameters or move funds should use role based checks, not an undifferentiated owner address.
- Multisignature design should account for independence of signers. Devices, networks, and organisations involved in a threshold should be as disjoint as possible.
- Guardians, recovery mechanisms, and session keys in smart wallets must be treated as privileged identities, not as convenience features.
Applying zero trust principles means:
- Treating contract calls that change state as access events, with the same scrutiny as admin actions in a cloud console
- Designing recovery and emergency mechanisms so that no single compromised address can override all other controls
- Using onchain and offchain logs to link identity, intent, and effect
Action plan for zero trust IAM in web3
- Build a combined inventory of identities across cloud accounts, CI, SaaS, and onchain roles and wallets.
- Deploy hardware backed MFA for administrators, signers, and anyone with production or key management access.
- Redesign access around specific workflows and least privilege, both offchain and onchain. Remove legacy broad access.
- Automate provisioning and deprovisioning and schedule periodic access reviews.
- Align onchain governance roles and protocol admin keys with organisational responsibilities and document that mapping.
How Spearbit reviews identity and access management
In identity and access focused audits, Spearbit:
- Traces how code moves from development to deployment and who can influence each step
- Maps which identities can change contract logic, parameters, and treasury balances
- Reviews cloud IAM, CI roles, multisignature and MPC policies, and guardian or recovery setups for abuse paths
- Highlights places where least privilege, separation of duties, and zero trust checks are missing or misaligned
If your protocol or infrastructure stack is complex, a structured IAM audit helps remove guesswork about who actually has control. Contact us to get started,