Section C — Application Segments (C.1-C.4)

Section C — Application Segments#

C.0. Introduction#

This section defines the applicability of the Section B requirements (8 domains) to each of the 4 segments of the crypto-asset market. Applicability is expressed by an M / R / N/A matrix (Mandatory / Recommended / Not Applicable) within each Section B domain (see the "Applicability summary table" block at the end of B.1 — B.8) and consolidated in this section.

Segments:

• C.1 — Custodial wallets and custodians
• C.2 — Non-custodial wallets (vendor wallet software)
• C.3 — Crypto exchanges (CEX and DEX front-ends)
• C.4 — Issuers of stablecoins, RWA tokens, fiat tokens

C.1. Custodial wallets and custodians#

C.1.1. Segment definition#

Organizations that hold customer crypto-assets under their own management of private keys. Includes:

• Centralized exchange wallets (custody-side)
• Dedicated custodians (Coinbase Custody, Anchorage, BitGo, Fireblocks Vault and the like)
• Bank crypto-wallets operated by digital-financial-asset (DFA) operators
• White-label custody services

C.1.2. Applicability of CCSA domains for C.1#

All 8 domains are Mandatory for C.1. This is the strictest application segment.

C.1.3. Specific per-level requirements for C.1#

---

C.2. Non-custodial wallets#

C.2.1. Segment definition#

Software or devices that provide the user with sole control over private keys:

• Browser extension wallets (MetaMask, Rabby and the like)
• Mobile wallets (Trust Wallet, Phantom and the like)
• Desktop wallets (Electrum, Sparrow and the like)
• Hardware wallets (Ledger, Trezor, Tangem and the like)
• Smart wallet / Account Abstraction wallets

Subject of certification in C.2: the software vendor or hardware manufacturer of the wallet product. The end user is not subject to certification and is not a subject of the audit.

C.2.2. The dual nature of the C.2 scope#

For C.2, the standard's requirements apply in two distinct contexts:

• Vendor scope — requirements on the organization that develops the wallet product (employees, processes, infrastructure within the vendor): includes onboarding, offboarding, SoD, background checks, build infrastructure security, release management.
• Device scope — requirements on the architecture of the wallet software on the end user's device: includes on-device entropy, secure storage in the Secure Enclave / StrongBox, the signing ceremony within the trusted boundary, recovery UX.

Neither of these scopes applies to the end user themselves. The user makes decisions about their own CCM (how often to rotate the seed, whether to use multi-sig) independently; the vendor is obliged to provide mechanisms and documentation, not to enforce policies on the user.

C.2.3. Applicability of CCSA domains for C.2#

C.2.4. Unique requirements for C.2#

Code security:

• Open-source preferred (for community verification and code review)
• Reproducible builds for App Store / Play Store releases
• Code signing with a verified developer identity
• Code obfuscation for proprietary parts (where applicable)

Protection against extraction:

• Anti-tampering measures
• Anti-screenshot protection when displaying the seed phrase in the UI
• Jailbreak / root detection with degraded functionality (for mobile)
• Anti-debugging measures

User education about CCM:

• In-app warnings about seed phrase security
• Anti-phishing measures (transaction simulation, address book with verified contacts)
• Recovery guidance documentation, available without an internet connection

C.2.5. Specific per-level requirements for C.2#

---

C.3. Crypto exchanges (CEX and DEX front-ends)#

C.3.1. Segment definition#

Trading platforms for crypto-assets, with respect to the protection of the CCM of their custody infrastructure:

• Centralized exchanges (CEX) — custody side
• DEX front-ends — management of signing keys for admin functions
• OTC platforms — custody hot / warm / cold

Scope note: segment C.3 covers only the protection of CCM in the exchange infrastructure. Trading engine integrity, market manipulation prevention, order book security, listing standards, fair access — these are business processes and market integrity, outside the scope of CCSA (see Section 0.2.2).

C.3.2. Applicability of CCSA domains for C.3#

All 8 domains are Mandatory for C.3, as for C.1.

C.3.3. Unique requirements for C.3 with respect to CCM#

User wallets (custody-side):

