Central bank digital currency security must start before build sign-off

At a glance

What this is: This is a governance analysis of a central bank digital currency partnership, with the key finding that security and resilience need to be addressed from the earliest design stages rather than left until after build completion.

Why it matters: It matters because payment and custody controls, key management, and supervisory visibility are identity-adjacent governance problems that become far harder to correct once a live digital asset system starts moving value.

By the numbers:

• Web3 losses reached 3.35 billion in 2025, according to CertiK.
• Web3 losses reached 1.31 billion across 344 incidents in the first half of 2026, according to CertiK.
• Wallet compromise accounted for over 444 million across just 33 incidents in H1 2026, according to CertiK.
• CertiK says it has protected more than 600 billion in digital assets across more than 150 countries and regions since 2017.

Context

Digital currency projects fail most often when security is treated as a late-stage review rather than a design input. In systems that will hold real monetary value, weak key custody, limited supervisory visibility, and brittle recovery assumptions are governance failures first and technical failures second.

This article is about the National Bank of the Kyrgyz Republic’s Digital Som partnership with CertiK, but the wider pattern is the same across CBDC and digital asset programmes: if security is not embedded before launch, the organisation inherits live operational risk that is expensive to unwind.

Key questions

Q: What is the first control to put in place for a central bank digital currency programme?

A: The first control is to make security part of the architecture decision process, not a review step after build completion. That means testing custody, recovery, privacy, and supervisory visibility while the design is still changeable. If those choices are deferred, the programme inherits live operational risk that becomes expensive to unwind once value is moving.

Q: Why do custody and key management matter so much in digital asset systems?

A: Because they determine who can move value, recover access, or override controls. In digital asset environments, custody is an access-governance problem as much as a storage problem. If signing authority, recovery authority, and operational monitoring are not separated and auditable, the platform can remain technically available while becoming governance-fragile.

Q: What are the signs that a digital asset control model is failing?

A: The warning signs are delayed security review, unclear signing authority, weak evidence for supervisory oversight, and reliance on point-in-time assurance for a live system. Those symptoms show that the control model is reacting to launch pressure instead of governing the operating environment. At that stage, recovery becomes more expensive than prevention.

Q: How should regulators oversee a live digital asset ecosystem?

A: They should combine technical security review with ongoing monitoring, case generation, and evidence that can be used in compliance and inspection workflows. A live system changes over time, so oversight must be continuous rather than episodic. The goal is not just to detect anomalies, but to preserve a defensible record of what happened and why it mattered.

Technical breakdown

Why early-stage security changes the failure profile of a CBDC

A CBDC or digital asset platform is not a normal software project once it begins handling value. Design choices about settlement, custody, privacy, offline use, and supervisory access become structural controls, not implementation details. If those choices are deferred, the organisation loses the chance to test them under realistic threat models before money is live. That is why early security review changes the failure profile: it surfaces trust assumptions while architecture is still mutable. Formal verification strengthens this further by proving specified properties across all behaviours in a defined model, which is materially different from reviewing selected test cases or code paths. See the Secure Coding Guide.

Practical implication: Treat architecture review and formal verification as design-stage controls, not post-build assurance.

How custody and key management shape digital asset risk

Digital asset custody is really about who can move value and under what conditions. In practice, key management determines whether an attacker, compromised insider, or weak recovery process can authorise transactions that should never have been possible. For central bank or regulated digital asset systems, custody is not just a storage question. It is an access-governance question that links entitlement scope, operational separation, and recovery authority. If those controls are unclear, the system may be technically available while still being governance-fragile. The most important question is not whether keys exist, but whether control over them is bounded, auditable, and revocable.

Practical implication: Map signing authority, recovery authority, and operational access to separate controls and review them as a single custody model.

Why supervision and compliance tooling matters after launch

Once a digital asset system is live, the control problem shifts from build assurance to continuous oversight. Supervisory tooling exists to turn transaction, wallet, and token activity into risk signals that regulators can act on. That matters because live systems create new exposure channels over time, including changes in counterparties, asset flows, and licensing status. The governance challenge is not only detecting suspicious activity. It is preserving enough evidential quality that a regulator or oversight body can explain what happened and why it mattered. This is where operational resilience and AML/CFT oversight overlap: both require reliable monitoring, not one-time assurance. See the Board Cyber Risk Reporting Guide.

