Executive Summary: The traditional model of network security assumes that anything inside the perimeter is trustworthy. That assumption was questionable in 2010. In the context of a remote-first Web3 organisation operating distributed infrastructure across cloud providers, decentralised nodes, and third-party RPC services, it is simply not a coherent concept. Zero trust security provides the alternative: a model in which no user, device, or network connection is implicitly trusted, every access request is continuously verified, and access is granted on the basis of confirmed identity and policy rather than network location. This post explains the zero trust model, why it maps directly onto the structural realities of Web3 organisations, how to apply it to the specific infrastructure and threat environment that crypto firms face, and how to implement it practically without requiring an enterprise security budget.
What Is Zero Trust Security
Zero trust is a security model, not a product. The term was coined by analyst John Kindervag at Forrester Research in 2010, and subsequently adopted and formalised by NIST in Special Publication 800-207 (published 2020). The core principle is "never trust, always verify": the model rejects the concept of implicit trust based on network location and replaces it with continuous, explicit verification of identity, device health, and context for every access request.
In a traditional perimeter-based security model, the network is divided into an inside (trusted) and an outside (untrusted), typically enforced by a firewall. Users and systems inside the perimeter are treated as trustworthy by default: once inside, lateral movement is relatively unconstrained. This model was designed for an era in which users sat at corporate workstations on a managed LAN, accessed applications hosted on on-premises servers, and the threat of a compromised insider or a perimeter breach was considered a manageable edge case.
Zero trust rejects every assumption in that design. There is no inside. There is no trusted zone. Every access request, whether it originates from a user at home, a developer on a coffee shop WiFi connection, an automated service account in the cloud, or a compromised internal system, is evaluated against the same set of identity and policy criteria before access is granted. The five core principles of zero trust, as defined by NIST, are:
- Verify explicitly: Authenticate and authorise every access request using all available data points, including identity, location, device health, service or workload, data classification, and anomalies.
- Use least privilege access: Limit user access with just-in-time and just-enough-access principles, risk-based adaptive policies, and data protection.
- Assume breach: Minimise blast radius and segment access. Verify end-to-end encryption. Use analytics to get visibility and drive threat detection and response improvement.
- Continuous verification: Do not rely on a one-time authentication event at session start. Monitor continuously throughout the session for signs of compromise or anomalous behaviour.
- Micro-segmentation: Divide the network into small, isolated segments so that compromise of one segment does not grant access to others.
These principles are not merely theoretical. They have been operationalised by organisations including Google (BeyondCorp), which transitioned its entire global workforce to a zero trust model following the 2009 Operation Aurora attack, and by defence agencies including the US Department of Defense, which mandated zero trust architecture adoption across all DoD systems from 2022. The model works, and its applicability extends directly to the structural realities of Web3 organisations.
Why the Crypto Industry Needs Zero Trust
The crypto industry has arrived at zero trust not by design but by structural necessity, and then failed to recognise the security implications. Web3 teams are remote-first by default: developers in Berlin, infrastructure engineers in Singapore, founders in New York, and community managers in Buenos Aires, all accessing the same production systems from personal devices on home and public networks. There is no corporate office to anchor a perimeter. There is no managed network to enforce baseline security controls across.
The perimeter model is not just less effective in this environment. It is structurally inapplicable. There is no inside. The network is the internet. The devices are personal. The applications are distributed across multiple cloud providers, decentralised node networks, and third-party infrastructure. Attempting to defend this environment with a VPN and a firewall is the equivalent of installing a high-security front door on a building that has no walls.
Meanwhile, the threat actors targeting this environment are operating at a level of sophistication that assumes and exploits perimeter-based thinking. Lazarus Group's operational playbook, as detailed in the Lazarus Group OpSec analysis, is built around the observation that if you can compromise one individual inside a crypto team, you typically gain access to far more than that individual's own systems. Developer environments connect to code repositories, deployment pipelines, signing infrastructure, and internal communication channels. A single compromised laptop is frequently a path to the entire organisation's privileged systems. This is the consequence of operating in an implicit-trust environment: lateral movement is easy because there is nothing to stop it.
Zero trust breaks this attack path at every stage. An attacker who compromises a developer's workstation does not automatically inherit the developer's access to production infrastructure, because that access is continuously re-verified against identity and device posture criteria that the attacker cannot satisfy. The compromised laptop fails the device health check. The authentication request from an unusual location triggers an anomaly alert. The lateral movement attempt against a micro-segmented network segment is blocked because the developer's role does not include access to that segment. The assumed breach is detected and contained before it reaches the treasury keys.
"In Web3, there is no perimeter to defend. The question is not whether you can keep attackers out of your network. The question is whether you can ensure that getting into your network gives them nothing."
Zero Trust for Web3 Infrastructure
Web3 infrastructure has a security surface that traditional zero trust implementations were not designed for. Applying zero trust to this environment requires adapting the standard framework to the specific components that define Web3 operations.
RPC Endpoint Access Control
Remote Procedure Call (RPC) endpoints are the interface through which applications communicate with blockchain nodes. Uncontrolled RPC access is a significant vulnerability: an attacker who can access or manipulate the RPC endpoint a protocol uses can intercept or modify transaction data before it reaches the blockchain. Zero trust principles applied to RPC access require authentication of all clients requesting access to RPC endpoints, enforcement of rate limits and access policies based on client identity, monitoring of all RPC requests for anomalous patterns, and preference for private or authenticated RPC providers over public endpoints for any operation involving signing or key material.
Node Access and Infrastructure Administration
Access to blockchain nodes, whether validator nodes, archive nodes, or execution clients, should be governed by zero trust principles. This means no standing SSH access to production nodes, all administrative access mediated through an identity-aware access proxy with session recording, device posture verification before access is granted, and automated alerting on any access outside a defined baseline of normal administrative activity. The assumption is that any network from which an admin connects may be compromised: the security controls must therefore operate at the identity layer rather than the network layer.
Validator Key Management
Validator keys represent one of the highest-value privileged assets in a proof-of-stake environment. Compromise of validator signing keys enables slashing attacks and potentially the theft of staked assets. Compromise of withdrawal keys enables direct theft of validator rewards and principal. Zero trust applied to validator key management means strict identity-verified access controls for any system that interacts with key material, hardware security module protection for key storage, continuous monitoring of signing activity for anomalous patterns (signing at unusual times, unusual volumes, or with unusual parameters), and micro-segmentation that isolates validator infrastructure from other network segments with no implicit trust between them.
Bridge and Oracle Administration
Cross-chain bridges and oracle networks represent some of the highest-value attack surfaces in DeFi: the cumulative losses from bridge exploits across 2021-2024 exceeded $2 billion. Bridge admin keys and oracle update authority are privileged accounts with direct impact on large volumes of locked assets. Zero trust controls for bridge and oracle administration require the same level of rigour as treasury signing: phishing-resistant MFA on all admin accounts, JIT access for administrative operations, out-of-band verification for parameter changes above defined thresholds, and comprehensive audit logging of all admin actions. The blockchain security audit framework for any bridge or oracle protocol must include assessment of the administrative access controls alongside the smart contract code.
Smart Contract Deployment and Upgrade Authority
Smart contract deployer wallets and upgrade proxy admin keys grant the ability to modify the code that governs protocol behaviour. These are, in the zero trust model, extremely privileged identities that require the strongest available verification controls. Zero trust for deployment operations means: deployer wallets are hardware-key-protected and never exposed on internet-connected systems, deployment operations require multi-party approval above defined risk thresholds, all deployment activity is logged and monitored, and deployments outside business hours or from unusual environments trigger immediate review. Smart contracts are one layer of a protocol's security posture: as covered in the smart contract security fundamentals, the code that governs the contract is not the only thing that needs to be secured: the keys that can change that code require equivalent protection.
Identity as the Perimeter
In a zero trust architecture, identity replaces the network as the primary security boundary. This shift has profound implications for how Web3 security programmes are designed and operated.
Identity, in the zero trust model, means verified, continuously authenticated proof of who is making an access request. This encompasses human identity (the team member or external user requesting access) and machine identity (the service account, automated process, or device requesting access). For human identity, the baseline requirements are: a centralised identity provider (Google Workspace, Okta, or Azure AD) as the authoritative source of identity, phishing-resistant multi-factor authentication (hardware security keys such as YubiKey, or passkey implementations) as the authentication mechanism, and single sign-on (SSO) integration across all applications and infrastructure so that access can be revoked centrally and instantly.
Hardware security keys are non-negotiable in a Web3 context. SMS-based MFA is defeated by SIM-swapping, a common attack against crypto industry targets. Authenticator app TOTP codes are defeated by real-time phishing sites that relay the code to the attacker before it expires. Hardware security keys implement the FIDO2/WebAuthn standard and are inherently phishing-resistant: they cryptographically bind to the specific domain of the legitimate service and cannot be used on a phishing site. For accounts with access to treasury operations, infrastructure, or signing keys, only phishing-resistant MFA is sufficient.
The man-in-the-middle attack surface explored in the MitM attacks in crypto analysis is directly addressed by phishing-resistant MFA: an attacker who intercepts authentication credentials from a SMS or TOTP prompt cannot use those credentials to authenticate via a hardware key, because the key will not respond to a phishing domain. This single control eliminates a significant proportion of account takeover attacks.
For machine identity, zero trust requires that every service account and automated process has a unique, verifiable identity with the minimum access required for its function. Service accounts should not share credentials, should not have standing elevated permissions, and should be subject to the same access review cycle as human accounts. Infrastructure as code deployments should use short-lived credentials issued by an identity provider rather than long-lived static API keys. Any credential that does not expire is a credential that can be stolen and used indefinitely.
Continuous Session Verification
Zero trust does not treat authentication as a one-time event at session start. Once a user has authenticated, their session is continuously monitored for signals that suggest the session may have been compromised: access from a new IP address mid-session, sudden changes in behaviour pattern, access to resources outside the user's normal scope, or access at unusual hours. When anomalous signals are detected, the zero trust policy engine can challenge the user for re-authentication, reduce their access privileges for the remainder of the session, or terminate the session and alert the security team.
In a crypto context, this continuous verification layer is particularly valuable for detecting post-compromise lateral movement. If a developer's session is hijacked after initial authentication, the behaviour of the session will typically diverge from the developer's normal pattern: the attacker will probe systems the developer does not normally access, run commands that the developer does not normally run, or attempt to escalate privileges in ways that the developer has no legitimate reason to perform. These behavioural anomalies are detectable and actionable in a zero trust architecture. In a traditional perimeter model, they are invisible.
Network Segmentation in DeFi
Network segmentation is a foundational zero trust control that limits the blast radius of any successful compromise. Rather than treating the entire internal network as a flat trust zone, micro-segmentation divides the network into isolated segments based on function, data classification, and risk level. Each segment has explicit, policy-enforced controls on what can communicate with what: a compromised system in one segment cannot communicate with systems in other segments without passing through a policy enforcement point.
For a DeFi protocol's infrastructure, micro-segmentation maps directly onto the functional separation that security architecture requires. Production blockchain node infrastructure should be isolated from development and test environments: a compromised development system should have no network path to production signing infrastructure. Bridge administration systems should be isolated from general internal infrastructure: access to bridge admin functions should require a separate, explicitly verified identity and session. Oracle update processes should be isolated from other protocol functions: anomalous behaviour in one component should not create a lateral movement path to others.
At the application layer, micro-segmentation translates into a segmented authorisation model: each application and API endpoint enforces its own access controls based on the requesting identity, rather than relying on network location to determine trustworthiness. A request that originates from inside the organisation's network is not implicitly authorised: it is evaluated against the same identity and policy criteria as any external request.
VPN vs. Zero Trust Network Access
Many crypto firms use VPNs as their primary remote access control. VPNs provide an encrypted tunnel between the user's device and the corporate network, placing the remote user inside the network perimeter. The problem is that once inside the VPN, the user typically has broad access to the internal network with limited granularity of control. A compromised VPN session: whether through credential theft, malware on the connecting device, or a VPN server vulnerability: provides the attacker with broad internal network access.
Zero trust network access (ZTNA) replaces the VPN tunnel with identity-aware, application-specific access. Instead of connecting to the network and then accessing applications, the user authenticates to a policy enforcement point that verifies their identity and device posture, then grants access specifically to the applications they are authorised for, with no implicit access to anything else. The attack surface of a compromised ZTNA session is dramatically smaller than that of a compromised VPN session.
For Web3 teams, the operational benefits of ZTNA are also significant. Remote access that verifies identity and device posture rather than network location works consistently regardless of where the user is connecting from: home, a co-working space, a conference, or a different country. The user experience is typically better than VPN, because access is granted to specific resources rather than routing all traffic through a central point. The security experience is better because every session is individually verified and monitored.
Implementing Zero Trust on a Budget
Full zero trust maturity across all five NIST pillars (identity, devices, networks, applications, data) is a multi-year programme for a large organisation. For a Web3 team of five to fifty people, the goal is not full zero trust maturity on day one: it is to apply zero trust principles to the highest-risk areas first and build maturity incrementally. The following phased approach delivers meaningful security improvement at each stage.
Phase 1: Identity Foundation (Weeks 1-4)
The identity layer is where the highest ROI zero trust controls are found. Deploy a centralised identity provider (Google Workspace or Okta) as the authoritative source of identity for all team members. Enable SSO across all applications, both internal and SaaS. Enforce hardware security key MFA on all accounts: this is the single most impactful security control available to a remote team and defeats a substantial proportion of known attack vectors against crypto industry targets. Conduct an immediate access review: identify all accounts, remove former team members, eliminate shared credentials, and establish a minimum access baseline for each role. Revoke any access that cannot be justified by the current role of its holder.
Phase 2: Device Trust (Weeks 4-8)
Define and enforce a device security baseline for all devices used to access work systems. The baseline should require full disk encryption, an up-to-date operating system with no known critical vulnerabilities, endpoint detection and response (EDR) software, and a screen lock policy. Deploy mobile device management (MDM) to enforce this baseline on managed devices. For roles with access to production infrastructure or signing operations, consider dedicated managed devices that are used only for those operations and never for general browsing or personal use. A developer who uses the same laptop to access production signing infrastructure and to download a Lazarus Group coding test has combined two threat surfaces that should be completely separated.
Phase 3: Network Access (Weeks 8-12)
Replace VPN-based remote access with a ZTNA solution. Cloudflare Zero Trust provides a free tier suitable for small teams and scales with team size. Google BeyondCorp Enterprise and Zscaler Private Access are enterprise-grade options. Configure access policies so that each team member's access is scoped to the applications and infrastructure their role requires: a developer should not have default access to treasury infrastructure, and a community manager should not have default access to production node administration.
Implement network segmentation between development, staging, and production environments. Enforce this segmentation at the infrastructure layer so that it cannot be bypassed by application-layer configuration changes. Require separate, explicitly verified authentication for any access that crosses segment boundaries.
Phase 4: Continuous Monitoring and Behavioural Analytics
Deploy centralised logging and monitoring across all identity and access events. Every authentication attempt, access grant, access denial, and session termination should be logged to a central security information and event management (SIEM) system. Configure alerts for high-priority anomalies: failed MFA attempts, access from new or unusual locations, access at unusual hours, and access to resources outside a user's normal baseline. Review anomaly alerts promptly: the value of continuous verification is only realised if the monitoring is actionable.
For signing operations and treasury management, integrate behavioural analytics into the signing workflow. Any signing event that occurs outside the normal operational pattern (time of day, device, network, transaction size, recipient) should trigger a mandatory out-of-band verification step before the signature is accepted as valid. This is the signing-specific application of the continuous verification principle: a single anomalous data point in a signing context warrants verification regardless of whether the authentication credentials were valid.
Aligning Zero Trust with the PPT Framework
Zero trust is a technology model, but its effective implementation requires equal attention to People and Process. The most sophisticated ZTNA deployment is ineffective if the team does not understand why access policies are enforced or how to respond when access is denied. Training should cover the rationale for zero trust controls (the threat model justifying continuous verification), the process for requesting access to resources not covered by the baseline policy, and how to report anomalies that may indicate compromise. Security awareness training should include specific coverage of the social engineering techniques used to target crypto industry teams, as detailed in the Lazarus Group OpSec playbook: because zero trust controls are most effective when the people operating within them understand the threat they are designed to counter.
Process alignment means ensuring that every team workflow that involves access to privileged systems has a documented zero trust-compatible process: how access is requested, how it is approved, how it is logged, and how it is reviewed. Access to production infrastructure requires a ticket. Signing operations follow a defined verification protocol. New user provisioning follows a standard onboarding process that grants only the minimum access required for the new role. Offboarding immediately revokes all access through the central identity provider. These processes ensure that the zero trust technology controls are consistently applied and that no access path exists that bypasses the verification model.
For firms operating under DORA or MiCA, zero trust architecture supports multiple compliance obligations: ICT risk management controls, access governance requirements, and the operational resilience mandates that require demonstrable control over who can affect critical systems. The DORA compliance framework explicitly references access controls and continuous monitoring as components of the required ICT risk management programme, making zero trust implementation directly relevant to regulatory compliance as well as security outcomes.
The Strategic Case for Zero Trust in Web3
Zero trust is not a compliance checkbox or a vendor narrative. It is the appropriate security architecture for an industry that is remote-first, operates distributed infrastructure, holds irreversible high-value digital assets, and is targeted by nation-state-level adversaries who have spent years developing techniques to exploit implicit trust. The crypto industry's security posture has developed primarily around the smart contract layer: the code is audited, the bug bounties are funded, and the formal verification work is done. What has not kept pace is the operational security layer: the access controls, the identity governance, the network segmentation, and the continuous monitoring that determine whether an attacker who reaches the perimeter of a protocol can reach its keys.
Zero trust closes that gap by treating every access request as potentially hostile until proven otherwise. In an environment where the perimeter does not exist and the assets are irreversible, that is the only defensible position.
Frequently Asked Questions
What is zero trust security?
Zero trust security is a security model based on the principle of never trust, always verify. It rejects the traditional assumption that traffic inside a network perimeter is trustworthy, and instead requires continuous verification of identity, device health, and context for every access request, regardless of whether it originates inside or outside a defined network boundary. Zero trust replaces implicit trust based on network location with explicit trust based on verified identity and policy.
Why is zero trust particularly relevant for Web3 organisations?
Web3 organisations are almost universally remote-first, with teams distributed across multiple countries and time zones, accessing infrastructure from personal devices and home networks. There is no meaningful network perimeter to defend. Traditional perimeter-based security is therefore structurally inapplicable. Additionally, Web3 infrastructure is highly distributed, spanning cloud providers, decentralised node networks, and third-party RPC providers: a perimeter model cannot encompass these boundaries. Zero trust, which operates at the identity layer rather than the network layer, is the appropriate security model for this environment.
Does zero trust replace VPNs?
In a zero trust model, VPNs are largely replaced by identity-aware proxies and software-defined perimeter solutions that grant access to specific resources rather than broad network segments. A VPN grants access to the network: zero trust grants access to a specific application or resource, with no implicit access to anything else on the network. Tools such as Cloudflare Zero Trust, Google BeyondCorp, and Zscaler Private Access implement this model. For Web3 teams, the transition from VPN to zero trust network access (ZTNA) typically improves both security and operational experience.
How does zero trust apply to smart contract deployers and protocol admin functions?
Zero trust applies to smart contract deployers and protocol admin functions through identity verification requirements, device posture assessment, and access scoping. A deployer should be required to authenticate with phishing-resistant MFA before any deployment action is authorised. The device used for deployment should meet a defined security baseline (managed device, up-to-date OS, no suspicious processes). Access to deployment credentials should be scoped to the specific deployment task. Continuous monitoring should flag anomalous behaviour such as deployments at unusual hours or from unusual network locations.
What is the minimum viable zero trust implementation for a small Web3 team?
The minimum viable zero trust implementation for a small Web3 team covers three areas. Identity: enforce phishing-resistant MFA (hardware security keys) on all accounts, implement single sign-on so that identity is centralised and access can be revoked instantly, and conduct regular access reviews. Device: establish a device management policy requiring all devices used for work to meet a security baseline (full disk encryption, endpoint protection, OS up to date). Network access: replace broad VPN access with identity-aware access controls for specific applications and infrastructure. These three measures deliver the core zero trust principles without requiring a large tool deployment or dedicated security team.