CBDC and Digital Currency Infrastructure

Key Control Areas

• Central Bank Core Ledger Security (SC-12, SC-13, SC-28, AC-05, AU-02): The central bank core ledger is the authoritative record of all CBDC balances and transactions. It is the monetary equivalent of a nation's gold reserve — its integrity is absolute. SC-12 (Cryptographic Key Establishment and Management) is the anchor control: the central bank's signing keys, which authenticate every CBDC issuance and redemption event, must be protected with the highest available assurance. Recommended minimum: FIPS 140-3 Level 4 HSMs for root key storage, with multi-party signing ceremonies requiring physical co-presence of at least three senior central bank officials. No single person should ever have access to the complete signing key. Key custody must be distributed across geographically separate secure facilities, with a tested recovery procedure that has never been used in a real incident. SC-13 (Use of Cryptography) mandates post-quantum cryptographic readiness — CBDC infrastructure commissioned in 2026 will operate for 20-30 years, well within the cryptographically relevant quantum timeline. The NIST PQC standards (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) must be incorporated into the cryptographic architecture from the outset, not retrofitted. SC-28 (Protection of Information at Rest) applies to all ledger data: transaction records, balance snapshots, and audit logs are sensitive both for individual privacy and for monetary policy confidentiality. AC-05 (Separation of Duties) is critical at the central bank operator level: no individual or team should be able to unilaterally issue, redeem, or transfer CBDC without multi-person authorisation. The four-eyes principle must apply to every privileged operation on the core ledger. AU-02 (Auditable Events) must capture a complete, tamper-evident record of every change to the core ledger — issuance, redemption, balance adjustments, configuration changes, and all administrative actions — with the audit log protected against modification even by the system administrators who operate the core ledger.
• Dual-Ledger Architecture and RTGS Interoperability (SC-07, SC-08, CA-07, CM-08, CP-09): CBDC does not replace the existing payment infrastructure — it operates alongside it. The dual-ledger architecture maintains the authoritative CBDC ledger at the central bank while enabling settlement interoperability with the Real-Time Gross Settlement (RTGS) system (TARGET2 in the Eurozone, CHAPS in the UK, Fedwire in the US) for conversion between CBDC and central bank reserves. SC-07 (Boundary Protection) defines the security boundary between the CBDC core ledger and the RTGS system. These are distinct systems with different operational characteristics, security controls, and threat models, connected by a gateway that must enforce strict controls on what can cross the boundary: CBDC-to-reserves conversions require authenticated requests from licensed intermediaries, validated against holding limits and AML rules, with cryptographic binding between the CBDC debit and the reserves credit to ensure atomicity. SC-08 (Transmission Integrity) protects all messaging between the CBDC platform and RTGS. ISO 20022 financial messaging must be transmitted with message-level signing and encryption, using HSM-backed signing keys at the gateway. MitM attacks on RTGS connectivity are a high-priority threat given the systemic value of RTGS flows. CA-07 (Continuous Monitoring) must provide real-time surveillance across both ledgers: total CBDC in circulation must equal total RTGS reserves held as CBDC backing at all times. Any discrepancy — even momentary — is an integrity incident requiring immediate investigation. The monitoring system must operate independently of the systems it monitors, with cryptographic verification of ledger state rather than relying on the ledger system's own reporting. CM-08 (System Component Inventory) must maintain a complete, authoritative inventory of every component in the CBDC-RTGS integration: gateway hardware, network connections, API endpoints, cryptographic materials, and software versions. This inventory is the foundation for the security assessment programme and supply chain risk management. CP-09 (Information System Backup) requires that both the CBDC ledger and the RTGS integration state can be recovered to a known-good point. For monetary infrastructure where the authoritative record of who owns what must never be lost, backup procedures must be tested quarterly with measured RPO and RTO against demanding SLAs.
• Offline Payment Capability and Hardware Security (SC-12, SC-28, PE-03, PE-04, IA-05): Offline CBDC payment — the ability to transact when network connectivity is unavailable — is essential for financial inclusion, resilience, and replication of cash functionality. But offline capability introduces the hardest security problem in CBDC design: how do you prevent double-spending when the central bank ledger cannot be consulted in real-time? The answer requires tamper-resistant hardware. SC-12 (Cryptographic Key Establishment and Management) governs the secure element or TEE (Trusted Execution Environment) wallet architecture for offline CBDC. Each offline wallet contains a device-unique signing key generated and stored within the secure element — it never leaves the hardware boundary. Offline CBDC tokens are cryptographically signed by the central bank and loaded into the secure element via an authenticated protocol. When used for offline payment, the secure element signs a payment message with its device key and simultaneously invalidates the token within its own tamper-resistant storage — the token can only be spent once. SC-28 (Protection of Information at Rest) applies to the offline token store: CBDC tokens held in a device secure element must be protected against extraction even by the device manufacturer, using per-device keys provisioned in a secure hardware manufacturing environment. PE-03 (Physical Access Control) and PE-04 (Access Control for Transmission Medium) apply to the hardware manufacturing and provisioning supply chain — a compromised secure element manufacturing process could produce devices that appear legitimate but contain backdoors. The secure element vendor selection process must include supply chain security assurance, tamper-detection mechanisms, and independent testing against CC EAL5+ or equivalent. IA-05 (Authenticator Management) governs offline wallet authentication — the user's PIN or biometric that authorises spending from the secure element. The PIN must be verified within the secure element, with lockout after failed attempts and tamper-evident reset procedures, to prevent brute-force attacks on extracted device images. Holding limits for offline wallets (typically equivalent to a few hundred units of currency, analogous to the cash you carry in a wallet) are enforced by the secure element hardware and cannot be bypassed by software manipulation.
• Tiered Privacy Model and Privacy-Enhancing Technologies (PT-01, PT-02, PT-03, AC-04, AU-02): CBDC privacy is not a binary choice between surveillance money and anonymous cash — it is a policy design question with profound implications for civil liberties, AML/CFT compliance, and monetary sovereignty. The security architecture must implement whatever privacy tier model the central bank and legislature mandate, without creating technical capabilities that exceed the mandated scope. PT-01 (Policy and Procedures) establishes the governing privacy framework: which transaction types are pseudonymous (small retail payments), which require full KYC identity linking (large transfers, cross-border), and what the data retention and access rules are for each tier. This policy must be formally documented and technically enforced — not just described in policy documents but instantiated in the system's cryptographic architecture so that even the central bank cannot access privacy-tier-1 transaction data without the legally mandated process. PT-02 (Authority to Process Personally Identifiable Information) applies to CBDC transaction metadata. In an account-based CBDC system, every transaction reveals the sender, recipient, amount, and timestamp — a complete financial surveillance apparatus. Even in a token-based system, metadata (device IP addresses, timing patterns, amounts) can enable re-identification. The legal authority to process, retain, and access this data must be explicitly documented for each processing purpose. PT-03 (Personally Identifiable Information Processing Purposes) constrains the use of CBDC transaction data: data collected for AML/CFT purposes cannot be repurposed for tax enforcement or law enforcement surveillance without separate legal authority. Technical controls (data access logging, query auditing, purpose-bound encryption) must enforce these restrictions. Privacy-enhancing technologies for CBDC include: blind signatures (Chaumian e-cash, used in Project Hamilton), which allow the central bank to sign tokens without learning the token-holder's identity; zero-knowledge proofs, which allow users to prove they hold sufficient balance without revealing the balance to the merchant; and threshold decryption, which requires multiple authorities to jointly decrypt transaction data, preventing unilateral surveillance. AC-04 (Information Flow Enforcement) governs which data flows to which parties: central bank AML monitoring systems, commercial bank compliance teams, law enforcement with legal warrants, and cross-border regulators each have different access rights that must be enforced cryptographically. AU-02 (Auditable Events) must log all access to privacy-protected CBDC data with immutable records of who accessed what and why — the access log must be protected even from those who manage the CBDC system.
• Programmable Money and Smart Contract Layer Security (CM-03, SA-11, IA-02, AC-03, IR-04): Programmable money — CBDC with embedded rules that govern how and when it can be spent — enables powerful applications: automated tax collection, conditional welfare payments, corporate treasury automation, and stimulus that expires if unspent. It also creates significant risks: overly restrictive programming could constitute financial censorship or exclusion, bugs in smart contract logic could freeze citizen funds, and malicious programming (from external attackers or insider threats) could enable mass financial manipulation. CM-03 (Configuration Change Control) is the anchor control for programmable money governance: every change to the smart contract logic that governs CBDC behaviour must go through a formal change process with multi-authority approval, mandatory legal review (smart contracts that enforce monetary rules have the force of law), security review, and staged rollout with monitoring. Emergency rollback capability must be available for any deployed programme, with a response time commitment of minutes, not hours. SA-11 (Developer Security Testing) mandates formal verification and independent audit for all CBDC smart contract logic — the stakes are too high for standard software testing alone. For smart contracts that govern citizen access to their own money, the correctness requirement approaches that of safety-critical systems: formal methods (TLA+ for protocol specification, Certora or similar for smart contract verification) must be applied before any production deployment. IA-02 (User Identification and Authentication) governs operator authentication for the programmable money management layer: the ability to create, modify, or deactivate CBDC programmes must require strong multi-factor authentication with hardware tokens, time-limited sessions, and complete audit trails. No programme should be deployable by a single person. AC-03 (Access Enforcement) constrains which parties can create and deploy CBDC programmes: the central bank retains exclusive authority over the base monetary rules; licensed programme operators (government agencies, commercial banks) can create programmes within policy-defined parameters; end users may have no ability to create programmes on their own funds unless explicitly enabled. IR-04 (Incident Handling) must include CBDC programme-specific scenarios: what is the response procedure if a deployed programme is found to have a bug that freezes funds? Who has authority to emergency-pause a programme? How are affected citizens notified? The incident response plan must be rehearsed, as these scenarios could affect millions of citizens simultaneously.
• Anti-Counterfeiting and Double-Spend Prevention (SC-12, SC-13, SC-17, CA-07, AU-03): Counterfeiting CBDC — creating fake currency that the central bank did not issue — would undermine monetary sovereignty and public trust in the digital currency. Double-spending — spending the same CBDC unit twice before the first transaction is confirmed — is the fundamental attack on digital cash, famously solved by Bitcoin's blockchain but addressable by other means in a centralised or quasi-centralised system. SC-12 (Cryptographic Key Establishment and Management) underpins CBDC authenticity: each CBDC token or account balance is cryptographically signed by the central bank's issuance key. Verification of the central bank's signature proves authenticity. The issuance key must be protected with the same rigour as the root CA for a national PKI — its compromise would enable unlimited counterfeiting. SC-13 (Use of Cryptography) mandates specific algorithm requirements: the token signature scheme must be resistant to forgery even with access to signed example tokens, using digital signature algorithms with security level matching the expected value and lifetime of the CBDC (FIPS 204 ML-DSA for quantum-resistant signatures for long-lived infrastructure). SC-17 (Public Key Infrastructure Certificates) governs the CBDC PKI: the central bank root key, intermediary issuance keys, and device-level signing keys form a hierarchy that must be managed with the assurance level of a national PKI, including certificate revocation infrastructure for compromised device keys and key ceremony procedures for root key operations. CA-07 (Continuous Monitoring) must detect double-spend attempts in real-time: for online CBDC, every token redemption is checked against the central bank ledger immediately; for offline CBDC, reconciliation of offline tokens occurs when the device reconnects, with automated detection of any token that has been spent more than once across different offline transactions. When double-spend is detected, the affected tokens are invalidated, the incident is escalated for investigation, and the parties involved are notified per the legal framework. AU-03 (Content of Audit Records) must ensure that every CBDC issuance, transfer, and redemption creates an audit record with sufficient detail to reconstruct the transaction — amount, timestamp, cryptographic reference to the token, and relevant identity attestations — forming the evidentiary basis for any legal proceedings regarding counterfeiting or fraud.
• Monetary Policy and Systemic Risk Controls (AC-06, PM-09, RA-03, CP-07, IR-08): CBDC could cause bank runs at scale if citizens move deposits from commercial banks to the central bank en masse during periods of financial stress — the very safety of CBDC (no counterparty risk) makes it a superior deposit in times of crisis. Preventing this systemic risk while preserving CBDC utility requires architectural controls that implement the central bank's policy choices. AC-06 (Least Privilege) at the macro level means that CBDC holding limits — the maximum amount any individual or entity can hold in CBDC — are enforced by the core ledger as a hard constraint, not a soft policy. Typical proposals range from 3,000-10,000 units of currency per person for retail CBDC. These limits must be enforced even for legitimate commercial bank transfers: a bank cannot move unlimited reserves into CBDC, and the system must prevent automated workarounds (splitting into multiple wallets, round-tripping through intermediaries). PM-09 (Risk Management Strategy) must address CBDC-specific systemic risks in the central bank's enterprise risk framework: the disintermediation scenario (bank deposit flight to CBDC during stress), the operational scenario (CBDC infrastructure outage during a critical payment event), the cyber scenario (attack on CBDC infrastructure coinciding with financial market stress), and the cross-border scenario (sudden capital flows via CBDC that bypass traditional capital flow management mechanisms). RA-03 (Risk Assessment) must quantify the systemic risk parameters: at what CBDC uptake level does disintermediation risk become material? What is the maximum CBDC outflow rate that the banking system can absorb without requiring emergency liquidity intervention? These parameters should be modelled and monitored in real-time, with automated alerts when CBDC flow patterns suggest emerging stress. CP-07 (Alternate Processing Site) recognises that CBDC infrastructure is designated as Critical National Infrastructure: a prolonged CBDC outage during a financial crisis could amplify the crisis. The alternate processing site must be active-active capable (not warm standby) and must be able to assume full CBDC operations within minutes, not hours. IR-08 (Incident Response Plan) for CBDC must include scenarios that no commercial organisation faces: coordinated attacks timed to coincide with market stress events, cross-border attacks using foreign CBDC infrastructure as a vector, and insider threats from staff with access to monetary policy-sensitive systems.

