Zero Trust Architecture (ZTA) has gained significant traction across cybersecurity since NIST formalised the concept in SP 800-207 in 2020.
The principle of “never trust, always verify” has been widely adopted in government, financial services, and critical infrastructure as a replacement for the traditional perimeter-based model, which extends implicit trust to anything within the network boundary.
For organisations operating a CCSS Trusted Environment (cryptocurrency exchanges, custody platforms, wallet infrastructure providers, and other VASPs), the question of how zero trust applies to protecting cryptographic key material warrants careful examination. The resources being secured are not conventional enterprise applications or databases; they are key material that control irreversible financial transactions, and this distinction has significant implications for how zero-trust principles are applied.
Some zero-trust concepts align naturally with CCSS requirements and strengthen the security of the CCSS Trusted Environment. Others introduce complexities and conflicts that do not arise in standard enterprise settings. This article works through both sides of that equation and proposes a pragmatic model for adoption.
The Zero Trust Model in Brief
Precision about what zero trust entails is a useful starting point. NIST SP 800-207 articulates several foundational principles.
Network location confers no implicit trust; a device on the internal network receives no more trust than one connecting over the public internet. Trust is established per session through authentication and authorisation.
Access decisions are made as close to the resource as possible, drawing on multiple signals: identity, device posture, behavioural patterns, location, and time.
The network is treated as hostile. Microsegmentation partitions resources so that compromise of one system does not automatically yield access to others.
Continuous monitoring and validation replace periodic checks.
All of the these principles were conceived for enterprise IT environments protecting corporate applications, databases, and cloud services. Translating them to a CCSS Trusted Environment, where the protected resources are cryptographic keys governing irreversible value transfer, calls for deliberate adaptation.
Security Benefits of Zero Trust for CCSS Environments
Network Isolation Through Micro-Segmentation
Microsegmentation is arguably the single most valuable zero-trust contribution to a CCSS Trusted Environment. It establishes hard boundaries around the key management infrastructure, separating it from the wider corporate network.
Without segmentation, signing servers, wallet management interfaces, backup infrastructure, and monitoring systems may share a network segment with corporate email, employee workstations, and general business applications. Any compromise on that shared segment opens a potential lateral movement path toward the signing infrastructure.
The Bybit incident of February 2025 made this risk concrete. Attackers reached the signing interface from the broader operational environment. Had the signing infrastructure been isolated in its own microsegmented zone with strict ingress and egress controls, that lateral movement path would have been substantially harder to exploit.
CCSS codifies related principles in requirement 1.05.2.1 (key material must be used only within the CCSS Trusted Environment) and requirement 1.05.2.2 (key material operations must be isolated from other operating system and application processes). Zero-trust microsegmentation provides an architectural mechanism for satisfying these requirements in practice.
Cloud-Native Segmentation and Identity Controls
A significant proportion of Web3 platforms operate without on-premises infrastructure. Their signing services, wallet management interfaces, and monitoring platforms run in cloud environments such as AWS, GCP, or Azure. Cloud environments are, in many respects, well-suited to microsegmentation because the infrastructure is software-defined.
Network isolation through VPCs
Each major cloud provider offers Virtual Private Clouds (VPCs, or VNets in Azure) that deliver logically isolated network sections. The signing infrastructure can be deployed in a dedicated VPC, fully separated from both the corporate application VPC and any public-facing services. Communication between VPCs is mediated by VPC peering or transit gateways, where every connection is explicitly configured and can be restricted by port, protocol, and IP range.
Within a VPC, subnets provide additional segmentation. Signing servers reside in a private subnet with no internet-facing ingress. Blockchain nodes occupy a separate subnet. Administrative interfaces sit in a third.
Each subnet enforces its own network access control lists (NACLs) as stateless firewalls at the subnet boundary, while security groups provide stateful firewall controls at the instance level. The two layers operate in combination.
Cloud IAM as a zero-trust policy layer
Cloud provider IAM systems function as built-in zero-trust policy engines. Every API call to the cloud infrastructure is authenticated and authorised through IAM, which means access to signing services is governed not only by network rules (can this IP reach this port?) but also by identity policies (is this principal authorised to invoke this action on this resource, under these conditions?).
For a cloud-hosted CCSS Trusted Environment, IAM policies can enforce conditions including: only designated roles may access the key management service; access is permitted only from specified VPCs or IP ranges; access requires multi-factor authentication; and all access is logged to CloudTrail, Cloud Audit Logs, or the provider’s equivalent. These controls map to CCSS requirements 1.05.1.1 (multi-factor authentication), 1.04.1.1 (grant/revoke), and 2.02.1.1 (audit trails).
Private endpoints and service mesh
Cloud key management services (AWS KMS, GCP Cloud KMS, Azure Key Vault) support access via private endpoints (AWS PrivateLink, GCP Private Service Connect, Azure Private Link), ensuring that traffic between the signing infrastructure and the key management service remains off the public internet. This adds an isolation layer beyond network segmentation.
For containerised workloads, which are common in Web3 platform architectures, service-mesh technologies such as Istio or Linkerd provide application-layer segmentation. Each service communicates through encrypted, mutually authenticated channels, with fine-grained policies governing inter-service communication. This represents micro-segmentation at the application layer rather than the network layer, and it aligns well with zero-trust principles.
Cloud-specific threat considerations
Cloud-native zero trust also introduces threat vectors absent from on-premises environments. Misconfigured security groups remain among the most frequent causes of cloud security incidents. An overly permissive IAM policy can expose sensitive data that network controls would otherwise block. Under the shared responsibility model, the cloud provider secures the underlying infrastructure, while the customer is responsible for configuring VPCs, security groups, IAM policies, and encryption settings.
Organisations hosting their CCSS Trusted Environment in the cloud should ensure their threat model (requirement 2.03.2.1) explicitly addresses cloud-specific risks: IAM misconfiguration, security group drift, credential exposure in code repositories, and the possibility that compromise of the cloud management console grants access to the entire environment. The CCSSA will evaluate whether the cloud architecture provides genuine isolation or only the appearance of it.
Identity-Based Access in Place of Network-Location Trust
Zero trust replaces the assumption that internal network traffic is trustworthy with per-request identity verification. Rather than “this request originates inside the network, so it is trusted,” the architecture asks “who is making this request, from which device, at what time, and does this match their established behaviour?”
This principle aligns directly with CCSS requirements for multi-factor authentication (1.05.1.1), grant/revoke checklists (1.04.1.1), and the broader personnel security requirements (1.05.3.1 through 1.05.7.1). Zero trust provides an architectural framework for consistently enforcing these controls, rather than relying solely on procedural compliance.
In operational terms, every access to the signing infrastructure requires identity verification (not merely a VPN connection), the identity is confirmed through multiple factors, the access is logged and monitored (supporting requirements 2.02.1.1 and 2.02.3.1), and access can be revoked in real time upon detection of anomalous behaviour.
A practical illustration: a key custodian needs to participate in a signing operation. Under a traditional architecture, the custodian connects to the corporate VPN and, once on the internal network, can reach the signing interface because internal traffic is implicitly trusted.
Under a zero trust architecture, the custodian authenticates via their identity provider using multi-factor authentication, the device posture is assessed (is the device managed, patched, and running approved software?), the access request is evaluated against current policy (is this custodian authorised for this wallet, at this time, from this location?), and only then is the session to the signing interface established. Every step is logged. Should the device fail a posture check mid-session, the connection can be terminated immediately.
For geographically distributed signing operations, where key custodians operate from different locations (as CCSS requirements 1.02.3.1 and 1.02.4.1 encourage), identity-centric access control is especially relevant. The custodian’s identity and device posture are verified regardless of physical location, delivering consistent security without requiring all custodians to share a single network.
Continuous Monitoring as a Structural Element
Within a zero-trust architecture, continuous monitoring is not bolted on as an afterthought; it is integral to how the system operates. Every access decision generates telemetry.
Every active session is monitored for shifts in risk posture. Anomalous behaviour triggers a real-time response. This maps to the CCSS monitoring requirements, particularly the Level 2 requirement for continuous, real-time monitoring with alerting (2.02.3.2) and the Level 3 requirement for blockchain state monitoring (2.02.4.1). Zero trust provides the architectural rationale for investing in comprehensive monitoring: it is a fundamental component of trust decision-making, not merely a compliance obligation.
Enforcing Least Privilege at the System Level
Zero trust operationalises least privilege. Each user, device, and process receives only the minimum access required by its function, and that access is dynamically adjusted based on context.
Within the CCSS Trusted Environment, this means a key custodian’s access is limited to the signing operations they need to perform. An operations analyst can view transaction logs but cannot initiate transactions. A system administrator can manage infrastructure, but has no direct access to key material. These separations are easier to implement and enforce within a zero-trust architecture than across a flat network, where access boundaries depend solely on policy and procedure.
Managing Supply Chain Trust Boundaries
Zero trust’s principle of treating every connection as untrusted extends naturally to the service-provider relationships governed by CCSS requirement 2.03.3.1.
An MPC provider’s API, a cloud HSM service, a blockchain node provider, and a smart contract audit firm each represent external connections to the CCSS Trusted Environment. Zero trust architecture subjects these connections to the same verification requirements as any other access: authenticated, authorised, encrypted, monitored, and revocable.
Where Zero Trust Creates Challenges in CCSS Environments
Offline Key Material and Air-Gapped Systems
Zero trust presupposes continuous connectivity. The architecture depends on real-time identity verification, ongoing session monitoring, and dynamic access decisions, all of which require network communication with identity providers, policy engines, and monitoring systems.
Cold storage key material is, by design, offline. Its security model is predicated on air-gapping: physically isolating the key material from any network connection. Continuous identity verification cannot be applied to a hardware wallet stored in a vault. Session monitoring cannot cover a signing operation on an air-gapped device. Access policies cannot be dynamically adjusted for key material that is connected to no policy engine.
Zero-trust architecture, therefore, applies to the operational layer surrounding cold storage (who can access the vault, how vault access is authenticated, and how the retrieval process is monitored), but not to the cold-storage key material itself. That material’s security relies on physical isolation, not continuous verification. Introducing connectivity to force a zero-trust model onto cold storage would diminish its security rather than enhance it.
Conflicts with Key Ceremony Requirements
CCSS Level 3 mandates formal key ceremonies (requirement 1.01.3.2) conducted in controlled environments under specific procedures: secure rooms, witnesses, segregation of duties, and signed runbooks. Key ceremonies are deliberately isolated from normal operational infrastructure. The ceremony room is inspected for surveillance devices, windows are covered, and the environment is physically secured.
Zero trust’s reliance on continuous monitoring and identity verification through centralised systems conflicts with this deliberate isolation.
If the ceremony environment must be disconnected from the network (to prevent surveillance and data exfiltration), it cannot communicate with the zero-trust policy engine.
Identity verification during the ceremony depends on physical, in-person methods (government-issued identification, witnesses) rather than digital identity providers. This is not a shortcoming of zero trust; it is a recognition that certain high-assurance operations are better served by physical security controls than by network-based verification mechanisms.
The zero trust architecture appropriately governs access to the ceremony location, the scheduling and authorisation of the ceremony, and the post-ceremony handling of generated key material. The ceremony itself operates under a separate security model.
The Policy Engine as a Single Point of Failure
Zero trust creates a critical dependency on the policy decision point (PDP). Every access request is evaluated by the PDP, which renders real-time authorisation decisions based on identity, device posture, context, and policy. If the PDP becomes unavailable, no access decisions can be made.
In a conventional IT setting, a brief PDP outage means employees lose access to email or applications for a short period. In a cryptocurrency operations context, a PDP outage could halt signing operations entirely, potentially during a time-sensitive response to a market event or a Key Compromise scenario requiring urgent fund movement.
The PDP also becomes a high-value target. An attacker who compromises the policy engine can manipulate access decisions across the entire CCSS Trusted Environment. This represents a form of centralisation risk that carries a certain irony in an industry built on decentralisation: the organisation has replaced implicit trust in the network with explicit trust in the policy engine, and compromise of that engine would be catastrophic.
Mitigation requires redundancy (multiple PDPs with failover capability), resilience (the ability to fall back to pre-approved emergency access procedures if a PDP fails), and rigorous security (treating the PDP as one of the most critical systems in the environment and applying dedicated security controls).
The PDP must reside within the security boundary, yet cannot be subject to the same zero-trust controls it enforces, as this would create a circular dependency (the PDP authenticating itself to the PDP to make access decisions). The PDP, therefore, operates at a different trust level than the rest of the infrastructure. It is, in effect, the one component that must be implicitly trusted, an inherent tension in the zero trust model that becomes particularly acute when the protected resources are cryptographic keys controlling irreversible financial transactions.
The practical response is to harden the PDP to a higher standard than any other component in the environment: dedicated infrastructure, a minimal attack surface, strict change management, comprehensive logging, and independent monitoring that does not itself depend on the PDP.
MPC and Threshold Signing Complications
MPC threshold signing distributes key material across multiple parties, with each party holding a share that is individually useless. The signing protocol requires inter-shareholder communication to produce a valid signature without reconstructing the complete key.
Within a zero-trust architecture, this inter-shareholder communication must traverse network controls (firewalls, micro-segmentation boundaries, identity verification checkpoints). If those controls are too restrictive, they can block MPC protocol traffic and prevent signing operations. If they are relaxed to accommodate the MPC protocol, they introduce an exception in the zero-trust model that an attacker could exploit.
The difficulty is that MPC protocols frequently employ communication patterns (peer-to-peer connections between shareholders, multiple rounds of interaction, latency-sensitive cryptographic operations) that do not align neatly with standard zero-trust traffic models (client-to-server, request-response, API calls).
Configuring zero-trust controls to permit the MPC protocol while blocking all other traffic requires a detailed understanding of both the protocol and the network architecture.
Proportionality of Investment
Zero-trust architecture carries a meaningful cost. It requires investment in identity infrastructure (identity providers, multi-factor authentication systems, device management platforms), policy infrastructure (policy decision points, policy information points, policy administration systems), network infrastructure (micro-segmentation, software-defined perimeters, encrypted channels), and monitoring infrastructure (SIEM integration, behaviour analytics, anomaly detection).
For a large custody provider managing billions in assets, this investment is proportionate and likely already in place. For a smaller VASP with a handful of employees and a straightforward wallet architecture, the full zero-trust stack may represent a disproportionate investment relative to the risk reduction it achieves. The organisation should evaluate whether the operational complexity and cost of zero trust are proportionate to its specific risk profile, which is ultimately a threat model decision under requirement 2.03.2.1.
A Pragmatic Model: Selective Adoption
For most CCSS Trusted Environments, the most effective approach is selective adoption: applying zero trust principles where they deliver the greatest security benefit, while acknowledging that certain elements of the key management architecture are better protected by other models.
Operational infrastructure
Signing servers, wallet management interfaces, administrative access points, monitoring platforms, and network boundaries all benefit from zero-trust controls: microsegmentation, identity-centric access, continuous monitoring, and least privilege.
Offline key material
Cold storage, backup key material, and key ceremony environments are secured through physical isolation, tamper-evident controls, and procedural safeguards, not through network-based zero trust mechanisms.
MPC communication
MPC signing traffic requires network controls that are aware of the protocol’s communication patterns, rather than generic zero-trust policies that may interfere with the signing process.
Policy engine resilience
The zero trust policy engine must be redundant, resilient, and hardened to a standard exceeding that of the systems it protects. Emergency access procedures must cover scenarios in which the zero-trust infrastructure itself becomes unavailable.
Threat-model-driven design
The threat model under requirement 2.03.2.1 should determine where zero-trust controls are deployed based on the specific threats to the organisation’s architecture. This is preferred over applying zero trust uniformly as an end in itself.
The selective model avoids two extremes: the organisation that disregards zero trust entirely and relies on perimeter security (as the Bybit incident demonstrated, insufficient), and the organisation that attempts to extend zero trust to every component, including air-gapped cold storage (which introduces connectivity and complexity that actually weaken security).
The appropriate balance depends on the architecture, the threat model, and the types of key material under management.
An organisation that operates exclusively with hot wallets and MPC signing will find that zero-trust principles apply to virtually the entire CCSS Trusted Environment. An organisation that relies primarily on cold storage and key ceremonies will find zero trust applicable to the operational infrastructure but not to the key material itself. Most organisations sit somewhere between these positions, and the architecture should reflect their specific circumstances.
Mapping CCSS v9 Requirements to Zero Trust
Several CCSS requirements map naturally to zero-trust principles, including the following.
- Microsegmentation supports requirements 1.05.2.1 (usage within the CCSS Trusted Environment) and 1.05.2.2 (process isolation)
- Identity-centric access supports requirements 1.05.1.1 and 1.05.1.2 (multi-factor authentication) and 1.04.1.1 (grant/revoke checklists)
- Continuous monitoring supports requirements 2.02.3.1 and 2.02.3.2 (monitoring and alerting) and 2.02.4.1 (blockchain state monitoring). Least privilege reinforces requirement 1.04.1.1 (grant/revoke)
- Supply chain trust boundaries support requirement 2.03.3.1 (service provider management)
The requirements less amenable to zero trust are those addressing offline key material (the 1.03.x backup requirements), key ceremonies (1.01.3.2), and data sanitisation (1.06.x), all of which depend on physical rather than network-based controls.
Closing Observations
Zero Trust Architecture (ZTA) provides tangible security improvements for the CCSS Trusted Environment. Microsegmentation constrains the blast radius of a compromise. Identity-centric access eliminates network-location trust. Continuous monitoring enables real-time detection. These benefits are most pronounced at the operational infrastructure layer, where most significant cryptocurrency breaches have occurred.
Yet zero trust is not a comprehensive solution for every aspect of a CCSS Trusted Environment. It does not apply to offline key material. It conflicts with the deliberate isolation of key ceremony environments. It creates a critical dependency on the policy engine. And its operational complexity may be disproportionate to that of smaller entities.
A considered approach deploys zero trust, strengthens security, applies physical controls where appropriate, and uses the threat model to determine the balance.
If you are designing or refining the security architecture for your CCSS Trusted Environment, zero trust should be part of the discussion, but it should not dominate it.