B.5 — Lifecycle Management

Domain B.5 — Lifecycle Management#

B.5.0. Overview#

This domain establishes requirements for the rotation, revocation, recovery, and secure disposal of Critical Cryptographic Material. These are the temporal aspects of CCM protection — what happens to the material over time.

Conceptually related PCI DSS v4.0.1 requirements: Requirement 3.6.4 (Key Rotation), Requirement 3.7 (Key Destruction), Requirement 12.10 (Incident Response, Business Continuity Planning).

---

B.5.1 — Rotation#

Defined Approach Requirement#

CCM must be subject to periodic scheduled rotation in accordance with the cadence table below, differentiated by CCM category and certification level, and to triggered rotation upon the occurrence of events from the list. Each rotation is documented in the CCM Inventory change log (see Section B.1.4), specifying the cause, ceremony reference (for categories A, B, C), cutover date, and confirmation of disposal of the previous material.

Scheduled rotation cadence#

Triggered rotation#

Triggered rotation is mandatory upon the occurrence of any of the following events:

• Termination or role change of a keyholder with access to material — rotation of the affected keys within 24 hours (L1), 4 hours (L2), 1 hour (L3) from the offboarding event
• Suspicion of compromise (even without confirmation)
• Change of the MPC threshold scheme or multi-sig participants
• Vendor security incident (a known vulnerability in an HSM, library, or MPC protocol implementation applicable to the given Assessed Entity)
• Expiration of a valid SKZI certificate (for Russian clients)
• Expiration of vendor support periods for the HSM or MPC product
• Material change in the Applicability Notes of requirement B.5.1 in a new version of the standard

Rotation procedure#

1. Pre-rotation validation of the old key's operability (defensive check that rotation does not block existing operations)
2. Generation of new CCM per the requirements of Section B.2 (with a full ceremony for categories A, B, and C cold storage)
3. Verification of the new CCM per Section B.2.4
4. Transition period (for hot and warm tier only):
   • The old key remains active for a maximum of 24 hours after deployment of the new key
   • Both keys are subject to watch-only monitoring (Section B.7.3)
   • Signing operations with the old key after the end of the transition period must be flagged as an anomaly (Section B.7.2)
   • The switching workflow requires multi-person approval (Section B.4.2)
5. Cutover to production
6. Safe disposal of the old CCM per Section B.5.4

For the cold storage tier, a transition period is not permitted — only atomic cutover (the old key is disabled at the same moment the new one is activated in the ceremony).

Applicability Notes#

• Mandatory for all segments and levels.
• Cold storage rotation of 36 months for L1 is permissible provided all of the following conditions are simultaneously met:
  • Cold storage is operationally air-gapped (see Section B.2.2, level L2+ environment isolation)
  • All cold addresses use multi-sig with a threshold no lower than 2-of-3 (see Section B.6.1)
  • There is no ad-hoc access to cold storage between scheduled ceremonies
  • All attempts to access cold storage are logged (see Section B.7.1)
  • Documented risk acceptance approved by the Chief Security Officer of the Assessed Entity
  • If at least one condition is not met, cold storage rotation must be performed at least annually.
• For C.2 (non-custodial wallets), the rotation requirement is reformulated: the vendor must provide the user with a UI and documentation for self-service rotation of the seed phrase when necessary (for example, before selling a device). The vendor has no right to forcibly rotate a user's keys.

Customized Approach Objective#

No CCM remains in production longer than the period during which the exposure window becomes incompatible with the protection of the corresponding crypto-assets; compromise of a key at time T cannot be exploited by an attacker at time T + rotation_period; a change of keyholder or changes in infrastructure are accompanied by rotation of the affected CCM before the exposure window expires.

Defined Approach Testing Procedures#

• B.5.1.a Examine rotation policy and records:

  • Obtain the documented rotation policy with cadence for each applicable CCM category.
  • Verify that the cadence corresponds to table B.5.1 for the applicable level; for cold storage of 36 months at L1, verify the presence of a risk acceptance document and compliance with all conditions of the Applicability Note.
  • Obtain the rotation event log for the last 24 months (or since the previous audit).
  • For each scheduled rotation in the table, verify that the event occurred within the expected window (with a tolerance no greater than 10% of the cadence).
  • Obtain triggered rotation events: for each triggering event in the period (offboarding, suspected compromise), verify that the rotation took place within the required SLA.

