## ftnea2024003 — Introduction and Cyber Resilience of CBDC Ecosystems ## Source details **Canonical URL:** [ftnea2024003 — Introduction and Cyber Resilience of CBDC Ecosystems](https://www.imf.org/-/media/files/publications/ftn063/2024/english/ftnea2024003.pdf) ## Other formats - [Markdown version](/-/media/files/publications/ftn063/2024/english/ftnea2024003.pdf.md) - [Structured JSON version](/-/media/files/publications/ftn063/2024/english/ftnea2024003.pdf.json) --- ### Introduction — context, purpose, and key observations - Over 100 central banks are exploring central bank digital currencies (CBDCs) to modernize payment systems and to explore potential benefits, risks, and the broad range of new capabilities CBDCs might offer. - A CBDC represents a fundamental change in the way the central bank operates and creates a vast and complex ecosystem that amplifies existing risk exposures and surfaces new ones. - "Without security, there is no trust, and without trust, there is no money." - Adoption of existing live CBDCs has been very low; many countries are at various stages of exploration and experimentation, largely focused on policy goals and functionality with little or no testing for cyber resilience. - Evidence base: draws on live CBDCs, central bank experiments, cybersecurity and resilience frameworks from standard-setting bodies, and work by the BIS Innovation Hub; ongoing experiments will inform future updates. ### Key statistics and notable numeric findings - 1.1 percent and 32.4 percent of global GDP. - Reportedly, over 80 percent of cyberattacks are due to the human element. - 99 percent of cyberattacks can be avoided by practicing foundational security hygiene and organization-wide training and awareness. - A BIS Innovation Hub survey: "49 percent of central banks consider offline payments with retail CBDC to be vital, while another 49 percent deemed it to be advantageous." ### Digital and cyber risk framing - Cybersecurity managed along the "CIA Triad": - Confidentiality: data visible and accessible only to authorized users and for specific purpose(s). - Integrity: data is accurate and complete, ensured for data at rest and in motion and for code/logic used in processing. - Availability: systems and data are accessible and usable as needed; availability controls should extend to all underlying components and interconnections that could cause outages or delays. - Digital risks sit at the intersection of people, process, technology, and data, internal to the institution and within its supply chain (Annex 1). ### Threats, vulnerabilities, and threat actor typology - Typical cyberattacks relevant to financial sector include: Denial of service (DoS)/Distributed denial-of-service (DDoS); System intrusion and data infiltration; Malware, ransomware, and wiperware; Phishing and social engineering attacks; Third-party and supply chain attacks; Cryptographic key compromise. - Threat actor categories (summary): - Nation-states and affiliated groups: highly skilled, well resourced, persistent; main impact: disruptions to critical services, financial and social instability, loss of citizen trust. - Organized crime groups: motivated by financial gain; main impact: fraud, loss of funds, data breaches, reputational damage. - Insiders: employees/contractors with privileged access; main impact: service outages, data breaches, fraud. - Hacktivists: politically/socially motivated; main impact: discrediting institutions and reputational damage. - Attackers increasingly use AI/ML and, potentially in the future, quantum computing. ### Impact of Artificial Intelligence (Box 1) - Positive: AI tools improve cyber defenses (anomaly detection, reducing unauthorized access, data exfiltration, and fraud). - Negative / risks: - AI can facilitate discovery of exploitable vulnerabilities and improve hit-rates of attacks. - Generative-AI (Gen-AI) can be exploited to: 1. support effective social engineering attacks (phishing, deep fakes in voice and images) on a large scale with potential financial stability implications; 2. quickly analyze large amounts of stolen data to identify valuable subsets, mount further attacks, and train models; 3. improve malware generation; 4. support post intrusion activities, such as lateral movement and exfiltration. - Skills gap: human capital to prevent, detect, and contain AI-enabled cyber incidents is in short supply. ### Cyber risk as operational risk — unique features - Cyber-attackers are motivated, persistent, patient, and oftentimes well resourced; origins of attacks are difficult to detect. - Extent of damage is difficult to fully quantify; remnants or backdoors may remain open post recovery. - Typical losses: in the order of millions of US$, but under extreme scenarios they could exceed billions. - In interconnected environments, every connection, however small, can create exposures and vulnerabilities. ### CBDC ecosystem perimeter and mapping - Cyber risk perimeter of a CBDC comprises three broad elements: 1. The currency itself throughout its life cycle—creation, storage, dissemination, and destruction. 2. Transactions or movement and transfer of value between individuals and merchants. 3. Sensitive information that a CBDC collects from users, merchants, and transactions. - Mapping to IMF ASAP model: - Security of CBDC (currency) sits in the asset layer. - Security of transactions maps to the access and platform layers. - Security of sensitive information relates to all layers. ### CBDC-specific technical and operational considerations - New considerations include: digital life-cycle management, programmability and smart contracts, seamless online/offline switching, potential use of DLT and AI, hosting choices (in-house or cloud), and reliance on third parties and national infrastructure. - Foundational national-level factors required: stable communication networks, digital and financial literacy and cyber risk awareness, technological maturity of institutions, collaboration between stakeholders, and a stable geopolitical environment. - Risks unique or amplified versus e-money/stablecoins: - Larger number of intermediaries and third parties; wider and less cyber risk-aware user base; multiple design goals increasing complexity; greater attractiveness to sophisticated attackers (e.g., nation-states). ### National infrastructure and EMDE challenges - Resilience depends on power supply, communication networks, national cybersecurity strategies, and coordination bodies such as CERTs. - EMDE-specific challenges: legacy IT, suboptimal critical infrastructure, limited IT skills, supplier concentration risks, limited legal oversight over vendors, less mature cybersecurity posture, and limited incident response mechanisms. - Materializing cyber risks can cause service disruption, loss of funds, data compromise, counterfeiting, double spending, reputational damage, and erosion of consumer confidence. --- ### Design choices and cybersecurity implications — distribution, token/account, ledger, programmability, wallets, offline Design Option 1: Distribution model - Direct or single tier - Central bank issues CBDC directly to end users, handles all payments, and keeps records of retail holdings in real time. - Requires central bank to create IAM, User and Transaction Authentication, Wallet Provision and Management, Private Key Management, and Dispute Resolution. - Central bank gains full visibility and control of PII and transaction history—creating reservoirs of rich data attractive to hackers. - Most countries have ruled out direct or single-tier models. - Intermediated or two-tier - Central bank provides core ledger/system; delegates other activities to private-sector participants. - Mimics traditional role separation and fosters private-sector innovation; risk management is delegated to intermediaries and overseen by the central bank. Design Option 2: Token or account-based - Account-based model - Key protection area: user identity; requires strong IAM (passwords, passphrases, biometrics, or combinations). - Opportunity to strengthen controls (data sharding, granular permissions, zero-trust, quantum-safe cryptography). - Could impair universal access depending on account-opening laws/regulations. - Token-based model - Tokens issued by central bank and transferred over distributed ledgers; key risk: protection of the digital token throughout life cycle. - Token issuance uses cryptographic mechanisms; private keys secure authenticity and uniqueness. Design Option 3: Ledger design — centralized and distributed trade-offs - Centralized Ledger Technology (CLT) - Findings: efficient, mature, well-understood governance; can adopt distributed principles via replication; consumers have recourse. - Key issues: single points of failure, attractive target for insiders, ransomware risks to replicated backups, geographic concentrations amplify outages. - Mitigations: air-gapped data centers, strong IAM, periodic privileged-user profiling, appropriately designed replication (real-time to secondary + periodic sync to third), geo-replication and off-site backups. - Distributed Ledger Technology (DLT) - Findings: spread across nodes; choice of consensus trades robustness for efficiency; may enable programmability and tokenization; potentially more available due to node distribution. - Key issues: recent/complex technology, limited national-scale testing, DDoS, 51-percent attacks, software/API failures, crash/Byzantine faults, scalability/latency concerns. - Mitigations: permissioned DLT, policies + strong oversight, geographically dispersed nodes, independent monitoring, algorithms tolerant to misbehaving nodes (e.g., PBFT). Software code: programmability and smart contracts - Programmability optional but expands utility; smart contracts can be composable and trigger cascading effects. - Key issues: code flaws or malicious code can cause fraud, manipulation, cascading failures, and complicate recovery. - Mitigations: - Regulatory frameworks defining creation/execution/enforcement. - Secure coding practices, code signing, certification. - Segmented governance: Authorization vs Auditability. - Regular independent audits and formal mathematical verification. - Bug bounty programs and broad community review. End points: digital wallets - Core functions: user authentication, transaction authentication, user interface; some wallets may store offline funds. - Key issues: compromised cryptographic keys, compromised IAM, compromised user interfaces leading to credential harvesting and theft. - Mitigations: - Secure hardware wallets, embedded secure elements, TEEs, threshold signing. - Custodians for less-experienced users. - Clear UI design and security prompts. Design Option 4: Offline functionality - Offline models: "Fully" offline; Intermittent offline (issuer-set risk limits); "Staged" offline (not settled until online). - Key issues: counterfeiting/double spending, device obsolescence/cloning/theft, torn transactions. - Mitigations: - Policy: record transactions but delay settlement, caps on offline transactions and wallet balances. - Technical: established cryptographic algorithms, hardware security modules, key rotation, crypto-agility, physical unclonable components; active research and experiments ongoing (Riksbank, Bank of Canada). --- ### Box 2 — Impact of Quantum Computing on CBDC Cybersecurity - QC can "solve difficult problems much faster" with direct impact on cybersecurity. - Widely used algorithms (elliptic curves, RSA) "were shown to be easily broken with QC." - QC threat "may not be immediate" — first quantum computers are "not expected before 2030," but transition to quantum-safe cryptography is "likely to be a long and arduous process." - Essential requirement: "cryptographic agility" to enable quick, seamless transitions to newer algorithms. - Potential mitigations: - General strengthening: user risk awareness, industry collaboration, physical and logical protections. - Air-gapped data centers for issuance systems; strong IAM. - Secure hardware elements for key storage; multilayered digital signatures. - Mutable tokens used once and destroyed. - Use cryptographic keys/algorithms conforming to international standards and integrate post-quantum schemes early in design. --- ### Cloud technology, vendor reliance, and governance - Cloud benefits: scalability, resilience, robust security investments by large CSPs and certifications (Tier, SOC 1, SOC 2). - Shared responsibility: central bank must maintain ownership/control of application and data layers; securing those layers sits with the owning entity. - Key cloud-specific issues: - Dependence on reliable internet connectivity; disruptions impact CBDC access. - Cloud platforms targeted by malware/ransomware via vulnerabilities, misconfigurations, third-party code, or insiders. - Single CSP dependency creates single point of failure and exit complexity; global data flows may introduce legal uncertainties. - Integration challenges with legacy systems in cloud environments. - Mitigations: - Clear migration strategy and frameworks; retain mission-critical on-premise where appropriate. - Select reputable CSPs with verifiable certifications. - Define roles/responsibilities; implement zero-trust and granular access controls. - Contracts with exit clauses and audit rights; upskill in-house cloud security talent. ### Vendor, implementation, and EMDE observations - Cybersecurity tests were often out of scope and deferred in live/pilot implementations. - External service-provider-led implementations risk poor knowledge transfer if not managed contractually. - Cost pressures in some EMDEs may drive lower-priced solutions with higher cyber risk exposure. - Laws have been adapted to include CBDC as legal tender in some jurisdictions, but regulatory guidance to strengthen cyber/information security is often not yet formalized. - Limited awareness of cyber risk and its potential impact on a public-facing national infrastructure with financial stability implications. --- ### Principles, supervisory, organizational, cooperation, and technical good practices High-level principles (summarized) - Principle 1: Resilience at least to the highest standards that apply to existing payment systems. - Align CIA triad and recovery objectives with requirements for systemic FMIs. - Principle 2: Protection proportional to systemic risk, considering severe but plausible threats. - Core systems should run multisite, fully redundant and potentially air-gapped infrastructure with real-time replication and separate backups. - Principle 3: Minimize the attack surface through proper design and implementation. - Assume targeting by highly sophisticated actors; implement zero-trust, strong standards-based crypto, and restrict functionalities to strictly necessary features. - Principle 4: Resilience requirements should be comprehensive. - Interplay among supervision, organization, cooperation, and technology; end-user awareness training is essential. Supervisory and organizational capabilities (baseline and good practices) - Baseline findings include: - Established legal framework to correct security noncompliance and prosecute cybercrime. - All legal entities operating core CBDC infrastructure within remit of financial regulators. - Regulation/guidance on operational/technology/cyber risk exists and enforced (for example, two to three years). - Licensing includes operations/technology/cyber criteria; CBDC-specific regulation passed. - Supervisory capabilities should encompass regulation, assessment of cyber risk in FMIs and financial institutions, systemic cyber risk assessment, and effective mitigation actions. - Organizational capabilities include CERT, Financial Intelligence Unit, Data Protection Agency, Customer Protection Agency, capacity for CBDC helpdesk in local languages, ongoing cyber training, and talent pipelines. - Cooperation capabilities: coordination among regulatory, law enforcement, national security, critical infrastructure authorities and peer foreign organizations. - Technical capabilities: reliable domestic telecommunications, redundant international data lines, Tier III data center capacity (Tier IV if CBDC projected systemic). Good practices (technical highlights) - Multilayered defense-in-depth architecture; multisite fully redundant operations (Tier III+), air-gapped core system, dedicated secure wide area networks, zero-tust interaction principles. - Cryptography compliant with international standards and employing quantum resistant algorithms; disallow proprietary/un-auditable cryptographic functions. - Strict controls on programmability and smart contracts; separation of production/test/dev environments with automated migration controls. - 24 × 7 monitoring with automated alerts and AI-based anomaly detection tools. - Regular threat-intelligence red teaming, incident reporting regimes, industry-wide cyber crisis exercises, and supply-chain risk oversight. ### Cyber resilience and CBDC project management — the 5P methodology (phases and cyber workstreams) - Recommended iterative five-phase or "5P methodology" with adequate time in each phase and early security testing (prototype phase). - Cyber risk management workstreams by phase (condensed): - Phase 1. Preparation: assess cyber maturity, map CBDC-specific cyber requirements, identify readiness gaps, develop gap remediation plan. - Phase 2. Proof-of-Concept/Proof of Assumption: assess risk mitigation feasibility, evaluate privacy-enhancing tech, DLT and AI risks, lab test security architecture, design rulebook and governance. - Phase 3. Prototypes: document security requirements, develop resilient-by-design model, test infrastructure/app security, develop contingency and crisis plans, conduct penetration tests and hackathons. - Phase 4. Pilot: simulate cyber resilience in live environment with ecosystem participants, run outages and attack simulations, red teams, code reviews, bug-bounties, and fix gaps. - Phase 5. Production: robust security monitoring, regular cyber resilience tests, continuous improvement programs. ### Production-stage safeguards and technical recommendations - Robust security monitoring; regular cyber resilience tests; continuous improvement. - Recommended technical safeguards: - Quantum resistant cryptography. - Air-gapped data centers for issuance. - Mutable tokens. - Secure hardware elements and hardware security modules for key storage. - Secure coding practices and enhanced IAM controls. - Emphasize holistic lifecycle-based cyber risk management spanning people, process, technology, and supply chain. ### Human element, training, and governance - Human element central: over 80 percent of cyber incidents due to human factor. - Strong emphasis on ongoing training, risk awareness, background checks for staff/contractors, and succession planning. - Assurance teams should have capacity to verify compliance and detect anomalous behavior. - Clear governance: independent payment system oversight if central bank operates core system; coordination council for cross-authority alignment. --- ### Implementation implications and next steps - Upfront capacity building and readiness assessment is essential before moving to large-scale production. - Prioritize early security testing in prototype phases to discover vulnerabilities and avoid expensive rollbacks. - Leverage BIS-led initiatives (Polaris, Sela) and active experiments to inform future guidance. - Adopt a mix of technical safeguards, rigorous monitoring, regular resilience testing, supply-chain oversight, and a focus on the human factor. *Source: ftnea2024003 — IMF Fintech Note: Cyber Resilience of the Central Bank Digital Currency Ecosystem (ftnea2024003).* ### Introduction ........................................................................................................... ### Introduction ### Context and purpose - Over 100 central banks around the globe are exploring central bank digital currencies (CBDCs) to modernize payment systems and to explore potential benefits, risks, and the broad range of new capabilities CBDCs might offer. - A CBDC represents a fundamental change in the way the central bank operates and creates a vast and complex ecosystem that amplifies existing risk exposures and surfaces new ones. - "Without security, there is no trust, and without trust, there is no money." A CBDC ecosystem will be a high-value target for a range of threat actors including nation-states and cyber criminals; any successful attack or operational failure resulting in a service outage, data breach, or fraud will erode public trust and confidence with systemic implications. ### Key characteristics of CBDC ecosystems (from the note) - Retail CBDC ecosystems are vast, complex, and highly interconnected, including participants outside the central bank’s purview and reliant on telecom networks and national infrastructures. - Wholesale CBDC ecosystems are available only to financial institutions, comprise fewer participants largely within supervision, and their cyber/operational risks are largely an "insider" threat subset of retail risks. - CBDC design choices considered in this note focus on a retail CBDC given its higher complexity. ### Digital and cyber risk framing - Digital risks sit at the intersection of people, process, technology, and data, both internal to the institution and within its supply chain (Annex 1). - Cybersecurity is managed along the "CIA Triad" (Information Security Trust principles): - Confidentiality: data visible and accessible only to authorized users and for specific purpose(s). - Integrity: data is accurate and complete, ensured for data at rest and in motion and for code/logic used in processing. - Availability: systems and data are accessible and usable as needed; availability controls should extend to all underlying components and interconnections that could cause outages or delays. ### Threats, vulnerabilities, and actors - Vulnerabilities across people, process, and technology can be exploited by cyber threat actors to launch cyberattacks that cause service outages, data breaches, and fraud. - Reportedly, over 80 percent of cyberattacks are due to the human element. - 99 percent of cyberattacks can be avoided by practicing foundational security hygiene and organization-wide training and awareness. - Typical types of cyberattacks relevant to the financial sector (Table 1) include: - Denial of service (DoS)/Distributed denial-of-service (DDoS) - System intrusion and data infiltration - Malware, ransomware, and wiperware - Phishing and social engineering attacks - Third-party and supply chain attacks - Cryptographic key compromise ### Cyber risk as a dimension of operational risk - Cyber risk can be a source or consequence of failures in processes, people, or technology and is a subset of operational risk. - Cyber events can cause operational disruptions leading to reputational and financial risks; operational events can create vulnerabilities exploitable by cyber threat actors (for example, outages facilitating credential harvesting). - Unique features of cyber risk that differentiate it from traditional operational risk frameworks: - Cyber-attackers are motivated, persistent, patient, and oftentimes well resourced; origins of attacks are difficult to detect due to lack of geographical boundaries. - The extent of damage from a cyberattack is difficult to fully quantify because remnants or backdoors may remain open post recovery. - Losses due to cyber incidents are in the order of millions of US$, but under extreme scenarios they could exceed billions. - In an interconnected environment, every connection, however small, can create exposures and vulnerabilities for the ecosystem. ### CBDC-specific technical and operational considerations highlighted - CBDC implementation introduces technical and operational considerations not present in existing payment systems, including: - Use of digital tools for life-cycle management of the currency. - Use of programmability and smart contracts for utility and efficient transfer. - Need for seamless switching between online and offline modalities to maintain service continuity. - Potential use of technologies such as distributed ledgers (DLT) and artificial intelligence (AI). - Hosting choices (in-house or cloud) and reliance on third parties and national infrastructure. - Foundational national-level factors required for CBDC deployment include stable and efficient communication networks, digital and financial literacy and cyber risk awareness of payment system users, technological maturity of institutions, collaboration between stakeholders, and a stable geopolitical environment. ### Evidence base and scope of the note - Adoption of existing live CBDCs has been very low; many countries are at various stages of exploration and experimentation, largely focused on policy goals and functionality with little or no testing for cyber resilience. - The note draws on experiences from live CBDCs, central bank experiments, cybersecurity and resilience frameworks from standard-setting bodies, and work by the BIS Innovation Hub. Insights and results from ongoing experiments will inform future updates. *Source: ftnea2024003 - Introduction (ftnea2024003 - Introduction)* ### 1.1 percent and 32.4 percent of global GDP. ### 1.1 percent and 32.4 percent of global GDP. ### Cyber risk characteristics and operational challenges - Certain cyberattacks can render traditional risk management and business continuity arrangements ineffective (example: ransomware in an environment of real-time data replication also impacting backup data stores simultaneously). - Cyber risks are difficult to predict due to: - rapid digitalization, - increasing zero-day vulnerabilities, - fragmentation of control measures. - Traditional prediction methods that rely on past data struggle to keep pace with constantly evolving attacker techniques. - Attackers use the same defensive tools as defenders, including AI, machine learning (ML), and, in the future, quantum computing (QC). - A significant proportion of cyberattacks are driven by human factors (poor security hygiene, low risk awareness, increasing sophistication of attacks), resulting in poor detection and higher exploitation by cyber threat actors. - Sophisticated exploits are becoming commonly accessible on the dark web, lowering barriers to entry; this is amplified by AI which further lowers entry barriers for cyberattacks. ### Threat actor categories (summary of Table 2) - Nation-states and affiliated groups - Description: Government institutions, intelligence agencies, and defense services with cyber espionage capabilities. - Motivation: To gain political advantage. - Main impact: Disruptions to critical services, financial and social instability, and loss of citizen trust. - Resources: Likely to be highly skilled, well resourced, and persistent; may influence insiders. - Organized crime groups - Description: Cyber gangs and individual criminals with technical know-how. - Motivation: Financial gain through ransom and bullying tactics. - Main impact: Fraud, loss of funds, data breaches and leakage, reputational damage. - Resources: Usually well resourced in skills and know-how but not always in IT equipment. - Insiders - Description: Employees of an institution or of its key suppliers with privileged access. - Motivation: Retribution, financial gain, or to cause reputational damage. - Main impact: Service outages, data breaches, fraud, reputational damage, loss of funds. - Resources: Not well resourced but often with privileged access; some cause vulnerabilities by careless behavior rather than malintent. - Hacktivists - Description: Groups of technology and cyber experts, geographically dispersed, working for a cause. - Motivation: Advancing a political or social cause. - Main impact: Discrediting institutions and reputational damage. - Resources: Not well resourced but persistent depending on the pursued cause. ### Impact of Artificial Intelligence (Box 1) - Positive: AI tools (ML, deep learning, natural language processing) improve cyber defenses (anomaly detection, reducing unauthorized access, data exfiltration, and fraud). - Negative / risks: - AI can facilitate discovery of exploitable vulnerabilities and improve hit-rates of attacks. - Generative-AI (Gen-AI) can be exploited to: 1. support effective social engineering attacks (phishing, deep fakes in voice and images) on a large scale with potential financial stability implications; 2. quickly analyze large amounts of stolen data to identify valuable subsets, mount further attacks, and train models; 3. improve malware generation; 4. support post intrusion activities, such as lateral movement and exfiltration. - Large datasets and models used in critical systems are attractive targets for attackers. - Sophisticated use of AI in cyberattacks is in the short term confined to well-resourced threat actors; new threats are likely as technology evolves. - Skills gap: Skill sets to prevent, detect, and contain cyber incidents using AI are in short supply; significant investments may be needed to develop human capital for effective use of AI tools. - Definitions/notes preserved verbatim: - Zero-day vulnerabilities are typically unknown to the vendor and for which no update, patch, or remedy has been developed. - Gen-AI comprises AI models that emulate the structure and characteristics of input data to generate derived synthetic content including images, videos, audio, text, software code, and other digital materials. - Industry response: Efforts are being made by large technology companies to curb improper use of AI tools and models. ### CBDC ecosystem: interconnections and cyber risk perimeter (Section II) - A well-designed CBDC at the technological frontier can enhance operational and cyber resilience of payments infrastructure, but increased interconnections can introduce additional exposures not commonly experienced by other forms of digital money. - A retail CBDC ecosystem is more complex than a wholesale CBDC and involves intermediaries (banks and nonbank financial institutions) and other financial market infrastructures with varying cyber vulnerabilities. - Many participants in the CBDC ecosystem may be outside the central bank’s purview, potentially masking a build-up of risks; overall responsibility for secure and resilient operations lies primarily with the central bank as issuer. - Cyber risk perimeter of a CBDC (three broad elements): 1. The currency itself throughout its life cycle—creation, storage, dissemination, and destruction. 2. Transactions or movement and transfer of value between individuals and merchants. 3. Sensitive information that a CBDC collects from users, merchants, and transactions (needs protection in transit and at rest). - Mapping to the IMF ASAP model: - Security of CBDC (currency) sits in the asset layer. - Security of transactions maps to the access and platform layers. - Security of sensitive information relates to all layers and can be compromised at any stage. ### Common and CBDC-specific cyber threats - CBDCs could be subject to similar threats as other digital payments, including: - Compromise of core servers dedicated to issuance (minting), holding, and redemption leading to fraud, unauthorized issuance, or exceeding intended money supply. - Compromise of payment systems leading to redirection of funds and mismatched balances. - Corruption or exploitation of code, or bugs in core/enabling systems leading to service disruptions, fraud, data breaches. - Direct attacks on underpinning infrastructure (cloud, power grids, internet, mobile networks) causing service disablement. - Insider threats from human error, manipulation, or malintent leading to compromised data, outages, or loss of funds. - CBDC-unique exposures (compared to e-money or stablecoins): - Larger number of intermediaries and third parties. - Wider and less cyber risk-aware user base. - Design intended to meet multiple goals (asset tokenization, financial inclusion, efficient disbursements, conditional payments, several payment initiation methods) increasing complexity. - As the national currency in digital form, it may be more attractive to sophisticated cyber-attackers such as nation-states. - Importance: Security and resilience requirements should be considered from early design stages to avoid expensive rollbacks and bolt-on measures. ### National infrastructure and EMDE challenges - Resilience and security of digital payment systems depend on national core infrastructure: power supply, communication networks (national and international), mobile/broadband/internet connectivity, national cybersecurity strategies, and coordination bodies such as Cyber Emergency Response Teams (CERTs). - Emerging market and developing economies (EMDEs) may face more pronounced challenges: - Legacy and out-of-date IT environments; layering new services/controls can create conflicts and vulnerabilities. - Suboptimal critical national infrastructure prone to power and network outages. - Inadequate skills in IT best practices and threat containment. - Supplier concentration risks for critical services (cloud, 24 × 7 perimeter monitoring, security operation centers); central banks may lack legal power to oversee or audit vendor environments. - Less mature cybersecurity posture, limited adoption of modern security frameworks, lack of national strategies, incident response, and information exchange mechanisms. - Materialization of cyber risks in a CBDC system can cause service disruption, loss of funds, data compromise, counterfeiting, double spending, reputational damage, and erosion of consumer confidence. ### Design and technology choices: cybersecurity implications (Section III) - Delivering a CBDC is large-scale and complex; design choices affect risk profile and require safeguards to ensure confidentiality, integrity, and availability. - A CBDC system should be resilient to faults and failures across people, infrastructure, networks and interfaces, hardware, software, protocols, logic, and control failures (accidental or intentional). Design Option 1: Distribution model - Two broad distribution models described: 1. Direct or single tier - Central bank issues CBDC directly to end users, handles all payments, and keeps records of retail holdings in real time. - Requires central bank to create IAM, User and Transaction Authentication, Wallet Provision and Management, Private Key Management, and Dispute Resolution. - Central bank gains full visibility and control of personally identifiable information (PII) and transaction history—creating reservoirs of rich data attractive to hackers. - Places new unfamiliar burdens and onboard unseen risks for central banks; most countries have ruled out direct or single-tier models. 2. Intermediated or two-tier - Central bank provides core ledger/system and life-cycle management and secure resilient platform; delegates other activities to private-sector participants. - Mimics traditional role separation and fosters private-sector innovation and competitiveness. - Central bank processes and records wholesale payments and balances, may periodically record retail balances. - Risk management within the wider ecosystem is delegated to intermediaries and overseen by the central bank or equivalent supervisory authority. Design Option 2: Token or account-based - Account-based model - Electronic holding of funds in a user account using debit/credit methods; similar to bank accounts and electronic payments. - Key protection area: user identity—strong IAM using passwords, passphrases, biometrics, or combinations. - New infrastructure offers opportunity to strengthen controls (data sharding, granular permissions, zero-trust architecture, quantum-safe cryptography). - Based on account-opening laws/regulations, could impair universal access to national currency. - Token-based model - Tokens issued by the central bank and transferred over distributed ledgers; akin to banknotes/coins in a physical wallet, offering some controllable level of anonymity and easier universal access. - Key risk: protection of the digital token throughout its life cycle. - Protection of currency includes issuance, distribution, destruction, programmability (if used), and smart contracts affecting supply and transfer. - Token issuance uses cryptographic mechanisms (digital signatures and public-private key encryption); private keys secure authenticity and uniqueness; public keys used for verification. Key issues highlighted - Compromise of cryptographic keys, digital signatures, and other cryptographic algorithms used for authentication and authorization. - Quantum computing is a future threat to cryptography protecting digital assets: - Elliptic curve keys, the gold standard for digital signatures, can potentially be computed by quantum attackers using publicly visible keys thereby threatening the safe custody of CBDC. - Central banks have experience managing fiat currency life cycle, but managing the life cycle of digital currency requires new logical protection measures across technology, people, processes, and governance. *Source: IMF Fintech Note (ftnea2024003 - 1.1 percent and 32.4 percent of global GDP).* ### Box 2. Impact of Quantum Computing on CBDC Cybersecurity ### Box 2. Impact of Quantum Computing on CBDC Cybersecurity ### Quantum computing risk and cryptographic agility - Quantum computing (QC) can "solve difficult problems much faster" with a direct impact on cybersecurity and CBDC. - Cryptography ensures confidentiality and integrity of CBDC; the strength of cryptographic algorithms (difficulty to break them) is vital. - Several widely used algorithms such as elliptic curves or RSA form the basis for digital signatures, are considered strong today, but "were shown to be easily broken with QC." - The QC threat "may not be immediate" as the first quantum computers are "not expected before 2030," but transition to quantum-safe cryptography is "likely to be a long and arduous process." - CBDC security architectures must enable quick, seamless transitions to newer algorithms as older ones become vulnerable — this feature is called "cryptographic agility" and "should be an essential requirement in any CBDC implementation project." - "Experimentation is under way in this regard with positive early results." ### Potential mitigations for quantum and general cybersecurity threats - General strengthening of security defenses: user risk awareness, comprehensive industry collaboration, physical and logical protections. - Data centers housing issuance systems should be air-gapped and access strictly controlled using strong IAM processes. - Use secure hardware elements for key storage and multilayered, strongly secured digital signatures with rigorous oversight and surveillance. - Use mutable tokens that live for only one use and are destroyed at the end of that transaction (considered in some experiments). - Use cryptographic keys and algorithms that conform to well-established international standards. - Although the QC threat is not imminent, a breached encryption algorithm will need a swift response from authorities; "Efforts should be made to integrate post-quantum cryptographic schemes early in the design process." ### Design Option 3: Ledger design — centralized and distributed trade-offs Centralized Ledger Technology (CLT) - Findings: - Centralized systems are efficient and mature with proven supervisory and regulatory rule books. - Protection, detection, and recovery mechanisms are well established and can be monitored efficiently. - Governance entrusts control to a central authority and can be amended expeditiously. - For business continuity, centralized systems adopt distributed principles via real-time replication across multiple data centers. - Centralized systems offer consumers recourse in face of errors, breaches, or outages and enable full visibility of risks. - Key issues: - A central authority or malicious insider can change rules, rewrite ledger history, censor or delay transactions, impacting public trust. - Centralized ledgers are attractive single points of failure; a successful attack can disable the entire system and lead to data breaches affecting many customers. - Ransomware attacks could impact live and backup systems simultaneously for replicated databases. - Malicious insiders with privileged access can make unauthorized amendments that remain undetected. - Large-scale power or network outages could impact production and backup servers simultaneously, amplified if secondary data centers are in proximity. - Possible mitigations (guidance from standard-setting authorities such as the CPMI): - Use secure, military-grade, air-gapped data centers for issuance/minting with strong IAM and frequent auditing of access logs. - Periodic profile checks on privileged users to detect malintent driven by changes in circumstances. - Appropriately designed replication to reduce ransomware impact, e.g., real-time replication to a secondary environment supported by periodic syncing to a third. - Geo-replication and off-site backups to reduce impact of large-scale outages of enabling critical infrastructure such as power grids. Distributed Ledger Technology (DLT) - Findings: - DLT is spread across several nodes; nodes can participate via consensus. DLT can be open/permissionless or permissioned. - Choice of consensus mechanism trades robustness for efficiency (single node confirmation is efficient but not robust; many nodes increase robustness but suffer latency). - DLT may facilitate efficient settlements, programmability, conditional payments, and asset tokenization; it affords coordination benefits from shared governance. - DLT networks may be natively more "available" than fully centralized systems since node failure does not automatically collapse the system. - Key issues: - DLT is relatively recent and complex, requiring specialized skills in short supply; not tested at national payment system scale, hindering predictive threat modeling. - DLT is not hardened to the same extent as traditional systems and is not immune to DDoS, collusion among nodes (51-percent attack), fraud, double spending, or delays. - Extensive use of APIs and software code means software failures or malicious code could compromise entire network integrity. - Crash faults can occur if a large fraction of validators go offline (e.g., due to geographically concentrated power/network disruption). - Byzantine faults can occur if some validators actively misbehave; in CBDC, financial incentives for misbehavior are high. - Scalability and response times could be suboptimal given extensive replication and authentication. - Potential mitigations: - Use permissioned DLT with nodes limited to trusted parties (being tested by several central banks). - In absence of specific threat modeling, combine policies, strong oversight and governance, and robust IT internal controls (advancements via project Polaris and others). - To guard against crash faults, geographically disperse nodes using different power sources and network links. - To avoid collusion and corruption, independently monitor nodes and govern them by algorithms that can withstand a certain number of misbehaving nodes (for example, PBFT). ### Software code: programmability and smart contracts - Findings: - Programmability is optional; not necessary for primary CBDC role but can expand utility and foster innovation. - Smart contracts can execute automatically based on conditions and be composable (one triggers another). - Programmability involves software code; flaws (unintended or malicious) can lead to fraud or manipulation, amplified by composability or simultaneous executions. - Key issues: - Code corruption or compromise from poor design, coding errors, or malicious alterations can cause operational failures, data breaches, integrity issues, and fraud. - Attacker contracts can manipulate victim contracts, causing cascading harm when outputs trigger multiple other contracts. - Undetected compromised code or bugs can mask risk build-up, especially with open-source code lacking due diligence and monitoring. - Interoperability and alignment of chained smart contracts can complicate recovery and remediation. - Possible mitigations: - Establish regulatory frameworks and legal standards defining creation, execution, and enforcement of programs impacting CBDC payments. - Promote secure coding best practices and issue guidelines; include code signing by developers and certification from established authorities. - Segment governance into 1) Authorization (who can program and for what purpose) and 2) Auditability (who checks the code is performing as intended). - Mandate regular and comprehensive audits of open-source code and smart contracts by independent security experts before and after deployment. - Employ formal mathematical verification techniques to prove smart contract logic correctness and absence of vulnerabilities. - Encourage broad community review by developers, security experts, and stakeholders. - Implement bug bounty programs to incentivize discovery and reporting of vulnerabilities. ### End points: digital wallets - Wallet core functions: user authentication, transaction authentication, and user interface; in some designs wallets may store funds for offline use. - User authentication overlaps with identity verification and can use passwords, PINs, biometrics, or combinations. - Transaction authentication typically uses cryptographic private/public key pairs; the private key signs transactions proving ownership of tokens. - Transactions are verified by the network via consensus (e.g., proof of work or proof of stake); once confirmed, wallet balances update. - User interface must balance simplicity/convenience with security protocols. - Key issues: - Compromised cryptographic keys: private keys can be lost or stolen. - Compromised IAM: stolen private keys/credentials allow adversaries to submit fraudulent transactions. - Compromised user interfaces: ambiguous graphics/icons may link to malicious sites and fake addresses to harvest credentials and steal funds. - Possible mitigations: - Use secure hardware wallets or embedded secure elements to store keys, complemented by Trusted Execution Environments (TEEs) to protect cryptographic keys and handle crypto processes; use threshold signing to create a single digital signature from multiple signatures. - Clear authorization protocols for key issuance and flexible key management involving authorized nodes that can invalidate and re-issue keys. - Use custodians (intermediaries) to manage keys for less-experienced users. - Design clear user interfaces with concise labeling and built-in security prompts and alerts for external link activation. ### Design Option 4: Offline functionality - Rationale: - Offline access increases resilience against temporary and prolonged outages and promotes financial inclusion in areas with limited telecoms coverage or frequent outages. - Central bank survey finding: - A BIS Innovation Hub survey shows that "49 percent of central banks consider offline payments with retail CBDC to be vital, while another 49 percent deemed it to be advantageous." - Offline models: - "Fully" offline: immediate offline settlement; payee can immediately spend received money. - Intermittent offline: issuer-set risk limits cap activity before offline wallets must connect to ledger. - "Staged" offline: transactions made offline but not settled until connection; payee cannot spend until online. - Security context: - Offline validation relies on hardware security and software integrity on devices; online validation ensures no double spending or counterfeiting in real time. - Double spending offline requires compromising user devices and cryptographic protocols (man in the middle, replay, cloning, jailbreaking, device tampering). - Key issues: - Counterfeiting and double spending: - CBDC may reside on devices (cards or smartphone wallets) that can be replicated or manipulated; without real-time surveillance, attackers can launch multiple attacks while offline. - Transactions protected by cryptography can be reverse engineered to generate fake messages and counterfeit value; side channel attacks (energy consumption, radiation emission) can crack cryptographic keys. - Device obsolescence, cloning, or theft: malicious actors can unlock and use stolen devices; damaged devices can block access to funds; outdated security protocols create vulnerabilities. - Torn transactions: weak/unstable communication links can record only one part of transaction (sender deducted, recipient not credited). - Any data breach or transaction integrity compromise results in reputational damage and erosion of user confidence. - Possible mitigations: - Policy measures: record transactions but delay settlement until online, cap number/value of offline transactions, limit how much CBDC can be stored in offline wallets. - Technical measures: use established cryptographic algorithms with sufficiently long keys, strong key management (keys in hardware security modules), key rotation, and code obfuscation. - Keys and algorithms must guard against quantum threat and conform to crypto-agility. - Emerging hardware with physical unclonable components may provide future solutions. - Developing complete solutions for torn transactions is challenging (as shown in e-Krona Phase 4 report); active research and experimentation are underway (Riksbank, Bank of Canada, others). *Source: IMF — Box 2. Impact of Quantum Computing on CBDC Cybersecurity (ftnea2024003).* ### 1. Weak visibility of security vulnerabilities in interconnected systems as they may be governed ### 1. Weak visibility of security vulnerabilities in interconnected systems as they may be governed ### Systemic risks from interconnected governance and vendor reliance - Interconnected systems governed by different regulatory bodies with varying intensity create weak visibility of security vulnerabilities and a high risk of contagion, potentially leading to an undetected build-up of risks. - Reliance on vendors for critical services could result in unmitigated risk transmission and vendor lock-in; inadequate knowledge transfer could lead to poor or expensive post-implementation security management and remedial actions.45 - Examples cited: Falcon update from CrowdStrike which halted airlines, health services, and media; SolarWinds that pushed a contaminated patch to computer systems worldwide. - Blurred boundaries and poor demarcation of role responsibilities in digital ecosystems can create accountability and control gaps; sharing excessive information with key vendors could shift control away from the central bank. ### Cloud technology: benefits and shared-responsibility risks - Benefits of adopting cloud technology (as stated in the source): - Scalability: cloud infrastructure and service propositions can provide flexible and elastic environments that automatically scale to accommodate unplanned changes in capacity and workload. - Resilience: large CSPs operate vast infrastructure across continents and time zones to ensure high availability, fault tolerance, and disaster recovery through automatic redirection to alternate regions. - Robust security: large cloud providers invest in security measures and certifications (examples: Tier certification of the cloud data center, SOC 1, SOC 2) and offer built-in features such as encryption for IAM and threat detection systems. - Shared responsibility model: - Security of a CBDC system’s application and data requires the central bank to maintain ownership and control of the environment; responsibility for securing those layers sits with the owning entity. ### Key issues specific to cloud-hosted CBDC components46,47 - Cloud-based systems require reliable internet connectivity; disruptions can hinder access to CBDC services, particularly in countries with weak national communications infrastructure—may necessitate on-premise or local “cloud” instances with physical cable connectivity. - Cloud platforms remain attractive to perpetrators and have been targeted by malware, including ransomware, due to vulnerabilities, misconfigurations, compromised third-party code, or insider threats; poor cloud security can result in significant data breaches (examples cited: Equifax, Google Cloud, and AWS).47 - Effective and secure use of the cloud is a complex shared responsibility between CSP and consumer and can be ambiguously demarcated. - Dependency on a single CSP can create a single point of failure, complicate exit or migration, increase costs, and add operational complexity. - The global nature of cloud services may introduce legal uncertainties and weak remediation if data is stored or processed in an unfriendly jurisdiction. - Integration challenges exist when connecting CBDC infrastructure with legacy financial systems and services in a cloud environment. ### Possible mitigations for cloud-related risks - Establish a clear strategy and frameworks to determine what data and services can be migrated or hosted in the cloud; retain mission-critical operations such as issuance on-premise where appropriate. - Select reputable cloud service providers with appropriate, verifiable security and resilience certifications. - Define roles and responsibilities clearly to avoid ownership gaps across the value chain. - Implement granular access controls and apply zero-trust principles for critical systems and sensitive data. - Design contracts with exit clauses detailing data treatment upon termination; include rights to audit security protocols or obligations to share independent audit and penetration test outcomes. - Upskill in-house talent with deep understanding of cloud security configuration and integration with on-premises systems. ### Design choice considerations and trade-offs - No single design choice is universally superior; design choices should be considered based on jurisdictional needs and motivations to issue a CBDC.48 - Vulnerabilities differ by architecture (example contrasts): - CLT: single points of failure such as a controlling central node vulnerable to attack or outage. - DLT: vulnerabilities include unauthorized use of keys, software failure or improper operation, or consensus mechanism failure (crash or “Byzantine” faults). - Cloud-hosted CBDC access may be impacted by national infrastructure stability (power grids, communications). - Programmable or conditional payments may be necessary in some countries and controversial in others. - Offline functionality could be a prerequisite in countries with weak networks or a secondary option where CBDCs coexist with fiat-based e-money systems. - Any architectural or technology option should be carefully designed and tested for vulnerabilities using a rigorous approach such as the IMF 5P methodology.49 ### High-level principles for protecting a CBDC ecosystem (summary of Principles 1–4) Principle 1: Resilience at least to the highest standards that apply to existing payment systems - Align confidentiality, integrity, and availability with international standards for systemically important payment systems or Principles for Financial Market Infrastructures. - Examples of derived requirements: - Maximum tolerable downtimes, recovery time objectives, and recovery point objectives for central elements should be aligned with or surpass requirements for systemic FMIs. - Cyber resilience frameworks for core systems, processing infrastructure operators, and intermediaries should define risk tolerances, objectives, responsibilities, and risk management processes based on internationally accepted standards and be rigorously enforced. Principle 2: Protection proportional to systemic risk, considering severe but plausible threats - Focus resilience attention on the core system, processing infrastructure, and intermediaries; adapt existing standards for newer CBDC technologies and give specific consideration to endpoints (digital wallets, point of sale terminals). - Examples of derived requirements: - Core system and processing infrastructure operators should run CBDC systems on multisite, fully redundant and potentially air-gapped infrastructure with real-time data replication between sites and a separate backup. - Operators and intermediaries should conduct regular threat intelligence-based red teaming exercises targeting CBDC-related systems at their organizations.51 - Recommend pragmatic, gradual resilience upgrades in line with adoption without compromising security architecture. Principle 3: Minimize the attack surface through proper design and implementation - Assume targeting by highly sophisticated threat actors, including nation-states; minimize attack surface by implementing only strictly necessary functionalities and continuous identification and remediation of weaknesses. - Design implications: - Governance: clear organizational hierarchies, responsibilities, and policies for in-house and outsourced services. - Technology: avoid unnecessary service access points; adopt zero-trust approaches; use strong, standards-based, potentially quantum-resistant cryptographic algorithms. - Balance security with functionality and user experience; rigorously test features such as offline availability and APIs for interoperability while weighing added cyber risks. - Enforce secure program design, coding, integration, test, and validation practices; validate all input and eliminate race conditions.52 Principle 4: Resilience requirements should be comprehensive - Cyber resilience is an interplay among supervision, organization, cooperation, and technology, supported by comprehensive regulation; overlap in risk mitigation across elements is preferable. - End users who are physical persons require awareness training and user-friendly security recommendations rather than supervisory or organizational controls. - Technical design best practices to embed from the start: built-in redundancies, loose coupling, high cohesion, comprehensive exception handling, fault isolation, fast failover, graceful degradation, continuous deployment, and ongoing effectiveness testing. - Note: over 80 percent of cyber incidents are due to the human element (unintentional errors, reckless practices, manipulation, malintent); ongoing training and risk awareness across all stakeholders should be reinforced by rigorous compliance testing. ### Foundational requirement overview - Before introducing a CBDC, jurisdictions should have foundational cyber risk management capabilities in place; these capabilities are essential before moving to large-scale production. - Upfront capacity building is preferable to managing potential financial stability and economic fallout from inadequate preparation. *ftnea2024003 - 1. Weak visibility of security vulnerabilities in interconnected systems as they may be governed* ### 1. There is an established legal framework to support enforceable corrections of security noncompliance ### 1. There is an established legal framework to support enforceable corrections of security noncompliance ### Key baseline findings - 1. There is an established legal framework to support enforceable corrections of security noncompliance and to prosecute cybercrime. - 2. All legal entities operating the core CBDC infrastructure are clearly within the remit of financial regulatory and supervisory agencies. - 3. Regulation or guidance on operational, technology, and cyber risk management in the financial sector exists and has been enforced for some time (for example, two to three years). - 4. Licensing requirements for new entrants include operations, technology, and cyber risk management criteria. - 5. CBDC-specific regulation that considers operations, technology, and cyber risk is passed. ### Supervisory Capabilities - 1. Supervisory authorities have the capacity to: - (1) regulate technology and cyber risk management in the financial sector; - (2) assess technology and cyber risk in payment systems or other FMIs and various financial institutions, both in licensing new entrants and in the supervision of incumbents; - (3) assess systemic cyber risk; and - (4) take effective action in mitigating such risks. ### Organizational Capabilities - 1. Financial sector authorities are sufficiently resourced to effectively discharge their regulatory and supervisory responsibilities regarding cyber risk. - 2. The following organizations are established and operational in the jurisdiction: (1) Computer Emergency Response Team (CERT), (2) Financial Intelligence Unit, and (3) Data Protection Agency and (4) Customer Protection Agency. - 3. Physical security measures are in place to protect systems from physical threats, unauthorized access, disasters, and sabotage. - 4. There are mechanisms to test business and service continuity in the face of severe but plausible scenarios. - 5. There is organizational capacity in the jurisdiction to provide CBDC first-line technical support and helpdesk services in local language(s). - 6. There is relentless focus on ongoing cyber risk training and awareness at all levels of the organization. - 7. There is a mechanism to grow a talent pipeline through universities, vocational, and exchange programs. ### Cooperation Capabilities - 1. There is an established cooperation between financial regulatory, supervisory, law enforcement, data protection, national security, and critical infrastructure authorities; or between branches of authorities with such responsibilities. - 2. There are established relationships with peer organizations in relevant foreign jurisdictions that can be leveraged in case of cross-border CBDC issues. ### Technical Capabilities - 1. Domestic telecommunications services are widely available and reliable (without major/frequent outages). - 2. International data communication lines have built-in redundancy, especially if parts of the CBDC infrastructure are cloud-based and located in another jurisdiction. - 3. There is data center capacity available for core CBDC IT infrastructure elements in the jurisdiction at Tier III level of resilience; and Tier IV if the CBDC is projected to be systemic as a payment system. ### Good Practices — Regulatory - 1. There is a financial sector cybersecurity strategy, ideally based on a national cybersecurity strategy. The former should ideally address CBDC resilience. - 2. Once widely in use, CBDC is designated as critical infrastructure, and its protection is addressed in the sectoral and national strategies. - 3. Regulators issue clarifications on requirements and expectations of CBDC core system and processing infrastructure operators and intermediaries and consult with the stakeholders on a regular basis. - 4. The supervisory or oversight remit is extended to critical third-party service providers of CBDC core system, processing infrastructure operators and intermediaries. - 5. In addition to entities within the remit of financial regulators, there are proportional cyber resilience recommendations and requirements for merchants imposed by other authorities with appropriate remit or industry standard setters (for example, Payment Card Industry Security Standards Council). - 6. There is easy to understand cybersecurity guidance for end users; and it is widely disseminated over various channels on an ongoing basis. - 7. In terms of cyber risk, CBDC regulation imposes at least the same controls as those used in systemic payment systems, clearly delineates the roles and responsibilities of core and intermediary nodes and facilitates a defense-in-depth approach to security. ### Good Practices — Supervisory and Oversight - 1. There are cybersecurity experts specialized in payment systems and with a sound understanding of CBDC at the supervisory and/or oversight authority. - 2. Cyber risk supervision and oversight is risk-based and forward-looking, aligned with the goals of the sectoral cyber strategy, and considers strategic threat intelligence. - 3. Off-site supervision and oversight of the CBDC and processing infrastructure operators is performed in a continuous manner and include assessments against the CPMI-IOSCO guidance on cyber resilience for FMIs. - 4. On-site examinations of the CBDC and processing infrastructure operators are conducted regularly. - 5. The CBDC core system and processing infrastructure operators are required to conduct business continuity and security tests regularly, preferably according to a well-established framework. - 6. Cyber risk supervision and oversight of the CBDC and processing infrastructure operators considers supply chain risk. - 7. There is a comprehensive cyber incident reporting regime in place including clear definitions of what constitute reportable incidents, deadlines, required content of reports, secure reporting platform, and follow-up process. - 8. Supervisors follow up reported cyber incidents and take corrective action to address root causes. - 9. Supervisors encourage cyber incident information sharing among financial services entities without inserting themselves in the process. - 10. Supervisors facilitate industry-wide cyber crisis exercises, which are conducted on a regular basis, using severe but plausible scenarios, which include attacks against the CBDC. ### Good Practices — Organizational - 1. In case of central bank operated CBDC core system, the payment system oversight function is independent from operations. - 2. A dedicated CERT for the financial sector (“FinCERT”) is established if predefined size and complexity criteria on the financial system are met. - 3. Employees and contractors involved in CBDC system or services development, and operations undergo background checks and are required to undertake ongoing cyber risk awareness training. - 4. Assurance teams have adequate capacity and skill sets to check compliance to approved policies and standards and to detect anomalous behavior. ### Good Practices — Cooperation - 1. There is a coordination council or similar mechanism to align approaches to cyber resilience among different authorities, including incident response protocols and crisis management plans of elements of the CBDC ecosystem. - 2. The CERT and other relevant stakeholders outside the financial sector (for example, the critical infrastructure protection agency or telecom providers) are involved in financial sector cyber crisis response exercises. - 3. The critical infrastructure protection authority consults with the supervisory authority regarding the designation, risk assessment, and protection requirements of critical infrastructure in the financial sector. - 4. The agency responsible for the national cybersecurity strategy consults with the supervisory authority regarding strategic goals for the financial sector. - 5. Authorities and financial sector entities participate in cyber incident sharing and threat intelligence fora. - 6. Information sharing and cooperation in cyber incident response and recovery for business continuity, including law enforcement, extends across jurisdictions. This is important not just because cyber risk does not respect national borders but also due to the potential cross border use of CBDC systems. ### Good Practices — Technical - 1. The security architecture of the CBDC is multilayered, designed for defense-in-depth; attackers are forced to break protection layers sequentially to reach critical systems and data. - 2. The core system and processing infrastructure are fully redundant. For example, operators run CBDC systems in a multisite, fully redundant architecture (Tier III or up) with real-time data replication between sites and a separate backup. - 3. The CBDC core system is air gapped from public networks. Access logs are frequently reviewed to detect unauthorized activity. - 4. There is a dedicated, secure wide area network connecting the central and intermediary nodes of the CBDC ecosystem. - 5. Data loss related to CBDC stock and flow is not tolerated at the core and the processing infrastructure operators; and system operations are built, run, and controlled accordingly. - 6. The cryptography used in CBDC is compliant with internationally accepted standards, employs quantum resistant algorithms; and disallows use of proprietary or un-auditable cryptographic functions. - 7. If the CBDC has programmability and smart contracts then these features are strictly controlled; secure coding, version control, review, and testing procedures are enforced with automated controls. - 8. CBDC-related production, test, and development IT environments are strictly separated; and migration procedures are enforced with automated controls based on clear segregation of duties. - 9. CBDC-related systems interact according to zero-trust principles. - 10. Critical CBDC systems are developed using a security-focused methodology and undergo extensive validation and testing before release. - 11. CBDC systems are certified against relevant technical security standards. - 12. System traffic related to CBDC, and its connections is monitored 24 × 7 with automated alerts to designated persons. Technical tools based on AI to swiftly detect anomalies in large data sets. ### Cyber Resilience and CBDC Project Management - Trust is central to CBDC deployment and depends on adherence to information security Trust Principles. - An iterative and methodical approach with ongoing evaluation of options with policymakers is necessary. - A five-phase approach is recommended for CBDC implementation, also referred to as the “5P methodology.” - Key recommendation: adequate time in each project phase; focused security tests of individual systems and components should be performed as early as possible (typically the prototype phase) to discover vulnerabilities and design flaws in a timely manner. ### Vendor and implementation observations (Box 3) - Cybersecurity tests were often out of scope and deferred to future stages in live and pilot implementations. - In some EMDEs, implementations are often managed by external service providers with the intention of transferring knowledge later, which may be risky if not properly managed through contract. - Central banks in some EMDEs tend to aim for services at lower cost due to business cases for CBDC not fully developed; costs could escalate based on quality of existing network and technology infrastructure, digital readiness, and internal skill sets. - Communication gaps exist regarding security thresholds for connectivity, interfaces, and end user devices. - Laws in jurisdictions with live CBDC have been adapted to include CBDC as the legal tender but no regulatory guidance has been formalized to strengthen cyber or information security defenses. - The insights indicate limited awareness of cyber risk and its potential impact on a large public-facing national infrastructure with financial stability implications. ### Cyber risk management workstreams across the 5P methodology (Table 3 — condensed) - Phase 1. Preparation - Assess existing cyber maturity, including regulatory frameworks (data privacy, cloud usage, and so on), organizational governance, and current practices. - Identify and map cyber requirements specific to CBDC use cases across people, process, and technology including policies, threshold requirements, stakeholders’ responsibilities, and governance arrangements. - Assess current readiness and gaps for these use cases, including stakeholders involved in distribution and adoption of CBDC. - Develop initial plan to address the gaps across regulation, technology, policy, governance, and so on for all stakeholders. - Phase 2. Proof-of-Concept/Proof of Assumption - For each use case, assess feasibility of risk mitigation for all stakeholders. - Evaluate and understand new technology relevant to cyber resilience, such as privacy enhancing technology, DLT-related issues, and AI-related risks. - Identify key elements of security architecture and test readiness. - Design rulebook and governance framework. - Evaluate relevant cyber resilience measures (for example, technology: infrastructure, ledger, wallet/token, and API security architectures, protocols, and algorithms). - Develop and test (or require in case of third parties) a security-focused system development methodology. - Evaluate existing and required skill sets and capacity to undertake technology experimentation. - Lab test initial versions of systems and cyber components. - Phase 3. Prototypes - Document detailed security requirements for RFP or for the development team. - Develop resilient-by-design initial model with key security features. - Test infrastructure and application security against requirements. - Develop and test contingency, incident, and crisis management plans. - Conduct penetration tests and hackathons. - Develop business case for investment in resilience. - Phase 4. Pilot - Simulate cyber resilience in a live environment with all ecosystem participants. Create actual outages and attacks for all identified risks, and test rulebook and mitigation plans. - Use a variety of approaches: for example, independent penetration tests, red team exercises, crisis exercises, code reviews, security audits and certifications, or bug-bounties. - Fix gaps identified during tests and repeat simulations. *Source: ftnea2024003 - 1. There is an established legal framework to support enforceable corrections of security noncompliance* ### 5. Production  Robust security monitoring. ### 5. Production  Robust security monitoring. ### Key elements of production-stage cyber resilience - Robust security monitoring. - Regular cyber resilience tests. - Continuous improvement programs. - Use of existing frameworks is recommended; example cited: Polaris, Part 2: A security and resilience framework for CBDC systems (https://www.bis.org/publ/othp70.pdf). ### Findings on trust, life cycle, and technology risks - Trust is pivotal for digital currencies; digital money is susceptible to a myriad of digital risks throughout its life cycle (issuance, storage, distribution, destruction). - Life-cycle functions of digital money require systems and tools that diverge markedly from those used for traditional fiat currencies. - Core information security principles—confidentiality, integrity, and availability—must be rigorously maintained to sustain user and consumer trust. - CBDC ecosystems are interconnected with multiple points of exposure to cyber risk; securing all elements for resilience is complex but necessary for successful deployment. - Novel technologies in CBDC ecosystems (distributed ledgers, digital wallets, smart contracts, offline-functionality variants) introduce complex security considerations. - Experience to date from live implementations and experimentation has not provided sufficient insights to develop specific frameworks or guidance for resilient CBDC designs. - BIS-led projects Polaris and Sela and outputs of active experiments in advanced economies show promise and will be leveraged in future updates to this note. ### Risk mitigation and recommended technical safeguards - Given CBDC’s nature as a national currency backed by a central bank, stakes are high and require targeted mitigation strategies. - CBDC implementation offers central banks an opportunity to rethink resilience and security of critical, often legacy, IT systems. - Technical solutions and safeguards cited: - Quantum resistant cryptography. - Air-gapped data centers. - Mutable tokens. - Secure hardware elements. - Secure coding practices. - Enhanced identity and access management controls. - A holistic approach to cyber risk management is proposed through overarching principles spanning all areas of the ecosystem. ### Human element and governance - The human element (users, designers, developers, operators, custodians, auditors) plays a critical role; human behavior and practices can materially affect effectiveness and public trust. - Need for effective project management in CBDC development and deployment. - Recommendation for ongoing training, risk awareness, and early analysis of policy and design choices. ### Digital risks taxonomy (Annex 1 summary) - Digital risks arise at the intersection of people, process, and technology, internal to the institution and its supply chain. - People risk manifestations: - Insider fraud or error (malicious insiders, insecure open-source code adoption, phishing leading to cascading effects). - Data breach or improper disclosure (poor IAM controls, third-party misconfigurations). - “Key person risk” from excessive reliance on a single/small group without knowledge transfer or succession planning. - Statistic: Reportedly, over 80 percent of cyberattacks are due to the human element. - Process risk: - Inadequate or failed processes due to rapid technology adoption, failed deployments, noncompliance, inadequate assurance. - Examples: inadequate redundancy, poor oversight of internal controls, untimely software patching, infrequent disaster recovery testing. - Technology risk: - Threats and vulnerabilities from implementation, operation, maintenance of technology systems and infrastructure. - Examples: hardware failures, software bugs, network outages, incompatibility, poor scalability. - Supply chain risk: - Risks from reliance on external parties/suppliers, including concentration risk and operational risk from suppliers governed by less stringent rules. ### Comparative cyber risk exposure across payment types (Annex 2 highlights) - Three dimensions compared: Likelihood of malicious/non-malicious events; Attacker attractiveness; Attack surface. - General observations preserved from the comparison table: - E-money: Medium likelihood of events; High end-user access diversity; Low coverage of supervisory oversight; Low maturity of security control frameworks; Low adequacy of incident-management skill set; High amount of data handled; High level of adoption; Medium ecosystem complexity; Low-Medium geographical dispersion. - Crypto/Stablecoins: Medium likelihood of events (range of use cases); Low end-user access diversity; High lack of formal oversight; High maturity of security control frameworks; High adequacy of incident-management skill set; Low amount of data handled; Low adoption; High ecosystem complexity; High geographical dispersion. - rCBDC: High likelihood of events (often many, sometimes competing objectives); Medium end-user access diversity; Medium supervisory coverage; Medium maturity of security control frameworks; High adequacy of incident-management skill set; Amount of data handled: TBC as Design dependent; High level of adoption (particularly attractive to nation-states); High ecosystem complexity; Medium geographical dispersion. - Note in source: The cyber risk exposure of wholesale CBDC (w-CBDC) is much smaller compared to retail CBDC (r-CBDC) and is not captured in the overview. ### Implementation implications and next steps - Leverage BIS-led initiatives and active experiments to inform future guidance. - Adopt a mix of technical safeguards, rigorous monitoring, regular resilience testing, and continuous improvement programs during production. - Prioritize human-factor controls: training, IAM, succession planning, and incident response capacity-building. - Apply a holistic, lifecycle-based cyber risk management approach across people, process, technology, and supply chain. *Source: Authors — Cyber Resilience of the Central Bank Digital Currency Ecosystem, NOTE/2024/003.* --- _Source: https://www.imf.org/-/media/files/publications/ftn063/2024/english/ftnea2024003.pdf_