Who is accountable when a regulated broker launches crypto services under MiCA?

Accountability should sit with named owners for the service, the control environment, and the operational exceptions process. Regulators will expect firms to show who approves scope, who supervises activity, and who can halt or remediate a control failure. If accountability is shared too loosely, evidence quality and escalation discipline will both suffer.

Why This Matters for Security Teams

MiCA does not remove accountability when a regulated broker expands into crypto services, it sharpens it. The board, senior management, and control owners still need to show who approved the activity, who owns the operating model, and who can stop trading or custody functions when controls fail. That is where regulated crypto launches often unravel: the service may be approved in principle, but the evidence trail for supervision, exception handling, and remediation is fragmented.

For NHI-heavy broker environments, the accountability problem is not just policy. Crypto services depend on service accounts, API keys, signing workflows, and other credentials that must be governed as operational assets. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that regulators and auditors care about how controls are evidenced, not merely whether they exist on paper. That expectation aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance and oversight.

In practice, many security teams discover that accountability gaps surface first during an incident review, not during the product approval gate.

How It Works in Practice

For a broker launching crypto services under MiCA, accountability should be mapped across three layers: business ownership, control ownership, and operational authority. The business owner approves the service scope and risk appetite. The control owner defines how custody, trading, wallet operations, reconciliation, and access reviews are enforced. Operational authority sits with the people who can pause activity, revoke credentials, or escalate a breach without waiting for a committee.

That model works only if non-human identities are governed with the same discipline as human access. If a wallet-signing service account, exchange API key, or reconciliation token has no named owner, then no one can credibly attest to its lifecycle, rotation, or emergency revocation. NHIMG’s Top 10 NHI Issues highlights the common failure pattern: excessive privilege, weak offboarding, and poor visibility. In regulated environments, that becomes an auditability issue as well as a security issue.

• Assign a named accountable executive for the crypto service line, not a committee with diffuse ownership.
• Define a control owner for each critical process, including approvals, transaction monitoring, and secret rotation.
• Document who can invoke emergency actions, including service shutdown, key revocation, and incident escalation.
• Require evidence of periodic review for every NHI tied to the service, including service accounts and automation tokens.

Current guidance suggests aligning this structure with NIST SP 800-53 Rev 5 Security and Privacy Controls for accountable control ownership and with Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs for ownership across provisioning, rotation, and offboarding. These controls tend to break down when crypto operations are outsourced across multiple teams because no single function retains end-to-end authority over exceptions and remediation.

Common Variations and Edge Cases

Tighter accountability often increases governance overhead, requiring organisations to balance faster product delivery against clearer supervision and evidence collection. That tradeoff is especially visible when brokers use third-party custodians, outsourced wallet infrastructure, or shared platform teams. There is no universal standard for this yet, but current guidance suggests that outsourcing does not outsource accountability. The regulated broker still needs to prove who owns the risk, who monitors the control environment, and who acts when a provider fails.

One common edge case is a distributed operating model where legal, compliance, technology, and operations all sign off. That can work only if the decision rights are explicit. Another is when a crypto launch is treated like a temporary pilot. Temporary scope often leads to temporary controls, but regulators expect the same discipline for exceptions, especially where secrets, signing keys, or custodial permissions are involved. If the service uses multiple NHIs across vendors and internal automation, the control problem becomes one of traceability: who created the credential, who approved its use, and who can invalidate it now.

For audit and remediation readiness, the broker should be able to point to a single accountable owner per control domain and a documented fallback when that person is unavailable. That is the difference between shared oversight and shared ambiguity.

Related resources from NHI Mgmt Group

• How should regulated brokers prepare IAM controls before offering crypto services under MiCA?
• Who is accountable for AI agent actions under regulated environments like DORA?
• What fails when a regulated crypto issuer cannot secure its MiCA passport on time?
• Who is accountable when MiCA enforcement cites negligence in a crypto issuer?