• B.5.1.b Interview rotation owner:

  • Interview the person responsible for the rotation policy and one of the keyholders who participated in the most recent rotation.
  • Questions:
    • "Describe the rotation cadence for cold storage. Why exactly this periodicity?"
    • "Describe the most recent triggered rotation. What prompted it?"
    • "What happens if a scheduled rotation is postponed due to operational constraints?"
    • "What deviations from the documented procedure have occurred in the last 12 months?"
    • "How is it ensured that the transition period does not exceed 24 hours for hot/warm?"

• B.5.1.c Observe rotation event:

  • If a rotation is scheduled at the time of the audit, observe it as an observer.
  • If not, request a demonstration of the rotation procedure on a test environment with a test key.
  • Verify conformity to the documented procedure, the presence of all required participants, and audit log generation.

• B.5.1.d Trace a specific rotation:

  • Select one rotation from the last 12 months (preferably a cold storage ceremony).
  • Trace: trigger event (scheduled or triggered) -> pre-rotation validation log -> new CCM generation ceremony record -> verification record (Section B.2.4) -> transition period log -> cutover event -> old CCM disposal record (Section B.5.4).
  • Any missing link is a finding.

Purpose#

Rotation limits the exposure window for a compromised key. If an attacker gained access to CCM at time T (for example, through a side-channel in an HSM vendor discovered later upon public disclosure), rotation at time T + period renders the compromised material useless. Differentiating the cadence by category reflects the differing value at risk and the differing operational cost of rotation: hot wallet rotation is automated, while cold storage rotation is a multi-day ceremony. Triggered rotations ensure that significant events (termination, incident) do not leave a key in a compromised state until the next scheduled rotation.

Good Practice#

• Use envelope encryption (Section B.3.2) for efficient MEK rotation without re-encrypting the entire CCM dataset.
• Include an explicit "defensive rotation" component in the rotation policy: an additional rotation after ambiguous events, even if the threshold for triggered rotation is not reached.
• Document post-rotation reconciliation: verification that all derived systems (watch-only monitoring, accounting, backups) have switched to the new key.

Examples#

• AWS KMS automatic key rotation of 365 days for category E (API keys).
• HashiCorp Vault transit secrets engine with automatic key versioning and a configurable rotation period.
• Custom ceremony procedure for cold storage with annual rotation for L2/L3 and triennial for L1 with mandatory risk acceptance.

Mapping to baseline standards#

• PCI DSS Requirement 3.6.4 (Key Rotation): Full carry-over. PCI DSS requires rotation "at least annually" — CCSA is in most cases stricter than or equal.
• CCSS v8.0 Domain 6 (Key Rotation): Full.
• GOST R 57580.1: Partial.

---

B.5.2 — Revocation#

Defined Approach Requirement#

Upon the occurrence of a confirmed or suspected compromise event for CCM, there must be the capability for immediate revocation of the compromised material. The revocation procedure for each CCM category must be documented, available 24/7, and have valid SLAs for execution time, differentiated by event type.

This requirement is a Critical Requirement (see Section D.2.5). The Customized Approach and Compensating Controls are not permitted for B.5.2.

Revocation SLA#

Revocation mechanisms#

• For blockchain keys (categories A, B, C):

  • Initiate emergency transfer of funds to pre-prepared backup addresses
  • Old addresses are flagged in internal systems as "do not use"; watch-only monitoring continues to detect use-after-revoke attempts by the adversary
  • Public communication (if applicable, depending on impact)

• For session tokens (category D):

  • Invalidation in the session store (Redis, database, JWT blacklist)
  • Force re-authentication for affected users
  • Optional: notification of users about mandatory re-authentication

• For API keys (category E):

  • Disable in the API gateway or identity provider
  • Logging of all subsequent attempts to use the revoked key
  • Notification of subscribers who used the key

• For recovery materials (category F):

  • Regeneration of recovery archives with new encryption
  • Old recovery archives are flagged as invalid
  • Disposal per Section B.5.4

Technical requirements#

• Documented revocation playbook for each CCM category
• 24/7 ability to execute revocation: on-call engineers with privileges and hardware tokens, without a single point of failure (a minimum of 2 keyholders have access to an initiator privileged session at any moment)
• Communication template for customer notification (if applicable)
• Integration with monitoring (Section B.7) for automated triggers where possible

Applicability Notes#

• Mandatory for all segments and levels.
• Critical Requirement: the Customized Approach and Compensating Controls are not permitted.
• For C.2, reformulated: the vendor must provide the user with documentation and a UI for self-service revocation of the seed phrase (through generation of a new seed and transfer of funds) upon suspicion of compromise.

Customized Approach Objective#

