MiCA Security Obligations: Entity Scope, DORA and Audit Evidence

Who is in scope

Start with the legal entity and the activity it performs. A token issuer, a custody provider and a software contractor do not acquire the same duties merely because they work on the same application. A useful assessment of MiCA security obligations maps each activity to the relevant entity before turning that assessment into engineering tasks.

MiCA distinguishes crypto-assets other than asset-referenced tokens and e-money tokens from those specific token categories. It also regulates crypto-asset service providers. Those distinctions affect the applicable requirements. A smart contract's programming language does not decide the entity's regulatory classification.

Article 2 sets the scope and exclusions. Its provisions need to be read alongside the definitions and the actual service model. A project should not infer an exemption from its own use of the word decentralized. Identify who operates the service, who controls changes and how clients access the activity, then obtain a reasoned classification for that arrangement.

This is a security implementation guide to the cited framework, not a determination that a particular project is authorized. The entity's counsel or compliance lead should resolve legal classification with the relevant authority where necessary. Engineering can then map the resulting duties to systems, controls and evidence without quietly deciding a legal question through an audit checklist.

The distinction matters during procurement. A request for a MiCA audit can mean a code review, a governance assessment or preparation of evidence for an authorization process. Those are different engagements. Require the requester to name the entity, applicable provisions and intended use of the deliverable before comparing quotes.

Where MiCA expressly points to DORA

Method

Source and selection

Every operative Article 1 through 149 in original Regulation EU 2023/1114 HTML. DOM boundaries exclude recitals, annexes and footnotes. Count exact textual references to 2022/2554.

Retrieved

2026-09-05

Observation

A cross-reference census of the original act, excluding recitals, annexes and footnotes. This is not a count of all security duties.

Results

The original MiCA text contains explicit references to Regulation 2022/2554 in Articles 34 and 68. The former addresses governance arrangements for asset-referenced token issuers; the latter addresses governance arrangements for crypto-asset service providers.

The result is useful as a reading route. It shows why a team cannot treat MiCA and the Digital Operational Resilience Act as unrelated workstreams. It does not mean that only those articles matter for security or that every entity reading them has identical obligations. The surrounding provisions and the applicable regulatory instruments still determine the actual duty.

Limits

• The population is the original Regulation EU 2023/1114, with 149 operative articles. It is not a consolidated compliance checklist.
• Counting an exact regulation number misses indirect duties and requirements expressed in implementing or delegated measures.
• Legal applicability, proportionality and entity-specific exceptions require separate analysis.

The reproducible record is kept in the repository: seo/research/articles-32-41-2026-09-05/surveys.py and seo/research/articles-32-41-2026-09-05/survey-35.json. These file paths are not public downloads.

Security and ICT requirements

MiCA Article 68 requires crypto-asset service providers to address continuity and regularity with appropriate resources and procedures, including resilient and secure systems under the referenced resilience framework. It also addresses response and recovery planning and the protection of data. These are operating obligations, not just requirements to possess a penetration-test report.

DORA establishes a broader framework for ICT risk management. Its governance provisions place responsibility with the management body. Its testing provisions describe a program of appropriate assessments and tests, while its third-party provisions address reliance on external ICT services. The applicability and proportionality provisions matter when deciding the exact implementation.

Translate these duties into named controls. A business continuity plan needs the services it protects, the dependencies it assumes and a way to test recovery. A risk register needs an owner and evidence of review. An access-control policy needs a deployed permission model that can be inspected. The document and the operational implementation should describe the same system.

Commission Delegated Regulation 2025/299 supplements the continuity requirements for crypto-asset services. It addresses how the business continuity policy is established and the measures it contains. Read this adopted instrument when preparing the policy; an earlier consultation draft is not a substitute for the adopted text.

A permissionless network can fail or degrade outside the service provider's direct control. The engineering question is how the provider handles that dependency while preserving its own obligations. Record which client operations depend on the network, how an interruption is detected and what communication or recovery actions remain available. The existence of an external dependency should not become an undocumented exception to the continuity plan.

For asset-referenced token issuers, Article 34 separately addresses operational risk, continuity, internal controls and audit arrangements. Do not copy a service-provider checklist into the issuer's file without checking the relevant provisions and token model. Similar control names can sit under different legal duties.

What an audit does and does not satisfy

A technical assessment can provide evidence about a defined system at a defined time. It can identify weaknesses in contract logic, an application interface or infrastructure configuration. Its scope and methodology determine what the report supports. It does not itself grant authorization or establish compliance with duties it never assessed.

DORA's testing framework includes several assessment methods. A source-code review can be one part of that work, but continuity, governance and supplier management are not reducible to a list of code defects. The procurement document should distinguish the technical testing engagement from the wider evidence program.

1. Identify the legal entity, service and provisions that apply.
2. Assign systems and owners to the resulting security obligations.
3. Perform the appropriate assessments and record remediation and recovery results.
4. Have accountable legal and operational owners evaluate remaining gaps.

