CryptoCurrency Security Standard (CCSS) Aspect 1.02
1.02.1 Signing Configuration
Aspect Objective: This aspect defines the criteria for applying single-signer and multi-signer mechanisms to wallets. This ensures that the signing configuration aligns with the criticality of the wallet, risk exposure, and operation requirements.
Single-signer mechanisms will consider the following factors:
- The criticality of the wallet to the CCSS Trusted Environment.
- The potential impact of loss of customer funds controlled by the wallet.
- The risk of a wallet compromise in the defined threat model (Requirement 2.03.2.1).
- The effectiveness of existing security controls protecting the wallet.
Multi-signer mechanisms are considered best practice for enhancing security. However, multi-signer mechanisms can potentially impact transaction speed and operational efficiency, therefore single-signer mechanisms can align with the CCSS only if the criteria in 1.02.1.1 is met. Single-signer configurations may be adopted by full-custody providers to allow rapid fund management. To ensure strong protection and distributed control, multi-signer mechanisms are implemented in wallets that hold the majority of customer funds.
1.02.2 Key Material Redundancy
Aspect Objective: This aspect ensures the availability of funds, even if a signing key becomes inaccessible, by requiring redundancy in multi-signer configurations.
For wallets that implement a multi-signer mechanism, they must include at minimum one redundant key for recovery purposes. This redundancy guarantees that funds remain accessible if one operational key is lost, compromised, or unavailable.
One common method that is considered best practice is creating a wallet that requires 2-of-3 signatures to authorize transactions for flexibility and recovery assurance.
1.02.3 Geographic Material Distribution
Aspect Objective: This aspect mitigates risks by separating key material geographically for multi-signer wallets. The risks that come with localized disruptions, including floods and break-ins, are minimized with key material separated across multiple locations.
Although locations can reside within the same region or country, risk assessments evaluate the potential consequences of storing all key materials within a single geographic area. Distribution across multiple, secure regions enhances overall resilience.
1.02.4 Entity Key Material Distribution
Aspect Objective: This aspect ensures that control of key material is decentralized across separate business units and legal entities, reducing organizational and legal risks.
For wallets implementing multi-signer mechanisms, key material must be stored by distinct operators within the same entity or by separate, trusted entities. These entities can be legal, accounting, or custody partners. This separation prevents a single organizational or legal disruption from affecting key material and disrupting fund availability.
Importantly, this distribution approach does not violate requirement 1.01.1.1, because separate entities do not meet the definition of an actor.
1.02.5 Wallet Generation Policy Documentation
Aspect Objective: This aspect focuses on creating a documented policy to ensure consistency and compliance regarding wallet generation processes.
This policy document includes details of the company’s internal policies and procedures to provide transparency. It will also cover all relevant areas of wallet generation to limit errors. A documented policy ensures standardization and provides clear operation guidelines for users.
Click to learn more about the CCSS.
This article was written by Shreya Patel.
1.01.1 Actor-generated Key Material
This aspect requires that the individual or system using key material is also the one generating it. The intent is to maintain confidentiality of the key material by preventing exposure to any party who is not the intended actor. Confidentiality is prioritized where access is strictly given to the actor generating the key material, and randomness ensures that keys must be unpredictable to maintain secure systems.
Additionally, digital signatures confirm the key material generation process has not been altered. The Level II requirement allows a digital signature for an extra measure of security. The digital signature for the key material is generated, published, and validated before each execution. This confirms that the key material generation process has not been compromised.
1.01.2 Validation of Generation Methodology
This aspect focuses on verifying the integrity and reliability of key generation methodology before it is used. The purpose is to validate that the process produces secure and unpredictable key material.
Validation of the methodology must happen prior to usage to confirm that the features will not restrict entropy, leak data, or create weaknesses. Unless security is being enhanced, software used in key generation must not restrict the values produced or store key material. A feature that would enhance security would be using Deterministic Random Bit Generators (DRBG).
By validating the integrity of the generation process, this aspect maintains the confidentiality and entropy needed for cryptographic protection.
1.01.3 Deterministic Random Bit Generator (DRBG) Compliance
This aspect focuses on key material adhering to the NIST SP 800-90A. NIST SP 800-90A ensures that DRBGs produce numbers that are statistically random. The goal is to ensure strong randomness is maintained, even though the generation process is deterministic.
The NIST SP 800-90A generation mechanism confirms that key material generation allows for high entropy and unpredictable outputs to minimize risks. The security and integrity of the key generation environment must be maintained.
Key generation must take place in a controlled and protected environment. The physical location should be inspected to ensure there is:
- No unauthorized recording/surveillance equipment
- No Visibility from outside or windows
- No weak entry points or uncontrolled access
- Access controls that are working as intended
- Backup power and environmental safeguards in place
All hardware and software involved must be up-to-date, verified, and functioning correctly. Portable devices must be secured, and every actor involved must follow a documented runbook so the process is consistent and accountable. Each actor generates their own key material independently to prevent any one person from influencing or exposing another participant’s key.
1.01.4 Entropy Pool
This aspect helps ensure that key material is generated using a Key Management System (KMS) with a strong, reliable entropy pool. Sufficient entropy is required for secure randomness. This prevents bias in key generation, reduced variability, or other properties that would allow for predictability or reproduction.
A robust entropy pool helps ensure that keys are unguessable, unique, and resistant to reproduction. Even strong algorithms fail without sufficient entropy, so this requirement reinforces one of the fundamental protections in secure key generation.
This article was written by Shreya Patel.
Why Traditional Security Standards Aren’t Enough for Digital Assets
As digital assets become more mainstream, traditional security standards alone are not enough. Traditional frameworks such as ISO 27001 and SOC 2 Type II audits have long been considered the gold standard for information security and organizational controls. Although these frameworks are valuable, they were designed for general IT systems and enterprise data instead of cryptographic assets.
This is why the CryptoCurrency Security Standard (CCSS) was developed. It introduces a crypto-specific framework focused on one of the critical elements in digital asset security: key material management.
Traditional Standards
Most organizations lean on traditional security standards because of their universal recognition and the broad assurance they provide to regulators, partners, and customers. These standards establish trust which demonstrates credibility in a wide range of industries.
- ISO 27001 establishes a structured framework for identifying risks, implementing security controls, and continuously improving governance across IT systems.
- SOC 2 Type II evaluates how effectively an organization’s controls operate over time, focusing on the core trust principles of security, availability, processing integrity, confidentiality, and privacy.
While these frameworks are valuable for general IT environments, they leave a critical gap when it comes to safeguarding digital assets.
CCSS: Designed for Cryptocurrency
The CryptoCurrency Security Standard (CCSS) addresses risks unique to the cryptographic key material used with blockchain-based systems. It establishes the conditions that must be met to ensure the secure generation of key material. It outlines the parameters for securely generating, storing, and using key material.
The CCSS covers several aspects regarding key material including:
- Key Generation: Ensuring randomness, entropy, and verifiable secure processes.
- Key Storage: Protecting against single points of failure by enforcing redundancy and separation.
- Key Usage: Requiring multiple factors or parties to authorize transactions, minimizing insider and external threats.
- Auditability: Offering measurable, cryptographic-specific benchmarks rather than generic IT policies.
Traditional frameworks measure how organizations secure their systems broadly, while the CCSS focuses on safeguarding the key material protecting digital assets.
Organizations securing digital assets should consider layering these standards, as each covers a different scope. Achieving ISO 270001 or SOC 2 certification establishes baseline trust with traditional partners and regulators, while CCSS certification demonstrates cryptographic key security to customers, exchanges, and custodians. Traditional security frames are broad and valuable, but the CCSS fills a critical gap by addressing key management practices that maintain trust in cryptographic systems. Together, they form a comprehensive defense that combines broad organizational security with specialized protection for digital assets.
This article was written by Shreya Patel.
Managing Key Material with the CryptoCurrency Security Standard (CCSS)
By following the CCSS in the creation and maintenance of systems, entities can build trust with stakeholders, protect funds from theft or loss, and show accountability through an third-party CCSS audit.
Aspects under Cryptographic Asset Management
-
- Aspect 1.01 – Key Material Generation
Aspect Objective: This aspect covers the generation of key material that will be used within a digital asset and blockchain protocol. The secure generation of key material requires two things to be secure: confidentiality and unpredictable numbers. Confidentiality is required to ensure that the newly generated key material is not read/copied by an unintended party. Nondeterministic and unpredictable numbers are required to ensure the newly generated key material cannot be guessed or determined by an unintended party. Each of the goals listed provide assurance that the key material is generated in a confidential and unguessable manner.
Getting this right forms the foundation for protecting digital assets; if key material is predictable or exposed, the system cannot be trusted. - Aspect 1.02 – Wallet Generation
Aspect Objective: This aspect covers the generation of wallets or addresses that can receive digital assets. Wallets are generated using cryptographic signing methodologies that can support single-signer and multi-signer mechanisms. Furthermore, wallets can be generated individually (commonly referred to as “Just a Bunch Of Keys” or JBOK wallets) or in a deterministic way that allows a set of addresses/key pairs to be generated from a single master seed. Security of wallet generation is derived from the integrity of the wallet in the face of various risks such as a lost/stolen/compromised key material and the confidentiality of the wallet that would make it difficult to associate a wallet with a particular actor.
Strong wallet generation ensures addresses are reliable, resistant to compromise, and do not easily reveal ownership– key ingredients for user confidence and system integrity. - Aspect 1.03 – Key Material Storage
Aspect Objective: This aspect covers the secure storage and backup of key material to ensure it remains protected, recoverable, and inaccessible to unauthorized parties. Key material is encrypted and backed up, with backups stored securely and protected from environmental threats. To prevent unauthorized use or tampering, access to operational key material and its backups is tightly controlled.
Well-designed storage means funds can be recovered in a crisis while staying shielded from misuse. - Aspect 1.04 – Key Material Access
Aspect Objective: This aspect covers the policies and procedures surrounding granting and revoking access to key material. Personnel typically have greater access to the CCSS Trusted Environment with respect to accessing its information, invoking privilege-restricted actions, and representing the entity to the public. Improper management of the onboarding and offboarding of personnel introduces risks of privileged accounts remaining when personnel depart, as well as unrevoked key material that persists in signing authority for certain transactions.
Well-managed access prevents key material from being abused after roles change. - Aspect 1.05 – Key Material Usage
Aspect Objective: This aspect covers the secure use of key material that minimizes the risks to the confidentiality of key material and the integrity of funds. A variety of risks are present when using key material that can lead to the loss of funds, including dirty signature vulnerabilities (i.e. re-used ‘R’ values), the opportunity for malware to copy or modify key material, and malicious insiders who use their authorized access to send unauthorized transactions.
Careful usage protects funds in motion and keeps legitimate transactions from being hijacked. - Aspect 1.06 – Data Sanitization Documentation
Aspect Objective: This aspect covers the removal of key material from digital media. Due to the manner in which file systems allocate data on digital media, digital forensic techniques can be employed to read old data that has previously been sanitized. Proper sanitization of digital media ensures the proper removal of all key material, eliminating the risk of information leakage from decommissioned devices like servers, hard disk drives, and removable storage.
Thorough sanitization prevents yesterday’s keys from becoming tomorrow’s breach. - Aspect 2.01 – Security Tests / Audits
Aspect Objective: This aspect covers third-party reviews of the security systems, technical controls, and policies that protect the CCSS Trusted Environment from all forms of risk as well as vulnerability and penetration tests designed to identify paths around existing controls. Regardless of the technical skills, knowledge, and experience of personnel who build and maintain the CCSS Trusted Environment, it has been proven that third-person reviews often identify risks and control deficiencies that were either overlooked or underestimated by personnel. For the same reasons that development companies require different people to test a product from those who write it, different people than those who implement a cryptocurrency system should assess its security. Third parties provide a different viewpoint and are independent of the technical controls and can be objective without risk of retaliation.
Independent testing brings objectivity and uncovers what insiders miss. - Aspect 2.02 – Log and Monitor
Aspect Objective: This aspect covers monitoring the CCSS Trusted Environment’s technical components audit logs for suspicious activity. When suspicious activity is identified, alerts must be generated so that personnel can triage and respond to the event to detect and respond to suspicious activity proactively.
Logging and monitoring turn hidden activity into visible alerts that can be acted on quickly. - Aspect 2.03 – Governance and Risk
Aspect Objective: This aspect covers the governance policies, standards, and procedures that guide and control an entity to ensure its CCSS Trusted Environment is effective, efficient, and secure. It also includes the requirements for a comprehensive risk management program to identify potential risks to the CCSS Trusted Environment and apply appropriate risk treatments.
Strong governance keeps security from being a one-time project and makes it an ongoing practice. - Aspect 2.04 – Key Compromise Documentation
Aspect Objective: This aspect covers the existence and use of documented policies and procedures that define the actions that must be taken in the event key material or its operator/holder are believed to have become compromised. Entities must be prepared to deal with a situation where key material has – even potentially – become known, determinable, or destroyed. Policies and procedures to govern these events decrease the risks associated with lost funds and increase the availability of the system to its users. Examples of when a Key Compromise Policy (KCP) would be invoked include the identification of tampering of a tamper-evident seal placed on the media that stores key material, the apparent disappearance of an operator whose closest friends and family cannot identify their whereabouts, or the receipt of communication that credibly indicates an operator or key material is likely at risk of being compromised. The execution of KCP makes use of Approved Communication Channels to ensure KCP messages are only sent/received by authenticated actors.
A tested compromise plan turns potential chaos into a coordinated response.
The CCSS is more than a checklist. It is a roadmap for building and operating crypto systems people can actually trust. Following it means protecting organizations, users, and, ultimately, the health of the entire crypto ecosystem.
If you are building or working with digital asset systems, take the time to learn what CCSS covers. It might just be the difference between being remembered for your innovation and being remembered for a breach.
Aspects under Operations
- Aspect 1.01 – Key Material Generation
Fireblocks Becomes First to Achieve CCSS v9.0 Certification at Level 3
We’re pleased to announce that Fireblocks is the first organization ever to have a system certified under Version 9.0 of the CryptoCurrency Security Standard (CCSS), the most current version of the standard, released in December 2024.
The certified system includes:
- Fireblocks Hot and Cold Vaults
- Fireblocks Secure Transfer
- Fireblocks Authorization Workflow
- Fireblocks Tokenization Engine
Fireblocks‘ system attained Level 3 certification as a Qualified Service Provider (QSP) – the highest attainable level – after undergoing a rigorous audit.
Why this matters: This certification shows that Fireblocks has implemented strong controls for managing and securing key material across its system, in line with the latest CCSS requirements.
Version 9.0 includes several important updates to the standard, and it builds on the strong foundation of earlier versions. Systems certified under v8.1 remain valid and have also demonstrated a high level of security through independent audit.
Shoutout to CCSSA Marc Krisjanous for another successful audit, CCSSA Phillip Moran, CFA for a successful peer review, and the Fireblocks team for setting the bar for what secure, independently-audited key management should look like under the version 9.0 of the CCSS.
As a reminder, this does not verify that another system which uses Fireblocks is CCSS certified at any level. Any third party who uses Fireblocks’ system must be audited for compliance in the areas where Fireblocks does not have control and certified (or not) in an audit for their cryptocurrency system.
Congratulations to the Fireblocks team on this industry-leading achievement!
👉 You can verify Fireblocks’ certification at: https://cryptoconsortium.org/completed-ccss-audits/
CCSS v8.1 Certification Eligibility Extended Through December 17, 2025
When CCSS v9.0 was released on December 17, 2024, it introduced major updates to requirements and audit expectations. While this version marks a strong step forward, the transition has impacted timelines for some teams already preparing for certification under v8.1.
To support those efforts, new system certifications may still be conducted under CCSS v8.1 if the Intent to Audit form is submitted by December 17, 2025.
What’s Changing
- New audits may use v8.1 or v9.0 until December 17, 2025.
- After that, all new audits must follow v9.0.
- The CCSS version number will continue to be listed publicly for each certified system.
Why This Matters
This extension, based on auditor and community feedback, gives organizations:
- Time to align with v9.0
- A clear path for in-progress v8.1 efforts
- Stability during the version transition
With the draft of v9.0 available three months before publication, this updated timeline provides a full year of visibility into the changes.
We appreciate the community’s input in shaping this decision and look forward to continued collaboration as we raise the bar for crypto security.
To learn more or begin a CCSS audit, visit https://cryptoconsortium.org/ccss