Not Applicable. B.5.2 is a Critical Requirement (Section D.2.5). The Customized Approach is not permitted (Section 0.7.2). Compensating Controls are fully forbidden (Section 0.8.2 — fully-forbidden CC). Compliance is achieved exclusively through the Defined Approach.

Defined Approach Testing Procedures#

• B.5.2.a Examine revocation playbook:

  • Obtain the documented revocation playbook for each CCM category.
  • Verify the presence of an SLA for each scenario, corresponding to table B.5.2.
  • Verify documentation of the technical revocation mechanisms for each category.
  • Obtain the on-call rotation schedule and verify that 24/7 coverage is ensured.
  • Obtain the privileged access procedures for revocation (Section B.4.4) and verify that they operate in emergency-grade mode (without a lengthy approval bottleneck).

• B.5.2.b Interview incident response lead:

  • Interview the person responsible for incident response.
  • Questions:
    • "Describe the most recent revocation (actual or drill). What SLA was achieved?"
    • "Who has the 24/7 ability to execute revocation? What credentials do they hold?"
    • "What happens if the first on-call engineer is unavailable?"
    • "Describe the interaction between the revocation procedure and customer communications."

• B.5.2.c Observe revocation drill:

  • Request the conduct of a revocation drill on a test environment.
  • Drill scenario: simulated compromise of a hot wallet of category A.
  • Measure the actual response time from detection to completed revocation; compare with the SLA.
  • Verify that all stakeholders are notified, an audit log is generated, and communication templates are applied correctly.

• B.5.2.d Trace an actual revocation or drill:

  • Select one revocation event (real or drill) from the last 12 months.
  • Trace: detection event -> notification chain -> approval initiation -> execution actions per mechanism category -> verification successful -> post-event analysis.
  • Verify that each link is chronologically consistent; verify that the SLA was achieved.

Purpose#

Revocation is the only defense against the continuation of a compromise after its detection. Without the ability to revoke, detection of a compromise remains theoretical — even if the organization knows a key is compromised, it cannot remedy the situation. The SLA constraints reflect the realities of crypto-infrastructure: transactions on a blockchain are final within 10–30 minutes, and a mixer moves funds within hours. The procedure must work as fast as the compromise can possibly turn into real financial damage.

Good Practice#

• Pre-prepared backup addresses for emergency transfer; they are generated in advance during a ceremony and stored separately from the primary ones.
• Automated revocation triggers for certain scenarios (for example, automatic session revocation upon detection of a geographic anomaly).
• Communication templates in several languages for public-facing communications.

Examples#

• Fireblocks Vault with an emergency freeze workflow available within seconds.
• AWS IAM Access Analyzer + custom Lambda automation for immediate API key revocation upon detection of exposed credentials.
• Pre-deployed multi-sig migration contracts on Ethereum for emergency transfer of custody balances.

Mapping to baseline standards#

B.5.2 is a Critical Requirement (Section D.2.5). Carry-over does not apply (Section A.0.3). Compensating Controls are fully forbidden (Section 0.8.2). The mapping below is reference material only.

• PCI DSS Requirement 12.10 (Incident Response): conceptually close; PCI DSS requires a documented incident response procedure; CCSA specifies an SLA for CCM revocation.
• CCSS v8.0 Domain 5 (Key Compromise Policy): conceptually close.

---

B.5.3 — Recovery#

Defined Approach Requirement#

For critical CCM (categories A, B, C, F) there must be documented and tested recovery procedures for loss of access to the material. Recovery must comply with the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) established for the applicable level. An annual drill (for L2) or quarterly tabletops with an annual full drill (for L3) are mandatory.

Recovery scenarios#

The procedure must cover the following scenarios:

1. Loss of a single MPC share or multi-sig key when k-1 of the threshold is present
2. Loss of keyholder access (termination, unavailability, incapacity, death) — replacement keyholder process
3. Loss of an HSM (vendor failure, physical destruction) — restoration from HSM backup
4. Loss of a cold storage seed — recovery from geographically distributed backup
5. Hardware wallet failure — recovery via seed phrase
6. Loss of the recovery materials themselves — backup of backup

Recovery targets#

RPO/RTO refer to recovery of CCM operations, not the entire system.

Required components#

• Documented step-by-step procedure for each scenario
• Designated recovery participants with backup participants (in case the primary is unavailable)
• Pre-positioned recovery materials in safe but accessible locations
• Verification steps that recovery is successful (applying the Section B.2.4 verification procedures)
• Communication templates for customers, partners, regulators (if applicable)