• Session tokens are protected as category D CCM (Section B.1.1)
• Mandatory 2FA for signing operations (Section B.4.3)
• Step-up authentication for high-value operations (Section B.4.3 Level 2+)

Internal operations:

• Withdrawal time-locks (Section B.6.4)
• Address whitelisting for institutional accounts (Section B.6.5)
• Real-time watch-only monitoring of all hot / warm wallets (Section B.7.3)

C.3.4. Specific per-level requirements for C.3#

---

C.4. Issuers of stablecoins, RWA tokens, fiat tokens#

C.4.1. Segment definition#

Organizations that issue tokens on a blockchain, with respect to the protection of the CCM of their issuance infrastructure:

• Stablecoins (USDT, USDC, DAI and the like)
• RWA tokens (real-world asset tokens)
• Fiat tokens (currency-backed tokens)
• Security tokens

Scope note: segment C.4 covers only the protection of mint / burn keys and the associated CCM. Reserve composition policy, audited reserves, Proof of Reserves, governance processes, regulatory disclosure, token holders' rights — these are finance, governance, and regulatory compliance domains, outside the scope of CCSA (see Section 0.2.2).

C.4.2. Applicability of CCSA domains for C.4#

C.4.3. Unique requirements for C.4 with respect to CCM#

Mint / burn key protection:

• Multi-sig is mandatory for mint / burn (Section B.6.1) — Mandatory regardless of market cap
• Watch-only monitoring of all mint events (Section B.6.2)
• Time-lock on mint > threshold (Section B.6.4)
• Compromise detection for unauthorized mint events (Section B.7.3)

What CCSA does not cover for issuers:

• Reserve composition policy and audited reserves — a separate compliance domain
• Token holders' rights, redemption procedures — corporate governance
• Smart contract audit (the issuance contract) — code security, a separate domain
• Regulatory disclosure — regulatory compliance

C.4.4. Specific per-level requirements for C.4#

---

C.5. Cross-segment rules#

C.5.1. Multi-segment organizations#

If an organization operates in several segments simultaneously (for example, exchange + custodian + issuer), the requirements of all applicable segments apply:

• Compliance with the union of all Mandatory requirements
• Common infrastructure requirements are verified once
• A single ROC with a breakdown by segment

C.5.2. Sub-organizational segments#

If different business units within a single organization operate in different segments, per-segment certification is possible:

• Each business unit may have its own Level and AOC
• Common CCM infrastructure requirements are verified once
• Segregated reporting per segment

Rule for determining the overall entity level. If the organization is certified as a single entity (not per-segment), and the different segments yield different levels (for example, for C.1 the level is determined as L2 by AUM, while for C.3 the level is L3 by daily volume), then the overall entity level = max(per-segment levels). This also applies to different metrics within a single segment (AUM vs transaction volume): the strictest level is taken. If per-segment certification is chosen (the sub-organization route), each business unit is documented with its own level separately.

C.5.3. Applicability of carry-over in a multi-segment context#

Where baseline certificates are present (see Section A), carry-over applies per requirement, not per segment. The same baseline (for example, PCI DSS Level 1) may cover the same common-infrastructure requirements (B.4.4 Privileged Access, B.7.1 Logging) for all of the organization's segments simultaneously.

C.5.4. Critical Requirements in a multi-segment context#

For all 8 Critical Requirements (B.1.1, B.1.2, B.2.1, B.3.1, B.4.1, B.5.2, B.7.3, B.8.1 — see Section D.2.5), carry-over does not apply in any segment (per Section A.0.3). A multi-segment organization must undergo a full CCSA assessment of the Critical Requirements through Defined Approach Testing Procedures for each segment in scope. The Customized Approach for Critical Requirements is prohibited (Section 0.7.2); a Compensating Control for the four fully-forbidden Critical Requirements (B.1.1, B.1.2, B.5.2, B.7.3) is prohibited entirely (Section 0.8.2); for the remaining four (B.2.1, B.3.1, B.4.1, B.8.1) it is permitted only at Level 1 with Council approval (Section 0.8.3).

Related#

• 10 — B.8 — Personnel and Access Control — the previous Section B domain
• 12 — Section D — Certification Levels — the next section

Sources#

See Section 0.4 Normative References in the Front Matter.