When to Use

Central banks in the design, prototyping, or pilot phase of a retail or wholesale CBDC. Commercial banks designated as CBDC intermediaries by their central bank. Payment infrastructure operators building CBDC wallet or distribution platforms. Technology vendors contracted to build CBDC core ledger, gateway, or offline wallet infrastructure. National payment system operators integrating CBDC with existing RTGS or fast payment infrastructure. Central bank technology consultancies advising on CBDC security architecture. Financial stability regulators assessing systemic risk implications of CBDC design choices.

When NOT to Use

Private sector stablecoins (USDC, EURC) — these are commercial instruments with different threat models; see SP-051 Tokenised Asset Security Architecture. Central bank wholesale settlement using existing RTGS infrastructure without a new CBDC ledger. Payment card security for traditional card-present or card-not-present transactions — see SP-026 PCI Full Environment. Digital identity infrastructure that does not specifically handle monetary value — see SP-052 Decentralised Identity. Cryptocurrency exchange or custody operations — see SP-051 Tokenised Asset Security Architecture.

Typical Challenges

The governance challenge is the hardest: CBDC decisions involve central banks, treasury ministries, data protection authorities, financial regulators, and legislatures — each with different risk tolerances and policy objectives. Security architecture decisions (privacy tier boundaries, holding limits, offline capabilities) require political decisions that no technology team can make unilaterally. The security architect's role is to present the technical implications of each policy choice clearly enough that decision-makers understand what they are approving. Offline CBDC represents an unsolved engineering problem for high-value use cases. Secure element hardware provides strong double-spend prevention but at the cost of complexity, device cost, and failure scenarios (lost device = lost funds). Software-based offline wallets offer usability but require periodic online reconciliation and cannot provide the same cryptographic guarantees as hardware. Privacy-enhancing technologies (blind signatures, ZKPs) are computationally expensive and may not scale to national retail payment volumes without significant infrastructure investment. The tension between AML/CFT compliance (which requires transaction traceability) and privacy (which requires unlinkability) cannot be fully resolved — the legal framework must establish where the line is drawn, and the technology must enforce it without creating technical capabilities that exceed the legal mandate. Interoperability between CBDCs across jurisdictions (mBridge, Nexus, Icebreaker experiments) introduces cross-border trust issues: whose rules govern a payment that originates in one CBDC system and settles in another? Supply chain risk for CBDC hardware (secure elements, HSMs) is acute — state-sponsored supply chain attacks on components that protect national monetary infrastructure are a credible threat. Nation-states with advanced semiconductor capabilities could potentially compromise hardware at the manufacturing level.