Mandatory drills#

• L1: Annual tabletop exercise; one full drill every 2 years recommended
• L2: Annual full recovery drill + quarterly tabletops
• L3: Quarterly tabletops + 1 full drill per year; post-drill analysis with lessons learned

Documented drill results + lessons learned update the recovery procedure as necessary.

Applicability Notes#

• Mandatory for C.1, C.3, C.4 at all levels.
• For C.2, applicable as a "seed recovery procedure for end-users" — the vendor must ensure the presence of a UI and documentation for the user to self-recover the seed.

Customized Approach Objective#

The loss of any single component of the CCM infrastructure does not lead to irreversible loss of access to crypto-assets; recovery is possible within a documented timeframe corresponding to the certification level; the recovery procedure has been tested within the last 12 months.

Defined Approach Testing Procedures#

• B.5.3.a Examine recovery plan:

  • Obtain the recovery plan documentation for each scenario.
  • Verify that the plan contains all necessary components (steps, participants, materials location, verification, communication).
  • Obtain drill records for the last 24 months.
  • Verify that the drill cadence corresponds to the level's requirements.

• B.5.3.b Interview recovery participants:

  • Interview at least one recovery participant and one backup participant.
  • Questions:
    • "Describe exactly how you would gain access to the pre-positioned recovery materials in an emergency."
    • "When was recovery last tested? What was the result?"
    • "What happens if the pre-positioned materials turned out to be unavailable or damaged?"
    • "What is your recovery role, and who is the backup person for that role?"

• B.5.3.c Observe mock recovery:

  • Request a mock recovery exercise on a test environment with test material.
  • Verify that the procedure correctly follows the documented steps; the replacement keyholder process works; verification is successful; the RTO SLA is achieved in the test scenario.

• B.5.3.d Trace recovery materials accessibility:

  • Verify that the recovery materials are physically accessible to authorized participants (in a secure but not inaccessible manner):
    • For L1: physical inspection (if applicable) of one backup location; verify chain of custody documentation
    • For L2: verification of 2+ jurisdictions with a separation of ≥ 100 km
    • For L3: verification of 3+ jurisdictions with organizational diversity

Purpose#

Recovery is the balance between confidentiality (CCM is protected from unauthorized access) and availability (CCM can be recovered in a crisis). Confidentiality that is too strict (for example, a single copy in a bank deposit box to which a keyholder loses access) leads to total loss. Recovery that is too relaxed (for example, unprotected backups) turns the recovery infrastructure into an attack surface. A documented procedure with drill testing ensures that recovery works in practice and not only on paper.

Good Practice#

• Use Shamir's Secret Sharing with m-of-n shares in different physical locations and jurisdictions.
• Apply "social recovery" via trusted contacts for category F.
• Regularly verify the physical accessibility of recovery materials (annual physical inspection of cold storage backups).

Examples#

• BitGo Backup Key Service with recovery key shares in 2+ jurisdictions.
• Coldcard MicroSD seed backups with Shamir's Secret Sharing distribution among verified trusted contacts.
• Coinbase Lost Vault Recovery with multi-stage verification and regulatory notification.

Mapping to baseline standards#

• PCI DSS Requirement 12.10 (Business Continuity): Partial.
• CCSS v8.0 Domain 5: Full.

---

B.5.4 — Disposal#

Defined Approach Requirement#

When CCM is taken out of service (after rotation, revocation, or system decommission), a documented secure destruction procedure must be performed. The disposal procedure is differentiated by storage type; it ensures the irrecoverability of CCM after disposal; it is accompanied by an audit log and retention of disposal records.

Disposal by storage type#

Software-stored CCM (encrypted vault, encrypted database):

• Cryptographic erasure: deletion of the encryption key that encrypts this CCM (resulting in the unrecoverability of the cipher-text)
• Overwrite with verification (multiple passes for magnetic storage; not required for SSD when cryptographic erasure is used)
• Removal from all backups, including offsite backups (with a timeline per the backup retention policy)
• Audit log of disposal events

HSM-stored keys:

• HSM zeroization command for the specific key handle
• Verification via the HSM audit log
• Documentation of the operation with timestamps and operator identification

Hardware decommissioning (an HSM is taken out of service):

• Full HSM zeroization (factory reset)
• Physical destruction for L3 if the HSM contained master keys
• Certified disposal vendor for regulated hardware with chain-of-custody documentation

MPC shares disposal:

• Coordinated destruction of all shares at every storage location
• Verification via audit logs from all keyholders
• Documentation of the destruction of each share

