§ 1Audit Objective
Primary Audit Objective
Determine whether the Key Management operational resilience program is designed and operating effectively to maintain continuous and correctly distributed cryptographic authority over all on-chain operations — ensuring that quorum can be reconstituted within the 2-hour RTO and that a compromised key can be revoked within the 1-hour execution ceiling — under any foreseeable disruption scenario, and that these capabilities meet the requirements of OCC NPR § 15.14, GENIUS Act § 9, and applicable NIST SP 800-57 standards.
The audit examines the full key management lifecycle: signer onboarding and vetting, HSM/MPC provisioning and ceremony controls, transaction authorization role segregation, 90-day key rotation compliance, emergency revocation playbook, backup signer pre-provisioning, and annual succession drill evidence. The on-chain threshold configuration is independently verified as part of this program — not assumed from policy documents alone.
§ 2Scope & Regulatory Anchor
| Framework | Provision | Relevance to Key Management OR |
|---|---|---|
| OCC NPR | § 15.14 | Robust key management policies — generation, storage, distribution, rotation, revocation, and documented recovery procedures for all cryptographic keys controlling stablecoin operations |
| GENIUS Act | § 9 | Technical controls sufficient to maintain operational continuity of on-chain governance and minting/burning functions at all times |
| GENIUS Act | § 113 | Reportable incident notification — key compromise or quorum failure that disrupts on-chain operations is an assessable reportable incident |
| NIST SP 800-57 | Parts 1–3 | Key lifecycle management standards — cryptoperiods, key storage requirements, key ceremony procedures, and revocation protocols |
| NIST SP 800-175B | §§ 4–6 | Guideline for using cryptographic standards in federal systems — applicable FIPS 140-2 Level 3 HSM certification requirements |
| FFIEC IS Handbook | Key Management Chapter | Financial institution key management governance, dual control ceremonies, and key custodian accountability requirements |
§ 3Risk Assessment — Inherent Risk Rating
Inherent risk ratings below reflect the risk exposure before any mitigating controls. Key management carries a uniquely asymmetric inherent risk profile: likelihood of compromise is low, but impact is existential — a compromised signing key can authorize fraudulent on-chain operations affecting all token holders simultaneously.
| Risk ID | Risk Statement | Inherent Likelihood | Inherent Impact | Inherent Risk Rating | Testing Priority |
|---|---|---|---|---|---|
| KM-R01 | Signer unavailability causing quorum failure | MEDIUM | CRITICAL | CRITICAL | PRIORITY 1 |
| KM-R02 | HSM/MPC key compromise via theft, malware, or physical breach | LOW | CRITICAL | HIGH | PRIORITY 2 |
| KM-R03 | Signer collusion enabling unauthorized on-chain operations | LOW | CRITICAL | HIGH | PRIORITY 2 |
| KM-R04 | Social engineering or phishing attack targeting a signer | MEDIUM | CRITICAL | CRITICAL | PRIORITY 1 |
| KM-R05 | On-chain threshold misconfiguration diverging from policy | LOW | CRITICAL | HIGH | PRIORITY 2 |
| KM-R06 | Key rotation failure leaving stale or over-privileged access | MEDIUM | HIGH | HIGH | PRIORITY 2 |
| KM-R07 | HSM/MPC vendor failure or firmware vulnerability | LOW | HIGH | HIGH | PRIORITY 2 |
| KM-R08 | Jurisdictional signer concentration creating legal seizure risk | LOW | HIGH | MEDIUM | PRIORITY 3 |
| KM-R09 | Proposer-approver role conflation enabling unilateral governance | LOW | CRITICAL | HIGH | PRIORITY 2 |
Auditor note — asymmetric risk profile: Key management carries two Critical inherent risk ratings (KM-R01 quorum failure; KM-R04 social engineering), both from scenarios with medium likelihood. Unlike banking or contract risks, key management failures can be silent — a compromised key may not generate an observable alert before unauthorized transactions are submitted. This drives the emphasis on on-chain threshold independent verification and the on-chain transaction log sampling procedures in § 5.
§ 4Control Design Assessment
For each control, assess whether it is capable of preventing or detecting the target risk as designed. A control is adequately designed if, when operating as described, it would reduce the risk to an acceptable residual level. Policy existence alone is insufficient — the auditor must verify the policy is operationalized through enforceable procedures, system configurations, or technical controls.
| Control ID | Control Name | Design Assessment Procedures | Design Adequacy Question |
|---|---|---|---|
| KM-C01 | Geographic & Organizational Signer Diversity Mandate | Obtain written signer diversity policy. Confirm policy specifies minimum 5 active signers across minimum 3 geographic jurisdictions and minimum 3 organizational units. Verify policy prohibits majority concentration in any single jurisdiction. Inspect current approved signer roster — confirm it meets diversity requirements as documented. Review process for monitoring roster changes against diversity thresholds. | Does the diversity policy, as designed, prevent a single legal action, geographic event, or organizational incident from simultaneously incapacitating enough signers to break quorum? |
| KM-C02 | HSM/MPC Hardware-Enforced Key Isolation | Obtain HSM/MPC device specification and FIPS 140-2 Level 3 certification documentation. Review key ceremony procedures — confirm private key material is generated inside the HSM boundary, never in software. Verify MPC key share encryption at rest and in transit procedures. Inspect vendor diversity policy — confirm primary and backup signers do not use HSMs from the same vendor. Review physical security procedures for HSM storage. | Is the HSM/MPC configuration designed so that private key material cannot be extracted from the hardware boundary by any internal or external actor — including an authorized signer? |
| KM-C03 | Role Segregation — Proposer / Approver / Executor | Review governance portal access control configuration. Confirm technical enforcement that: (a) the proposer of a transaction cannot be a required approver; (b) no individual holds both proposer and executor roles simultaneously. Inspect role assignment matrix. Confirm alert or block is triggered if role segregation violation is attempted. Review periodic access review procedure for role assignments. | Is role segregation technically enforced — not just a policy requirement — such that a single compromised individual cannot both initiate and approve an unauthorized on-chain transaction? |
| KM-C04 | On-Chain Threshold Verification | Obtain the approved threshold configuration record (e.g., 3-of-5 for standard operations, 5-of-8 for treasury operations). Perform an independent query of the on-chain multisig contract state to retrieve the current configured threshold. Compare on-chain threshold to approved policy document. Inspect Independent Verifier sign-off records from most recent ceremony. Verify threshold is enforced by contract logic, not by off-chain procedure alone. | Does the on-chain threshold match the approved policy threshold, and is it enforced by the smart contract such that it cannot be bypassed by any individual or off-chain action? |
| KM-C05 | Mandatory Key Rotation (90-Day Maximum) | Review key rotation policy — confirm maximum 90-day rotation schedule is documented. Inspect system alert configuration for Day 75 reminder and Day 91 compliance alert. Review rotation log for audit period — confirm all keys were rotated within 90-day schedule. Inspect dual-witness attestation records for each rotation ceremony. Verify post-rotation independent verification of on-chain threshold state is documented. | Is the 90-day rotation policy operationalized through a system-enforced reminder and compliance alert — not reliant on manual calendar tracking — and does it trigger automatic escalation at Day 91? |
| KM-C06 | Emergency Revocation Playbook with Tested RTO | Obtain written Emergency Revocation Playbook. Verify playbook specifies: compromised signer (1-hour revocation ceiling), unavailable signer (2-hour RTO for quorum reconstitution), quorum failure (transaction hold + Board emergency session). Inspect pre-provisioned pause/revocation credentials. Confirm playbook was tested against the 2-hour RTO ceiling — inspect test results and elapsed time documentation. | Is the playbook designed with sufficient procedural and technical specificity that a Security Officer could execute a full revocation and quorum reconstitution within 2 hours without requiring decisions that depend on unavailable personnel? |
| KM-C07 | Pre-Provisioned Emergency Backup Signers | Inspect evidence that at least two backup signers per role are Board-approved. Verify backup signers hold pre-provisioned HSM/MPC devices in an activated-dormant state. Confirm device integrity verification procedure and inspection frequency. Verify backup signers can be deployed to active status without new key generation ceremony — inspect activation runbook for elapsed-time estimate. | Are backup signers truly pre-provisioned — not merely identified — such that they can be made operational within the 2-hour RTO ceiling without requiring a key generation ceremony? |
| KM-C08 | Annual Succession Drill with RTO Measurement | Review annual succession drill design — confirm scenario involves simultaneous unavailability of at least two signers. Verify drill is conducted on testnet with actual system activation. Inspect drill report template — confirm it captures elapsed time at each stage vs. 2-hour RTO ceiling. Review whether drill results are presented to the Board and retained for examination. | Is the drill designed to meaningfully test the 2-hour RTO ceiling under realistic multi-signer unavailability conditions, or is it a tabletop discussion that could conceal operational gaps? |
§ 5Control Effectiveness Testing
Key Management effectiveness testing includes a unique on-chain component — the auditor independently queries the live smart contract state to verify threshold configuration, rather than relying solely on management-provided records. This is a required procedure for all on-chain threshold controls.
| Control ID | Test Procedure | Sample / Scope | Evidence Required |
|---|---|---|---|
| KM-C01 | Obtain the current approved signer roster. Map signer locations to geographic jurisdictions. Verify minimum 3 distinct jurisdictions represented. Verify minimum 3 distinct organizational units. Confirm no single jurisdiction holds majority. Obtain roster change log for the audit period — verify every addition was Board-approved before provisioning commenced. | Current roster · full roster change log for audit period | Approved roster document · Board approval records for each addition · geographic diversity mapping |
| KM-C02 | Inspect physical HSM device log for a sample of signers. Confirm FIPS 140-2 Level 3 certification for each device model in use. Review key ceremony attendance records — verify dual-witness attestation for each ceremony in the audit period. Inspect any evidence of attempted key export — confirm no successful key exports occurred outside the HSM boundary. Verify vendor diversity between primary and backup signer devices. | All ceremony records in audit period · physical device inspection for 3 signers | FIPS certificates · ceremony attendance records · export attempt logs · vendor diversity matrix |
| KM-C03 | Select a sample of on-chain governance transactions from the audit period (mints, burns, parameter changes). For each, obtain the governance portal transaction log — verify the proposer is not among the required approvers. Inspect access control matrix and confirm proposer and executor roles are held by different named individuals. Test for any role segregation bypass alerts fired during the period — inspect investigation records. | 20 on-chain governance transactions · full bypass alert log · access control matrix | Transaction logs with proposer/approver identities · access control matrix · bypass alert records |
| KM-C04 ⚠ | On-chain independent verification (required): Auditor independently queries the multisig smart contract state using a public blockchain explorer or direct RPC call. Retrieve the current configured threshold (m) and signer count (n). Compare retrieved on-chain threshold against the policy-approved threshold. Inspect Independent Verifier attestation records from the most recent ceremony. Confirm on-chain threshold has not changed since last verified ceremony without a documented CAB-approved change record. | Live on-chain query (point in time) · all ceremony change records in audit period · Independent Verifier attestations | Auditor-obtained on-chain query result · policy threshold document · Independent Verifier sign-offs · CAB change records |
| KM-C05 | Obtain key rotation log for the audit period. For each key, calculate days since last rotation. Confirm all keys were rotated within 90-day maximum. Identify any keys approaching or exceeding Day 75 (reminder) — verify reminder alerts were triggered. Inspect any Day 91 compliance alerts — verify immediate escalation occurred. Review dual-witness attestation records for each rotation ceremony. | Full rotation log for audit period · all compliance alerts in period | Rotation log with dates · system alert records · dual-witness attestation documents |
| KM-C06 | Inspect the Emergency Revocation Playbook — confirm it was reviewed and signed off within the last 12 months. Obtain the most recent playbook test results. Verify the drill recorded actual elapsed time at each stage. Confirm total elapsed time for quorum reconstitution was within the 2-hour RTO ceiling. If the drill exceeded the ceiling, inspect the remediation actions and re-test evidence. Inspect pre-provisioned revocation credential hardware storage. | Most recent drill report (within 12 months) · playbook version with sign-off date | Drill report with elapsed times · playbook sign-off · revocation credential hardware inspection records |
| KM-C07 | Inspect backup signer roster — confirm minimum two Board-approved backup signers per role. Obtain quarterly backup device integrity verification records — confirm all devices were verified in the audit period. Inspect backup signer activation runbook — verify activation process does not require a new key generation ceremony. Test: ask management to walk through the activation sequence and time the steps against the 2-hour RTO ceiling. | Backup signer roster · all quarterly device checks in period · activation runbook walkthrough | Board approval records for backup signers · device integrity check records · activation runbook |
| KM-C08 | Obtain the most recent annual succession drill report. Confirm drill was conducted on testnet with actual system activation (not tabletop only). Verify drill scenario involved simultaneous unavailability of at least two signers. Inspect elapsed time measurements for each stage against 2-hour RTO ceiling. Confirm drill results were formally presented to the Board. Inspect any gaps identified and verify remediation status. | Most recent annual drill report · Board presentation confirmation | Drill report · testnet activation records · Board meeting minutes confirming drill presentation · gap/remediation log |
§ 6Impact Tolerance Verification
| Service | Impact Tolerance | Verification Procedure | Evidence Required |
|---|---|---|---|
| Signing Ceremony / Quorum Availability | 2 hr RTO | Obtain written management acceptance of 2-hour quorum reconstitution RTO. Verify RTO is documented in the Emergency Revocation Playbook as the target ceiling. Inspect drill results from the most recent annual succession drill — confirm achieved reconstitution time was within 2 hours. If any actual quorum disruption occurred during the audit period, inspect incident records for actual elapsed time vs. RTO ceiling. | Signed RTO acceptance · playbook RTO reference · drill elapsed times · incident records (if any) |
| Emergency Key Revocation | 1 hr CEILING | Obtain written management acceptance of 1-hour revocation execution ceiling. Verify pre-provisioned revocation credentials are in place. Inspect playbook for revocation step-by-step timing — confirm all steps can be completed within 1 hour under the scenario of a compromise discovered during business hours and out of hours. If any actual revocation was executed during the audit period, inspect timestamped records of each revocation step vs. the 1-hour ceiling. | Signed revocation ceiling acceptance · pre-provisioned credential evidence · playbook timing analysis · actual revocation records (if any) |
§ 7Scenario Stress Test Evidence Review
Scenario KM-S01: Compromised or permanently unavailable multisig administrative signer during an active transaction queue. Tests: key revocation within 1-hour ceiling, quorum reconstitution within 2-hour RTO, pending transaction resubmission after revocation, backup signer activation, and GENIUS Act § 113 notification assessment.
| Step | Evidence Review Procedure | Evidence Required |
|---|---|---|
| Documentation Review | Obtain the KM-S01 scenario documentation. Verify the scenario description matches the OR Program (compromised signer + active transaction queue). Confirm the scenario covers both the compromised (revocation) and unavailable (backup activation) variants. Review the six-stage recovery protocol — verify each stage has a defined time target aligned with the impact tolerance ceilings. | Written scenario document · management sign-off · six-stage protocol with time targets |
| Execution Evidence | Confirm the scenario test was executed on testnet within the prior 12 months with actual system activation — not a tabletop simulation. Obtain the execution log — verify it covers all six stages including: incident declaration, revocation execution, transaction queue management, backup signer activation, GENIUS Act § 113 notification assessment, and post-incident rotation initiation. Verify observer sign-off on execution scope and accuracy. | Execution log with timestamps · testnet activation evidence · observer/facilitator sign-off |
| Results vs. Tolerances | Review drill report and verify measured outcomes: (a) was revocation executed within the 1-hour ceiling? (b) was full quorum reconstitution completed within the 2-hour RTO? (c) was the transaction queue held without any transactions submitted to the blockchain during the incident? (d) was § 113 notification assessment completed and documented? Inspect any identified gaps and confirm remediation status. | Drill results report · elapsed time measurements · queue hold evidence · notification assessment record · gap log |
§ 8Exception Escalation Thresholds
| Finding Severity | Threshold Definition | Required Response | Board Notification |
|---|---|---|---|
| CRITICAL | On-chain threshold does not match policy-approved configuration. Any control failure on KM-R01 (quorum failure) or KM-R04 (social engineering) risks. Any key that has not been rotated beyond 90 days without a documented exception. Any unauthorized on-chain transaction executed during the audit period. | Immediate written response within 5 business days. Interim controls within 10 business days. Permanent remediation within 30 business days. | Board notification within 5 business days. Regulator notification assessed under GENIUS Act § 113. |
| HIGH | Role segregation violation detected in governance portal logs. Backup signer devices not verified within required quarterly cycle. Annual drill not conducted within 12 months. Playbook not reviewed and signed off within 12 months. | Written response within 10 business days. Remediation within 45 business days. | Board informed at next scheduled meeting. |
| MEDIUM | Policy documentation gaps. Missing dual-witness attestation for a rotation ceremony. Signer diversity approaching — but not breaching — minimum thresholds. | Written response within 20 business days. Remediation within 90 days. | Included in periodic management report. |
§ 9Regulatory Readiness Sign-off Criteria
Sign-off on the Key Management OR audit is granted only when all criteria below are satisfied. The on-chain threshold independent verification is the one test that cannot be waived — it is the only procedure that provides direct evidence of the control rather than relying on management representation.
Mandatory — Design
- All 8 controls assessed as adequately designed
- On-chain threshold independently verified to match approved policy configuration
- Role segregation confirmed technically enforced in governance portal
- Emergency Revocation Playbook reviewed and signed off within 12 months
- Backup signer pre-provisioning confirmed with zero-ceremony activation capability
Mandatory — Effectiveness
- Zero Critical findings from effectiveness testing
- All keys rotated within 90-day maximum for the full audit period
- No unauthorized on-chain transactions identified in the audit period
- Annual succession drill completed within prior 12 months with elapsed time within 2-hour RTO
- Backup device integrity verified on quarterly schedule throughout audit period
Mandatory — Impact Tolerance
- Written management acceptance of 2-hour quorum RTO and 1-hour revocation ceiling
- Drill results confirm achieved quorum reconstitution within 2-hour ceiling
- No actual key incidents during audit period exceeded ceiling without documented post-incident review
Mandatory — Scenario & Regulatory
- KM-S01 scenario test executed within prior 12 months with documented testnet results
- OCC NPR § 15.14 key management policy requirements confirmed met in writing
- GENIUS Act § 9 / § 113 notification assessment completed for any incidents in audit period
- No open Critical or High findings from this audit at time of sign-off
§ 10Finding Log Template
All findings identified during this audit are recorded below. The on-chain threshold verification result is recorded as its own finding entry — whether a finding or a clean result — to create an explicit, immutable audit record of the independent verification procedure.
| Finding ID | Audit Section | Control / Risk Ref | Finding Description | Severity | Mgmt Response | Remediation Date | Status |
|---|---|---|---|---|---|---|---|
| KM-F-001 | § 5 / KM-C04 | KM-C04 / KM-R05 | On-Chain Threshold Verification Result: [Record auditor-queried on-chain threshold vs. policy threshold — confirmed match or discrepancy] | RECORD | [N/A if clean result — remediation required if discrepancy] | — | VERIFIED |
| KM-F-002 | § [X] | KM-C[X] / KM-R[X] | [Describe finding] | OPEN | [Management response] | [DD/MM/YYYY] | NOT STARTED |
On-chain threshold record: The KM-F-001 entry is a mandatory record in every Key Management OR audit, regardless of outcome. It creates a point-in-time attestation of the auditor's independent verification of the on-chain threshold state. This record is the primary evidence supporting the regulatory readiness sign-off criterion for on-chain threshold verification.