Threat Resistance

This pattern provides layered defences across the CBDC threat landscape. Core ledger integrity attacks — manipulation of the authoritative balance records — are mitigated through cryptographic signing of all ledger state (SC-12, SC-13), separation of duties preventing single-operator manipulation (AC-05), and an independent audit log protected even from system administrators (AU-02, AU-09). Counterfeiting — generating fraudulent CBDC not issued by the central bank — is defeated by the central bank's cryptographic issuance key hierarchy (SC-12, SC-13, SC-17), which cannot be forged without the private key, protected by FIPS 140-3 Level 4 HSMs. Double-spend attacks — spending the same CBDC unit more than once — are prevented in online mode by real-time ledger checking and in offline mode by secure element hardware that invalidates tokens on first use (SC-12, PE-03). Privacy attacks — mass surveillance of citizen payment patterns — are bounded by the tiered privacy architecture (PT-01, PT-02, PT-03, AC-04) and enforced by cryptographic privacy-enhancing technologies including blind signatures and zero-knowledge proofs. Bank-run amplification — CBDC acting as a crisis accelerant by enabling instant mass deposit flight — is controlled by holding limits enforced as hard constraints in the core ledger (AC-06) and monitored in real-time against macroprudential thresholds (RA-03, PM-09). Offline hardware attacks — extraction of CBDC tokens from a compromised secure element — are mitigated by TEE architecture, tamper-detection, and per-device key isolation (SC-12, SC-28, PE-03). Insider threats from central bank or intermediary staff — the highest-impact actor class for monetary infrastructure — are addressed through separation of duties (AC-05), multi-person authorisation for privileged operations (IA-02), comprehensive audit logging (AU-02), and insider threat programme governance (PM-12). Infrastructure availability attacks — denial of service against national payment infrastructure — are mitigated through active-active alternate processing sites (CP-07), incident response plans tested for crisis-coincident attack scenarios (IR-08), and continuous monitoring with rapid detection (CA-07).