Ask a provider what it will test and what it will deliver. The report should identify targets, assumptions, exclusions and the process for validating fixes. If a proposal promises MiCA compliance from a smart contract audit alone, require an explanation of how the engagement addresses the non-code duties. A marketing phrase is not an evidence mapping.

Pharos Production's cybersecurity assessment and compliance-readiness services page describes application testing, source review, cloud configuration review and secure-development work. These activities can support the technical evidence needed by an in-scope organization. Agree which controls and artifacts the engagement covers; the service description does not establish regulatory approval or complete MiCA compliance.

Our Web3 cybersecurity service guide separates those technical workstreams in more detail. The member profile identifies the provider, while the audit scoping hub helps frame a concrete request. Keep the legal decision and the technical acceptance criteria visible in the same project record.

An unresolved finding also needs a governance decision. A delivery date is not a reason to rename an open weakness as fixed. The responsible owner should document the consequence, interim control and plan, then determine how that gap affects the organization's legal and operational readiness. The auditor should retain the actual technical status.

Documentation to keep

Maintain an evidence index that connects each applicable requirement to the control, owner and current artifact. That index should make stale evidence visible. A report from an earlier architecture may still explain historical work, but it should not silently represent the present production environment.

The system inventory should identify the client services, data flows and critical dependencies relevant to the assessment. Include administrative access and deployment authority as well as ordinary user flows. A service can depend on a signing system or release pipeline that is absent from the customer-facing architecture diagram.

Retain testing scope, source revisions, environment details and remediation records. The audit RFP guide explains how to agree these artifacts before work begins. A report title and invoice are weaker evidence than a reproducible statement of what was assessed and how the resulting findings were handled.

MiCA Article 68 also contains a specific recordkeeping provision for service-provider activities. Do not confuse that provision with a universal retention period for every engineering log. The organization's retention schedule must identify the record type, relevant rule and any other applicable legal constraints. A copied duration without a record classification can be wrong in either direction.

Document how evidence is protected. A penetration-test report can expose sensitive architecture or reproduction details. The organization needs controlled access and a way to provide the appropriate material to authorized reviewers. Public marketing summaries should not be the only surviving record, but neither does an evidence program require every technical artifact to be public.

A useful readiness review samples the index in both directions. Starting from a requirement should lead to a current artifact and owner. Starting from a production control should lead back to the requirement or risk it addresses. Broken links identify work that is documented without implementation, or implementation whose purpose and acceptance have been lost.

Build an evidence record around the actual service

Consider a hypothetical provider that operates a custody service through an application, a signing system and an outsourced infrastructure environment. A contract assessment may be relevant to one component. The evidence owner still needs to identify the other components, their responsibilities and the obligations that apply to the authorized service. This example illustrates scoping; it does not determine any particular company's legal status.

Start the record with the legal entity and the service being assessed. Connect each applicable requirement to a control owner and to an artifact showing what the control does. If a supplier performs part of the work, identify the agreement and evidence available to the provider. A supplier's general security statement should not silently stand in for a service-specific control assessment.

Record the difference between an intended control and an operating control. A policy describes intended behavior. The review record shows whether the process ran and what it found. A testing plan can identify future work, while a completed test provides a dated result and any unresolved exception. Keep those states distinguishable when preparing material for internal review or a competent authority.

Technical remediation also needs a legal handoff when it affects the service boundary. If a finding leads the team to change custody arrangements or a material supplier relationship, the engineering owner should identify that change to the responsible legal and compliance teams. The vulnerability report alone cannot settle the resulting authorization or contractual questions.

Use a versioned applicability decision. State who assessed the entity's position, which sources were current at that time and what change would require a new review. That prevents a transition-era note from being reused as present-day authorization evidence after the relevant period has ended.

Where evidence is unavailable, retain the gap and its owner rather than substituting a generic certificate or badge. The next useful action might be a scoped test, a supplier clarification or an updated legal assessment. Assigning that action is more informative than marking an entire requirement complete because one security document exists.

Timeline

The main application dates are already historical at the time of this review. A team preparing a launch in 2026 should not rely on an old transition-period article without checking whether the period has ended and whether the entity obtained the authorization it requires.

Member States could shorten or decline the relevant transitional regime. ESMA's statement dated June 23, 2026 addresses the end of that period and the orderly wind-down of unauthorized service providers. Its expectations include protecting clients during the wind-down. The statement does not turn an unapproved application into permission to continue ordinary operations.

ESMA's DORA question-and-answer entry also distinguishes authorized MiCA service providers from entities that had relied on the transition under national law. Read that explanation in its temporal context. A clarification about transition-period status should not be carried past the end of the period as though it created a permanent exemption.

For the engineering plan, work backward from the actual decision the organization must make. Identify which evidence is needed for the service, which controls are already operating and which tests remain incomplete. Assign a responsible owner to each gap and retain the review date. The immediate task is a current, entity-specific evidence assessment, not the production of another generic compliance badge.