A CBDC design is failing if it cannot support transactions during outages, poor network coverage, or other disruption. Cash works because it remains usable anywhere, anytime. If the digital design depends entirely on constant connectivity, or if offline transactions cannot be secured against double spending and unauthorised money creation, it has not achieved cash-like resilience.
What does cash-like resilience actually require?
Cash-like resilience is not just about being digital, it is about being usable when normal dependencies fail. A CBDC design starts to fall short if it cannot complete or queue payments during outages, local network loss, or degraded infrastructure. The core test is whether the payment can still function in realistic failure conditions without collapsing into a single point of dependence.
A design also needs to preserve practical availability across ordinary life conditions, such as weak coverage, terminal failure, or temporary service interruption. If the user experience only works when every layer is online and responsive, the system is more fragile than cash even if it is secure in steady state.
Which failure signs matter most?
The clearest sign is an absolute reliance on constant connectivity. If the payment path cannot degrade gracefully, then the design has not matched cash’s offline resilience. Another sign is that the system works only in controlled test environments but not in real-world retail, transit, rural, or emergency conditions.
Watch for constraints that make the system behave like a remote account rather than a transferable instrument. If transaction finality, value transfer, or spending permissions break down whenever the network is unavailable, the CBDC is functionally less resilient than physical cash.
A second warning sign is weak offline integrity. If the design cannot prevent double spending, replay, tampering, or unauthorised money creation when disconnected, then offline support is not robust enough to be trusted at scale. Resilience is not achieved by allowing offline use alone, it is achieved by allowing offline use without opening a new fraud path.
Why offline security and recovery are the real test
For a CBDC to approach cash-like resilience, it must balance availability with integrity. Offline capability is only credible if the system has a reliable way to bound loss, reconcile transactions later, and detect abuse after reconnection. If those controls are missing, the design may remain operational in theory but still fail under pressure.
That is why resilience should be assessed as both a continuity problem and a trust problem. The payment rail must survive outages, but it also must survive the security consequences of being offline. A solution that is easy to spend when disconnected but impossible to reconcile safely is not resilient in the cash sense.
Risk and Threat Considerations
When resilience depends on network availability, the main risk is service interruption turning into payment interruption at scale. If offline mode is weakly controlled, attackers or even routine users can exploit the gap between local execution and later settlement to create double-spend pressure or unauthorised value creation.
Failure mechanism: The design either has no dependable offline path, or it allows offline spending without strong limits, secure synchronization, and later validation, so the system cannot preserve both continuity and integrity under disruption.
Impact: The CBDC becomes less usable than cash during outages, and its offline mode can become a fraud amplifier rather than a resilience feature.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Planning | Cash-like resilience depends on operating through outages and recovering cleanly after disruption. |
| PR.IR-04 — Resilience | The subject is explicitly about resilience under degraded connectivity and disruption. | |
| PR.AA-05 — Identity Management, Authentication, and Access Control | Offline transfers still need control over who can initiate or spend value safely. | |
| Recommendation — Define and test recovery paths that preserve payment continuity during outages. Engineer payment services to tolerate disruption without losing core functionality. Bind offline payment authority to verified access and enforce limits. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | Outage handling and continuity planning are central to cash-like availability. |
| SI-10 — Information Input Validation | Offline transaction integrity depends on rejecting tampering, replay, and invalid value states. | |
| IA-5 — Authenticator Management | Resilient offline payment design still depends on secure credentials, tokens, or device-bound authenticators. | |
| Recommendation — Document and exercise contingency procedures for payment outages and degraded service. Validate offline transactions so malformed or replayed messages are rejected. Rotate and protect authenticators used to authorize offline value transfer. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | The question is fundamentally about whether the payment system stays usable during disruption. |
| A.8.13 — Information backup | Offline or disrupted operation requires recovery of transaction state and reconciliation data. | |
| Recommendation — Build and test ICT continuity measures that keep payment services available in outages. Maintain recoverable records so offline payments can be reconciled after service restoration. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | Recovery and restoration are essential when connectivity or service availability fails. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Weak configuration can break offline operation or expose double-spend pathways. | |
| Recommendation — Test recovery procedures that restore transaction data after disruption. Harden payment components so resilience features cannot be bypassed by misconfiguration. | ||
Practitioner Guidance
What to verify: Test the design under genuine outage conditions, not just simulated latency. A credible cash-like model should still support bounded, auditable payments when network access is absent, and it should show how the system prevents duplicate use of the same value after reconnection.
What practitioners underestimate: Offline resilience is usually lost at the boundary between user convenience and settlement assurance. If the design cannot explain how it limits offline risk without making every transaction depend on live connectivity, it has probably not matched cash’s resilience target.
Practitioner takeaway: The key question is not whether the CBDC is technically offline-capable, but whether it remains usable, secure, and reconcilable when the network is down.
Related resources from NHI Mgmt Group
- What are the signs that a hybrid RAG and MCP design is failing?
- What are the signs that a cyber resilience programme is failing across organisational boundaries?
- What are the signs that a physical security programme is failing against covert entry attempts?
- What are the signs that a privacy by design programme is failing?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