Practical implication: Build continuous monitoring and case-management into the operating model before launch, not after the first incident.

NHI Mgmt Group analysis

Early security is a governance control, not a later-stage assurance activity. The article’s central lesson is that security review placed at the end of a digital currency project cannot fix structural choices about custody, settlement, privacy, or supervisory access. In systems that will handle real value, those decisions belong in the design phase because they define the operating risk envelope. Practitioner implication: move security, resilience, and key-governance review into the architecture stage.

Custody is the identity problem hiding inside digital asset operations. Who can sign, recover, approve, or monitor value-moving activity is an access-control question even when the technology is blockchain-based. That makes entitlement scope, separation of duties, and revocation authority central to digital asset governance, not peripheral controls. A system can be cryptographically sound and still be operationally unsafe if control over keys is ambiguous. Practitioner implication: govern signing authority as a privileged identity model.

Formal verification debt: the cost of relying on review after a system’s trust model is already fixed. Formal verification matters here because it can prove properties that manual review often misses, but only if it is introduced before the design hardens. The article shows why late validation creates debt: once the system is live, weaknesses are not just technical defects, they are public trust liabilities. Practitioner implication: require proof-oriented assurance for the highest-impact system behaviours before deployment.

Regulatory supervision now depends on machine-readable evidence, not narrative reassurance. A central bank cannot supervise a live digital asset ecosystem with point-in-time reports alone. It needs monitoring, case generation, and inspection-ready evidence that can survive scrutiny from policy and compliance teams. That is the real significance of combining technical security work with AML/CFT and oversight support. Practitioner implication: design evidence generation as part of the control plane, not as an after-action report.

Digital asset governance is converging with identity, compliance, and resilience operations. The article shows that a CBDC programme cannot separate code assurance from oversight, or technical security from regulatory accountability. That convergence is now the operating model, especially where the same platform must support national payment resilience, AML/CFT, and custody assurance. Practitioner implication: organise the programme around control domains rather than project stages.

What this signals

CBDC programmes now need a control-plane mindset. The important shift is from reviewing a project to governing a live value system. That means oversight, custody, resilience, and evidence generation have to be designed together, because weak separation between those functions creates irreversible operational debt.

Formal verification belongs where failure is least tolerable. For national payment infrastructure, point-in-time review is not enough to prove that critical behaviours are safe across all relevant execution paths. Teams should reserve proof-based assurance for the highest-impact transaction and custody functions, then use it to shape the rest of the control model.

For practitioners

• Embed security in the design phase Bring security and resilience review into architecture, key management, and supervisory design before any launch decision is finalised.
• Separate custody from operational access Define who can sign, who can recover, and who can monitor the system, then enforce those roles as distinct privileged functions.
• Use formal verification for high-impact behaviours Apply mathematical proof to the behaviours that matter most, such as value transfer, access boundaries, and recovery logic.
• Build continuous monitoring into supervision Create case-management and inspection-ready evidence from transaction, wallet, and token monitoring rather than relying on point-in-time review.

Key takeaways

• The article shows that digital currency risk grows when security is treated as a final checkpoint instead of a design constraint.
• It also ties late-stage assurance failures to real-world loss patterns, especially where wallet compromise and key control dominate the damage.
• For practitioners, the implication is to govern custody, verification, and supervision as a single operating model before launch.

Related NHI Mgmt Group resources: Identity and NHI Security Business Case Guide · Board Cyber Risk Reporting Guide · Secure Coding Guide · Risk Register Template

Key terms

• Formal Verification: Formal verification is the mathematical proof that a protocol or system model satisfies defined security properties. It is useful for proving design logic, but it does not by itself validate real-world configuration, integration, logging, or runtime behaviour.
• Digital-asset custody: The controlled holding and safeguarding of digital assets on behalf of an organisation or customer. In practice, custody includes key management, access separation, approval paths, and recovery processes that determine whether value can be moved safely and under accountable control.
• Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
• AML/CFT Monitoring: AML/CFT monitoring is the ongoing analysis of transactions and activity to identify suspicious patterns linked to money laundering or terrorist financing risk. In digital asset environments, it combines transaction oversight, behavioural signals, and evidence handling so that regulators and institutions can investigate activity with defensible context.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, human identity, identity lifecycle, and secrets management. It helps practitioners connect identity control to the broader security programmes they already run.