Every virtual asset service provider (VASP), whether operating as a custodian, an exchange, or a wallet infrastructure provider, holds cryptographic key material that adversaries actively seek to compromise.
The threat actors range from organised criminal groups and state-sponsored operatives to malicious insiders and supply chain intermediaries. Acknowledging that these threats exist is insufficient; what matters is whether an organisation has systematically identified them, evaluated the associated risks, and deployed controls that bring residual risk within acceptable bounds.
CCSS v9 codifies this expectation through Aspect 2.03 with two distinct requirements: the threat model under requirement 2.03.2.1 (a Level 1 obligation) and the risk management programme under requirement 2.03.2.2 (a Level 2 obligation). These two requirements collectively establish the risk management foundation for the CCSS Trusted Environment, and every other control in the standard, from key generation through to incident response, should trace back to an identified threat and a corresponding risk decision.
This article examines both requirements in depth: what each demands, how they differ, and how they function as complementary elements within a coherent security programme.
Defining the Threat Model
At its core, a threat model is a structured exercise that identifies the threats facing a defined system, documents the controls deployed to address those threats, and articulates the residual risk remaining once those controls are in place. It is scoped specifically to the CCSS Trusted Environment, encompassing the technology, personnel, and processes that participate in the generation, storage, use, and management of key materials.
A threat model is not a generic enterprise risk register; it is focused and system-specific. Because requirement 2.03.2.1 sits at Level 1, it applies to every organisation pursuing CCSS certification regardless of the target level.
The requirement calls for identifying security threats to the CCSS Trusted Environment, defining and implementing controls to reduce residual risk to acceptable levels, periodically reviewing the threat model, and specifying task frequencies for controls requiring recurring execution (such as audit log reviews or backup inspections).
Therefore, without first identifying the threats relevant to the CCSS Trusted Environment, an organisation cannot construct a complete or coherent set of controls. Any control not anchored to an identified threat is either addressing an unassessed risk or overlooking a risk that has not been recognised.
Threat Categories Relevant to the CCSS Trusted Environment
A well-constructed threat model for a CCSS Trusted Environment should address several threat categories. The following are not exhaustive, but they represent the areas a CCSSA expects to find documented.
Attacks against signing infrastructure
The February 2025 Bybit incident illustrated that capable adversaries target the systems and interfaces used to authorise transactions, rather than focusing solely on key material. Andhov, (April 1, 2025) Inside The Bybit Hacking Incident: Lessons From The Breach. Forbes.
Relevant attack vectors include compromising the signing interface, manipulating the transaction details displayed to authorised signers, exploiting vulnerabilities in wallet software, and network-boundary attacks targeting the CCSS Trusted Environment.
Supply chain risks
The security posture of any VASP is only as strong as the security of its critical vendors. MPC providers, HSM vendors, software library maintainers, cloud infrastructure providers, and smart contract development firms each represent a potential avenue of compromise. The supply chain attack pattern documented in the SolarWinds incident, where a legitimate software update channel delivers malicious code, is well established.
The threat model should identify which suppliers are within the CCSS Trusted Environment boundary and assess the consequences of their compromise.
Insider risks
Personnel with access to key material, both current and former, constitute a threat that purely technical controls cannot fully mitigate. The assessment should distinguish between the malicious insider (an individual who deliberately acts against organisational interests) and the negligent insider (an individual who creates vulnerabilities through error or insufficient training).
State-sponsored workforce infiltration
Research from CrowdStrike, the FBI, and Microsoft Threat Intelligence has documented campaigns in which North Korean operatives have used fabricated identities to secure employment at cryptocurrency companies, reportedly generating hundreds of millions of dollars for the regime annually. Kapko, M. (April 7, 2026). Cybercrime losses jumped 26% to $20.9 billion in 2025. CyberScoop. Organisations that hire remotely should explicitly address this threat.
Compromise scenarios for key material
Each type of key material held by the organisation (private keys, seed phrases, key shares, encryption keys, and backup material) carries distinct compromise scenarios. The scope and impact of a seed phrase compromise differ materially from those of a single-key compromise in a multi-signer arrangement, and the corresponding controls and response plans will differ accordingly.
Physical and environmental threats
Fire, flood, theft, and equipment failure are neither exotic nor unlikely, and they remain common causes of key material loss. Controls such as encrypted backups, environmental protections, and geographic distribution of material should all be traceable to these documented threats.
The deliverable from this exercise is a document that maps each threat to its corresponding controls and states the residual risk after those controls are applied. Executive management, who bear accountability under requirement 2.03.1.1, must formally accept that the residual risk falls within the organisation’s stated tolerance.
Keeping the Threat Model Current
The threat landscape does not remain static. New attack methodologies emerge (AI-assisted social engineering, novel smart contract exploitation techniques), previously unknown vulnerabilities appear in production systems and software, and the organisation’s own architecture evolves through the addition of new wallets, changes of provider, or expansion into new markets. Requirement 2.03.2.1 accordingly mandates periodic review of the threat model.
Each review cycle should evaluate whether the documented threats remain current or new threats have emerged; whether the controls remain effective or environmental changes have weakened them; and whether the residual risk remains acceptable given any changes in assets under management, regulatory obligations, or intelligence on attacker capabilities.
CCSS does not prescribe a specific review frequency; the organisation determines what is appropriate for its operating environment. That said, the CCSSA will evaluate whether the chosen cadence is reasonable given the organisation’s threat profile.
An entity managing billions in custodied assets that last reviewed its threat model two years ago is unlikely to satisfy the requirement. An annual review is a common baseline, supplemented by ad hoc reviews triggered by significant events, such as a major industry security incident, an architectural change, or the introduction of a new regulatory obligation.
How Task Frequencies Link the Threat Model to Daily Operations
A frequently overlooked aspect of requirement 2.03.2.1 is the task frequency provision, which states that where a procedure requires tasks to be performed at a defined frequency for a given control (such as reviewing audit logs), the threat model must specify that frequency. This provision transforms the threat model from a purely analytical exercise into an operational control.
The frequency with which audit logs are reviewed, tamper-evident seals on backup key material are inspected, access rights are reassessed, and background checks are renewed should all be documented within the threat model and justified by the underlying threat assessment.
The result is a traceable chain of reasoning. When a threat is identified (for example, an insider compromise of backup key material), a control is implemented (tamper-evident seals on backup storage with periodic inspection), and the inspection frequency is documented in the threat model (monthly, in this example). The CCSSA can then confirm that inspections occur at the documented frequency by reviewing operational records.
An organisation that cannot articulate why a particular frequency was selected will face scrutiny from the CCSSA. The concern is whether the threat model genuinely drives the control environment or whether it was produced retrospectively to satisfy a compliance requirement.
The Risk Management Programme: Moving Beyond the Threat Model
Requirement 2.03.2.2, a Level 2 obligation, extends the threat model into a structured risk management programme aligned with an industry-recognised standard such as ISO/IEC 27005 or NIST SP 800-37.
The threat model asks: “What are we defending against, and which controls do we have in place?” The risk management programme asks: “How do we systematically identify, evaluate, and manage risk across the CCSS Trusted Environment on a continuing basis?”
A threat model may exist as a standalone document. A risk management programme is a continuous process with defined inputs, activities, outputs, and governance structures. Its components include systematic risk identification (going beyond the obvious threats), risk analysis (evaluating both likelihood and impact for each identified risk), risk evaluation (comparing assessed risks against the organisation’s risk criteria to determine which require treatment), risk treatment (selecting and implementing controls to reduce, transfer, avoid, or accept each risk), and ongoing risk monitoring and review (tracking risks over time, assessing treatment effectiveness, and updating the assessment as conditions change).
The requirement that the programme align with an industry-recognised standard is intentional. ISO/IEC 27005 provides a structured information security risk management methodology that integrates with an ISO 27001 management system. NIST SP 800-37 provides the Risk Management Framework used across US federal systems and increasingly adopted in the private sector. (ISO/IEC 27005:2022 – Guidance on managing information security risks, 2022)
Both produce repeatable, auditable processes with documented outputs, which is what the CCSSA requires for assessment. Alternative risk management standards or frameworks are also acceptable; the CCSSA is evaluating the programme’s effectiveness rather than mandating a specific methodology.
The Relationship Between the Two Requirements
The threat model and the risk management programme are complementary rather than redundant. An organisation pursuing Level 1 certification requires a threat model. An organisation pursuing Level 2 certification requires both.
In operational terms, the threat model provides initial threat identification and control mapping. The risk management programme supplies the methodology and governance for managing those risks over time.
The threat model serves as input to the risk management programme, and the programme, in turn, produces outputs (a risk register, treatment plans, monitoring reports) that are maintained throughout its defined lifecycle.
For organisations that already operate a risk management programme under ISO 27001, the CCSS threat model should be incorporated into the existing information security management system (ISMS) rather than maintained as a separate artefact. The threats to the CCSS Trusted Environment are a subset of the organisation’s broader information security risk landscape, and managing them within the established framework is both more efficient and more effective than operating a parallel process.
For organisations without an existing formal risk management programme, the Level 1 threat model serves as the foundation. When the organisation is ready to advance to Level 2, that threat model is formalised into a structured programme using ISO/IEC 27005, NIST SP 800-37, or an equivalent methodology.
Recurring Weaknesses Observed in Assessments
Several patterns recur across organisations assessed against these requirements.
Generic threat identification
The organisation produces a document citing broad categories (“hacking,” “malware,” “social engineering”) without analysing which specific attack vectors are relevant to its architecture, which systems are targeted, or what the impact of a successful attack would be. A threat model that makes no reference to the actual wallet architecture, signing workflow, or key material inventory is a template rather than a threat model.
Absence of threat-to-control mapping
Threats are documented, and controls are implemented, but there is no clear linkage between them. Multi-factor authentication, encrypted backups, and monitoring may all be in place, yet no one has documented which threats each control is intended to mitigate. Without this mapping, it becomes impossible to determine whether the control set is complete (every identified threat has at least one corresponding control) or whether each control is effective against its intended threat.
Unjustified task frequencies
Audit log reviews occur weekly, but the organisation cannot explain why the cadence is weekly rather than daily or monthly. The frequency was selected because it appeared reasonable, not because the threat assessment indicated that a seven-day detection window was appropriate for the identified threat. The CCSSA will probe this, and “it appeared reasonable” is not an adequate justification.
A Practical Approach to Implementation
For organisations beginning their CCSS implementation, the following sequence provides a sound starting point.
Begin with the key material inventory under requirement 2.04.1.1. Threats to key material that the organisation is unaware it holds cannot be identified. The inventory defines what needs protecting.
Establish the CCSS Trusted Environment boundary
Identify all systems, individuals, and processes involved in key management operations. This boundary determines the scope of the threat model. Engaging a CCSS Implementer (CCSSI) can be valuable for scoping exercises.
Conduct systematic threat identification
Working through the threat categories outlined above (external attackers, supply chain, insiders, state-sponsored infiltration, key material compromise scenarios, and physical/environmental threats), assess which are relevant to the organisation’s specific architecture and operating model.
Map each control to the threats it addresses
For each identified threat, document which controls mitigate it, and evaluate whether those controls are sufficient to bring the residual risk within acceptable bounds. Where they are not, identify the additional controls required.
Derive task frequencies from the threat assessment
For each control that requires periodic execution, specify the frequency and justify it. For example: “Monthly backup inspections, because the threat model identifies insider access to backup storage as a medium-likelihood threat and a monthly inspection cadence provides a detection window consistent with the assessed attack tempo.”
The threat model must be formally documented, not an unwritten understanding held by a single individual. The CCSSA will need to review it, and the organisation’s personnel should be able to consult it.
Establish and follow a review cycle. Set a minimum annual review cadence and conduct the reviews on schedule. Record what was reviewed, what changed, and how the residual risk assessment was updated.
The Threat Model as a Structural Foundation
The threat model and risk management programme are not peripheral activities. They are foundational requirements on which the rest of the CCSS control framework depends.
The controls an organisation implements across key generation, storage, access control, signing, destruction, and monitoring should all be traceable to threats documented in the threat model.
Task frequencies for periodic controls (log reviews, backup inspections, background check renewals, Key Compromise Policy testing) should all be specified within the threat model.
The Key Compromise Policy required under requirement 2.04.1.2 should address the compromise scenarios identified by the threat model. The service provider management programme under requirement 2.03.3.1 should evaluate the supply chain threats documented in the threat model.
During the assessment process, the CCSSA will typically begin by reviewing the threat model to understand the threats the organisation has identified and how it has structured its response.
Every subsequent control assessment is then tested against this context: Does the control address an identified threat? Is it implemented as documented? Is it operating at the frequency specified by the threat model?
A thorough and well-maintained threat model supports a more efficient assessment process and, more importantly, produces a more coherent security posture. A weak or absent threat model makes it considerably harder to justify control choices, defend task frequencies, and present a convincing picture of overall security readiness.
Key Takeaway
VASP security teams should remember that risk management should align with industry standards such as ISO/IEC 27005 or NIST SP 800-37. Additionally, threat models must be system-specific, regularly reviewed, and map threats to controls and task frequencies. Finally, CCSS v9 requires both a threat model and a risk management programme for compliance.
CCSS auditors or assessors will remember the importance of traceability from threats to controls and justified task frequencies.