Assumptions

The organisation is a central bank, central bank technology partner, or licensed CBDC intermediary (commercial bank, payment service provider) building or operating CBDC infrastructure. The CBDC architecture follows the hybrid intermediated (two-tier) model where the central bank operates the core ledger and licensed intermediaries handle distribution and end-user wallets. At least one retail CBDC use case exists (consumer-facing digital currency). The organisation is subject to central banking law, payment systems regulation, AML/CFT legislation, and applicable data protection law (GDPR or equivalent) in the operating jurisdiction. Existing payment infrastructure (RTGS, commercial bank core banking, payment card networks) is already in operation and this pattern addresses the CBDC layer that integrates with or runs alongside existing infrastructure. Physical security of data centres and key ceremony facilities meets national critical infrastructure standards (equivalent to ISO 27001 with national security overlay). A security operations capability capable of monitoring national-scale payment infrastructure exists or is being established.

Developing Areas

• Cross-border CBDC interoperability is the most consequential open design problem in digital currency infrastructure. BIS Project mBridge — connecting the central banks of China (PBC), Hong Kong (HKMA), Thailand (BOT), UAE (CBUAE), and Saudi Arabia (SAMA) — achieved minimum viable product in 2024, demonstrating atomic FX-PvP settlement on a shared ledger that eliminates Herstatt risk (the settlement timing gap that has plagued correspondent banking since the 1974 Herstatt Bank failure). However, at least three competing architectural models are under active development: common platforms (mBridge, Dunbar), interlinking arrangements (BIS Nexus connecting domestic instant payment systems), and bilateral corridors (specific central bank pairs). Each model carries different security, sovereignty, and governance implications — a common platform requires shared key management across jurisdictions with potentially divergent geopolitical interests, while interlinking preserves sovereignty but introduces FX settlement complexity. The geopolitical dimension is unavoidable: mBridge enables cross-border settlement outside USD correspondent banking infrastructure, which has implications for sanctions enforcement and financial statecraft that extend well beyond the technical architecture.
• Programmable money poses risks that are unprecedented in monetary history because no previous form of money has been capable of enforcing spending restrictions at the instrument level. China's digital yuan pilots have demonstrated merchant-category restrictions on government disbursements, and the technical capability exists to implement expiry dates, geographic restrictions, income-based spending limits, and real-time taxation — capabilities that would be impossible to implement with physical cash or conventional bank deposits. The ECB has explicitly prohibited spending restrictions on the digital euro (the 'cash-like' principle), but this is a policy commitment, not a technical constraint — the architecture supports programmability, and future political leadership could reverse the commitment. BIS research draws a critical distinction between programmable money (restrictions embedded in the currency itself) and programmable payments (restrictions applied at the payment rail level, as credit card merchant category codes already do) — the former is architecturally novel and politically dangerous, the latter is an extension of existing practice. Security architects must design programmability layers with constitutional and legislative guardrails that cannot be overridden by executive action alone, including formal governance for programme deployment, independent audit of active programmes, and citizen-accessible transparency mechanisms.
• CBDC-induced financial disintermediation — the risk of digital bank runs — is the primary financial stability concern identified by every central bank exploring retail CBDC. If citizens can instantly convert commercial bank deposits to central bank digital currency with a tap, a loss of confidence in a single bank could trigger deposit flight at a speed impossible with physical cash withdrawal (ATM networks process roughly 100-200 transactions per second per bank; a CBDC conversion API could process thousands). The ECB has proposed a EUR 3,000 holding limit; the Bank of England consulted on GBP 10,000-20,000; the design choice has profound implications for CBDC utility versus financial stability. Tiered remuneration — applying penalty interest rates above the holding limit to discourage hoarding — is the complementary approach favoured by several central bank research papers (BIS WP 976, IMF DP/2020/02). From a security architecture perspective, holding limits must be enforced cryptographically in the core ledger (not just at the intermediary layer, which could be bypassed by using multiple intermediaries), and the system must handle burst load from coordinated mass conversion attempts during a stress event without degrading below the RTO target for normal payment processing.
• Privacy-enhancing technologies for CBDC represent the most technically challenging design space because they must satisfy two mathematically contradictory requirements: regulated anonymity for citizens and lawful access for authorities. The ECB's digital euro design proposes tiered privacy: offline low-value payments with cash-like anonymity (no data shared with the intermediary or the central bank), online payments with pseudonymity (intermediary sees the transaction, central bank sees only aggregates), and high-value payments with full KYC. Project Hamilton (Federal Reserve Bank of Boston / MIT DCI) demonstrated Chaumian blind signatures for transaction privacy — the central bank signs a token without seeing the transaction details, providing cryptographic anonymity — but this approach conflicts with AML/CFT requirements above threshold values. Zero-knowledge proofs offer a middle path: a holder can prove their transaction is below the anonymity threshold, their cumulative daily transactions are below a limit, and their wallet is not on a sanctions list — all without revealing their identity, balance, or transaction history to the central bank. Hardware-based privacy (secure element attestation that spending limits are enforced locally, without reporting balances to any server) is being researched by the ECB and SNB, but requires trust in the tamper-resistance of consumer hardware — a strong assumption given the history of secure element side-channel attacks.
• Offline CBDC resilience is identified by the Bank of England, Riksbank (e-krona), and BIS as a top research priority because it addresses a scenario where digital currency must function precisely when infrastructure has failed — natural disasters, grid attacks, military conflict, or remote areas without connectivity. Tamper-resistant secure elements (NXP SmartMX3, Infineon SLC37, Idemia Secure Enclave) can store CBDC value and execute peer-to-peer transfers without network connectivity, but double-spend prevention without a central ledger requires hardware trust: the secure element must be trusted to decrement the sender's balance and increment the receiver's, with no ability to replay or reverse. BIS WP 1123 identifies the maximum offline accumulation limit as a critical policy-security parameter — too low and the offline CBDC is useless for disaster resilience; too high and the double-spend exposure from a compromised secure element becomes unacceptable. Disaster resilience scenarios require mesh-network payment capability (device-to-device transfer chains where no single device has connectivity), which creates reconciliation complexity when connectivity restores: the central bank must process potentially millions of offline transactions, detect any double-spends, and update the core ledger — a burst processing load that must be architected for but occurs only in exceptional circumstances. The security architecture must also address the physical security of offline-capable hardware: unlike a mobile app that can be remotely wiped, a lost or stolen secure element containing offline CBDC value is equivalent to lost cash.