TL;DR: The National Bank of the Kyrgyz Republic has signed an MoU with CertiK to support Digital Som security and digital asset oversight, covering blockchain security, formal verification, operational resilience, AML/CFT, custody, supervision, and training. The partnership reflects a wider shift: CBDC and digital asset programmes now need governance and monitoring built in from the start, not added after launch.
At a glance
What this is: CertiK and the National Bank of the Kyrgyz Republic have agreed a long-term partnership focused on Digital Som security, digital asset oversight, and regulatory capability building.
Why it matters: It matters because CBDC programmes and digital asset supervision create governance, custody, and resilience obligations that identity, compliance, and security teams cannot defer until after deployment.
Context
A central bank digital currency programme changes the security problem from protecting a product to governing part of the monetary system. Once digital currency, custody, and oversight become operational priorities, the control model has to cover resilience, auditability, licensing, and risk supervision from the outset.
This article is about that governance shift in a regulated financial context. The identity angle is indirect but real: supervisory access, custody workflows, and compliance operations all depend on controlled access, accountable roles, and well-scoped operational permissions.
Key questions
Q: How should central banks govern digital currency security before launch?
A: Treat digital currency security as an operating model issue, not a technical add-on. Central banks need defined ownership for custody, oversight, resilience, and escalation before pilots scale. That means separating privileged roles, logging supervisory activity, and making recovery and intervention paths explicit so the system remains auditable under stress.
Q: Why do CBDC programmes need both technical assurance and operational resilience?
A: Because a system can be correct in design and still fail in operation. Formal verification helps prove protocol behaviour, but resilience depends on live monitoring, recovery, and controlled intervention. Without both, the programme may satisfy engineering concerns while still leaving supervisory, custody, or availability gaps that matter to regulators and the public.
Q: What breaks when supervisory access is not tightly controlled?
A: Oversight becomes difficult to trust if staff can view, approve, and intervene without clear role boundaries or audit trails. In a digital asset environment, that creates accountability gaps, weakens separation of duties, and increases the chance that compliance decisions are made outside the intended control model.
Q: Which matters more for regulated digital assets: oversight tooling or governance design?
A: Governance design comes first. Tooling can support monitoring and compliance, but it cannot fix unclear ownership, excessive privileges, or weak accountability. For regulated digital assets, the right sequence is to define controls, responsibilities, and escalation paths, then select the tooling that fits those rules.
Technical breakdown
CBDC oversight as a governance problem
A CBDC programme is not just a payments design exercise. It combines monetary operations, platform resilience, security assurance, and rule enforcement in one system, which means technical controls and regulatory controls have to develop together. For a central bank, the hard part is not only cryptography or transaction integrity but also who can approve, monitor, and intervene in the system across its lifecycle. That makes the programme closer to critical infrastructure governance than a simple digital product rollout.
Practical implication: define operating, security, and supervisory control ownership before pilot activity expands.
Why formal verification and operational resilience matter together
Formal verification reduces uncertainty about whether a system behaves as intended, but it does not by itself prove operational resilience. In a CBDC context, resilience also depends on monitoring, recovery, custody controls, and the ability to detect misuse or failure across live operations. Security teams should treat these as complementary layers: correctness in the code or protocol, then assurance in the running environment. If either is missing, the trust model remains incomplete.
Practical implication: pair design assurance with runtime monitoring and recovery controls, not one or the other.
Digital asset oversight needs supervisory access control
Supervision and compliance tooling only works when the underlying access model is disciplined. Regulatory oversight depends on role separation, auditability, and tightly bounded privileges for staff who can view, approve, or intervene in digital asset operations. That is where identity governance intersects the programme directly: oversight functions are only credible when privileged actions are attributable, reviewable, and constrained to their intended scope.
Practical implication: govern supervisory accounts as privileged identities with explicit approval, logging, and review.
NHI Mgmt Group analysis
CBDC security must be designed as an operating model, not a post-launch control layer. The article shows a central bank and a security specialist treating Digital Som as infrastructure that needs embedded assurance, not bolt-on review. That approach is the right one because currency systems carry availability, integrity, and supervisory expectations at the same time. Practitioners should read this as a signal to align governance, custody, and resilience before scale.
Supervisory access is a privileged identity problem as much as a compliance problem. Any platform used for digital asset oversight creates high-value administrative pathways, and those pathways need lifecycle control, auditability, and separation of duties. This is where the identity bridge is strongest: oversight fails if privileged roles are vague or overbroad. Practitioners should model supervisory accounts, approval rights, and escalation paths with the same discipline used for PAM.
Digital asset programmes are moving from experimentation to regulated operations. The partnership reflects a wider market pattern in which central banks and regulators are building security and compliance into digital currency initiatives early. That shifts the practitioner question from whether to add controls later to how to govern them now. Teams should expect more scrutiny of custody, monitoring, and licensing readiness as these programmes mature.
Security vendors entering sovereign finance need to prove governance depth, not just technical capability. The relevant test is whether their assurance model can support supervision, operational resilience, and policy constraints in a highly regulated environment. For practitioners, that means evaluating not just code-level analysis but whether the surrounding control model can support audit, accountability, and long-term oversight.
What this signals
Digital currency programmes are shifting into the same governance category as critical financial infrastructure. That means practitioners should expect control expectations around auditability, resilience, and accountable operations to tighten before public rollout. The practical challenge is to make those controls visible in the operating model, not just in design documentation.
Supervisory access will need the same scrutiny as any other privileged workflow. Once oversight tools can influence live currency or custody operations, role boundaries and approval paths become part of the security perimeter. Teams that do not govern those permissions early risk building fragile controls around a high-trust process.
For practitioners
- Define supervisory privilege boundaries Map every role that can view, approve, pause, or override digital asset operations, then restrict those rights to the smallest practical scope.
- Separate custody from oversight Keep custody controls, supervisory review, and policy enforcement on distinct approval paths so no single role can both operate and self-authorise.
- Build resilience into the operating model Test failure recovery, monitoring escalation, and manual intervention paths before production use, especially where currency availability is a public trust issue.
- Treat compliance tooling as privileged infrastructure Apply strong account management, logging, and review to any supervision and compliance solution used for digital asset oversight.
- Document regulatory and security ownership Assign named accountability for custody, licensing support, AML/CFT alignment, and incident escalation so operational gaps do not sit between teams.
Key takeaways
- Digital Som security is being treated as a governance and resilience problem, not simply a blockchain design issue.
- The partnership highlights how oversight, custody, and compliance controls must be built into regulated digital currency programmes early.
- Practitioners should define privileged supervisory roles, separate approval paths, and test recovery before digital asset operations scale.
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 governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Oversight of cybersecurity risk | The article centres on governance, oversight, and resilience for a regulated digital currency programme. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Supervisory and compliance workflows depend on tightly scoped privileged access. | |
| Recommendation — Establish oversight, assurance, and accountability for the digital currency operating model. Restrict supervisory permissions to approved roles and review them on a defined cadence. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Oversight tooling and custody operations require minimal and separable privileges. |
| AU-2 — Event Logging | Auditability is central to regulated oversight and incident reconstruction. | |
| Recommendation — Apply least privilege to any account that can monitor, approve, or intervene in digital asset operations. Log supervisory actions and administrative changes so every privileged intervention is attributable. | ||
| CIS Controls v8 | CIS-5 — Account Management | The partnership implies a need to govern high-value operational and supervisory accounts. |
| Recommendation — Inventory and govern privileged accounts used for custody, oversight, and compliance functions. | ||
Key terms
- Central Bank Digital Currency: A central bank digital currency is a digital form of sovereign money issued by a central bank. It is distinct from private stablecoins because it carries public monetary authority and policy implications. In policy discussions, it often raises questions about financial system design, privacy, access, and the balance between innovation and control.
- Digital Asset Oversight: Digital asset oversight is the supervisory control function used to monitor, assess, and regulate activity involving tokens, custody, and related financial operations. In practice it depends on auditable access, policy enforcement, and a clear division between operational execution and supervisory authority.
- 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.
- Supervisory Access: Supervisory access is privileged access used to review, approve, or intervene in regulated operations. It is high trust by design, which means it must be tightly scoped, attributable, and separated from day-to-day operational control to preserve accountability.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, IAM, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity control to broader security governance across regulated environments.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org