Mobile wallets (for C.2):

• The vendor must provide remote wipe capability upon loss of a device (if architecturally possible)
• Customer education via documentation about the need to factory reset the device before sale

Required documentation#

• Disposal certificate for each destroyed CCM, specifying: disposal method, date, executor, witness (for L3)
• Retention of disposal records — a minimum of 7 years (corresponding to Section D.6.2)
• Independent verification (forensic check per B.5.4 Testing Procedure) for category A at L3

Applicability Notes#

• Mandatory for all segments and levels.
• For C.2, reformulated: the vendor provides mechanisms (UI and documentation) for the user and does not perform disposal itself.

Customized Approach Objective#

After disposal, recovery of CCM is impossible even with physical access to the storage media; disposal events are auditable; denial of the fact of disposal is impossible (non-repudiation).

Defined Approach Testing Procedures#

• B.5.4.a Examine disposal policy and records:

  • Obtain the disposal policy with procedures for each storage type.
  • Obtain disposal records for the last 24 months.
  • Verify that each disposal event has a certificate specifying the method, date, and executor.
  • Verify retention of records per policy (a minimum of 7 years).

• B.5.4.b Interview disposal procedure owner:

  • Interview the person responsible for the disposal procedure.
  • Questions:
    • "Describe the most recent disposal event. What was the method?"
    • "How is the impossibility of recovery after cryptographic erasure ensured for software CCM?"
    • "For HSM decommissioning — who performs the physical destruction and how is it verified?"
    • "Which backups are affected during disposal and how is their sync ensured?"

• B.5.4.c Observe disposal event:

  • If a disposal is scheduled at the time of the audit, observe it as an observer.
  • If not, request a demonstration of the disposal procedure on test material.
  • Verify conformity to the documented procedure and the correctness of audit logging.

• B.5.4.d Forensic check (L3):

  • For L3, request a recovery attempt after disposal on a test environment.
  • Expected result: recovery is impossible; cipher-text without the MEK is unreadable; the HSM partition is zeroized; physical media (if destroyed) is physically destroyed.
  • Any successful recovery after disposal is a critical finding.

Purpose#

Disposal is the closing of the CCM lifecycle. Without formal disposal, a compromised or rotated key remains in backups, archived storage, and legacy systems and can be recovered by an adversary later. Cryptographic erasure (deletion of the encryption key) is the only practical way to irreversibly destroy encrypted data without requiring physical destruction of the media. Physical destruction for L3 is an additional layer of protection against advanced persistent threats and for regulatory compliance in strict jurisdictions.

Good Practice#

• Use DBAN-style overwrite for magnetic storage only in the absence of cryptographic erasure (legacy systems).
• For an HSM with FIPS 140-3 Level 4, physical destruction is mandatory before the disposal vendor.
• Document the chain of custody from decommissioning to destruction in a certified facility.

Examples#

• AWS KMS DeleteKey API with a waiting period of 7-30 days for cryptographic erasure.
• Iron Mountain Secure Destruction service for physical HSM disposal with a certificate.
• Custom workflow for multi-party coordination of MPC shares disposal.

Mapping to baseline standards#

• PCI DSS Requirement 3.7 (Key Destruction): Full.
• CCSS v8.0 Domain 8 (Data Sanitization Policy): Full.
• GOST R 57580.1 (PUI): Full.

---

B.5.X. Summary applicability table#

Legend: M = Mandatory, R = Recommended, N/A = Not Applicable. (Critical) = Critical Requirement (Section D.2.5); Customized Approach Not Applicable; CC fully forbidden.

Related#

• 06 — B.4 — Usage of Cryptographic Material — previous
• 08 — B.6 — Wallet Architecture for CCM — next
• 03 — B.1 — Cryptographic Material Inventory and Classification — change log in B.1.4

Sources#

See Section 0.4 Normative References in the Front Matter.

Conceptually related PCI DSS v4.0.1 requirements:

• Requirement 3.6.4 (Key Rotation) — Full carry-over
• Requirement 3.7 (Key Destruction) — Full carry-over
• Requirement 12.10 (Incident Response, Business Continuity) — Partial carry-over

Conceptually related requirements of other standards:

• CCSS v8.0 Domain 5 (Key Compromise Policy)
• CCSS v8.0 Domain 6 (Key Rotation)
• CCSS v8.0 Domain 8 (Data Sanitization Policy)
• GOST R 57580.1 (UZP, PUI)
• NIST SP 800-57 Part 1 (Key Management Lifecycle)