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.
Why the first control belongs in the design stage
The first control is architectural, not procedural. A central bank digital currency programme needs security decisions made while custody, redemption, settlement, privacy, and supervisory access are still being shaped, because those choices determine the control surface the rest of the programme inherits. If security waits until implementation is finished, the team is no longer deciding controls, it is compensating for design decisions that have already hardened.
That is especially important in a CBDC programme because the architecture defines who can move value, who can observe it, and who can recover it. Those are not secondary features. They are core operating assumptions, and they should be tested before they become production commitments.
What “security in the architecture decision process” actually means
This control means security reviews are embedded in the earliest design choices, such as whether the platform uses segmented trust domains, how administrative authority is separated, what gets logged, what privacy boundaries exist, and how recovery works if a component fails. The question is not whether security approves a finished design, but whether the design can still change in response to security findings.
For a CBDC programme, that means the team should validate whether the proposed model can support custody controls, fail-safe recovery, privacy by design, and supervisory visibility without forcing later workarounds. A design that cannot satisfy those requirements cleanly usually becomes expensive to operate, difficult to govern, and risky to unwind.
The practical test is simple: if a control decision would be awkward to retrofit later, it belongs in architecture now. That includes settlement authority, recovery paths, administrative separation, data minimisation, and the audit evidence needed for oversight.
Why delay creates expensive operational risk
Once a CBDC system is live and value is moving, architectural mistakes stop being theoretical. They become operational constraints that affect continuity, incident response, privacy handling, and supervisory confidence. At that point, changing the design often means touching live transaction flows, authority models, or records retention behaviour.
That is why the first control is really about preserving optionality. Early security input keeps the programme from locking itself into an approach that is technically workable but operationally brittle. It also reduces the chance that privacy, custody, and monitoring requirements end up competing with one another instead of being designed together.
In our view, the most common failure is treating security as a sign-off step after product design is effectively fixed. By then, the team can still add controls, but it can no longer shape the operating model with the same freedom.
Risk and Threat Considerations
CBDC programmes concentrate trust, value movement, and supervisory obligations in a small number of architecture decisions. If those decisions are made without early security input, the result can be brittle custody paths, weak recovery assumptions, excessive visibility for operators, or privacy choices that are hard to defend after launch.
Failure mechanism: Security is deferred until after the design has hardened, so the programme compensates with overlays, manual approvals, or retrofit controls that do not fully match the underlying operating model.
Impact: The organisation inherits live exposure that is harder to contain, harder to explain to regulators, and more expensive to correct once the system is carrying real transaction volume.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01 — Policy | Security must be built into architecture decisions through policy and governance. |
| PR.AA-01 — Identity Management, Authentication, and Access Control | CBDC architecture must define who can move value and who can observe it. | |
| RC.RP-01 — Recovery Plan Execution | Early design must account for recovery before live operation begins. | |
| Recommendation — Embed security requirements in architecture governance before design is frozen. Define and enforce access boundaries during architecture design. Design recovery paths before deployment so they are testable and usable. | ||
| ISO/IEC 27001:2022 | A.5.8 — Information security in project management | Security needs to be part of the project and architecture process from the start. |
| A.8.27 — Secure system architecture and engineering principles | The answer is fundamentally about choosing secure architecture before build completion. | |
| Recommendation — Integrate information security requirements into project governance from inception. Apply secure architecture principles before implementation decisions harden. | ||
| NIST SP 800-53 Rev 5 | SA-8 — Security and Privacy Engineering Principles | The first control is to apply security engineering principles during design. |
| SA-15 — Development Process, Standards, and Tools | Security needs to be embedded in the development and design process, not added later. | |
| RA-3 — Risk Assessment | Early architecture choices should be informed by risk before deployment commitments. | |
| Recommendation — Use security engineering principles to shape the system architecture early. Require security to be part of the development process and design reviews. Assess architectural risk before finalising the design. | ||
Practitioner Guidance
What to prioritise: Put custody model, recovery model, privacy boundary, and supervisory visibility into the earliest architecture reviews. Those are the choices that determine whether later controls are native to the design or bolted on after the fact.
What to verify: Confirm that the architecture can still change after security findings are raised. If the programme cannot realistically alter key control assumptions without major rework, the architecture review has happened too late.
Decision rule: If a security requirement affects how value moves or how authority is exercised, treat it as an architecture requirement, not an implementation detail.
Practitioner takeaway: The first control is to force security to shape the design while the programme still has room to choose, because after launch the cost of correcting structural weakness rises sharply.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org