By NHI Mgmt Group Editorial TeamPublished 2026-07-01Domain: Governance & RiskSource: SumSub

TL;DR: MiCA’s grandfathering period is still active in some jurisdictions, but full licensing will be required across the EU from July 1, 2026, and SumSub’s guide focuses on scope, licensing milestones, and AML/CFT obligations that sit alongside MiCA rather than inside it.


At a glance

What this is: This is a compliance guide for CASPs on MiCA scope, licensing timing, and the separate AML/CFT obligations that still apply.

Why it matters: It matters because identity, onboarding, screening, and evidence collection are now part of EU crypto operational readiness, not just legal interpretation.

By the numbers:

👉 Read SumSub's guide to MiCA licensing readiness and AML/CFT obligations


Context

MiCA is the EU’s crypto-asset regulatory perimeter for CASPs and issuers, but the licensing question is only part of the operational problem. The harder work is proving that onboarding, identity verification, screening, and governance evidence are consistent enough to survive regulatory review.

For identity teams, the useful distinction is between the rule set and the control evidence. MiCA may define the market access condition, while AMLD, TFR, and national laws shape the identity, due diligence, and transaction screening work that practitioners actually have to run.


Key questions

Q: How should CASPs prepare for MiCA licensing without missing AML/CFT obligations?

A: CASPs should separate the licensing work from the underlying control work. MiCA sets the market access perimeter, but AML/CFT, Travel Rule, and national rules still govern identity verification, screening, and evidence retention. The safest approach is to map each obligation to an owner, a workflow, and a document trail so the application reflects real operating discipline, not just legal interpretation.

Q: Why do MiCA readiness programmes fail in practice?

A: They usually fail when teams treat the application as paperwork instead of governance evidence. If identity verification, approvals, exceptions, and oversight are not already operating in a repeatable way, the submission becomes a narrative that cannot be defended under review. Regulators are assessing whether the business can prove control, not whether it can describe intent.

Q: What should compliance teams do when MiCA and AML rules seem to overlap?

A: They should draw a clear boundary between the two and assign obligations accordingly. MiCA covers the authorisation context, while AMLD, TFR, and national laws drive much of the identity and screening detail. Clear boundary-setting prevents control gaps, duplicate work, and misleading compliance claims during supervision.

Q: How do organisations know if their MiCA application pack is strong enough?

A: A strong pack shows that governance, control execution, and evidence retention all line up. If approvers, reviewers, and exception handlers can be traced through documented workflows and retained artefacts, the pack is far more likely to survive regulator scrutiny. Weak packs tend to lack consistency, ownership, or proof that the controls actually ran.


Technical breakdown

MiCA scope for CASPs and issuers

MiCA applies to crypto-asset service providers and issuers of asset-referenced tokens and e-money tokens when they issue, offer, or trade across the EU. That scope matters because it draws a line between market authorisation and the separate compliance work needed to support it. Teams often overread MiCA as a single compliance wrapper, but the operational reality is a layered control stack: authorisation, identity assurance, screening, recordkeeping, and jurisdiction-specific obligations all interact. The practical question is not whether MiCA exists, but whether the business can evidence the controls regulators will examine during licensing and supervision.

Practical implication: Map each CASP activity to the exact regulatory obligation and evidence owner before the licensing deadline.

AML/CFT, Travel Rule, and identity verification

The guide’s core clarification is that MiCA does not itself create AML/CFT or Travel Rule obligations. Those requirements come from AMLD, TFR, and national laws, which means identity verification and enhanced due diligence remain separate compliance functions even when they support MiCA readiness. This distinction matters because a programme can be MiCA-aware and still fail on customer due diligence, sanctions screening, or transaction-origin visibility. In practice, identity data quality and workflow consistency become the control plane for demonstrating that the crypto business can identify counterparties, screen risk, and retain the right evidence.

Practical implication: Separate MiCA licensing tasks from AML/CFT control design so identity workflows are not treated as a legal afterthought.

Why the application pack is really a governance pack

The guide points to a MiCA application pack because regulators assess more than a filing. They examine whether governance, controls, and operational readiness are coherent across the business, including who approves, who verifies, who screens, and how exceptions are handled. That makes the application package a governance artefact, not a paperwork exercise. For identity and compliance leaders, the important mechanism is evidence orchestration: policies, roles, attestations, and operational records must line up cleanly enough that the organisation can prove control, not merely claim it.

Practical implication: Build the application pack as an evidence model with clear ownership, control mapping, and repeatable review steps.


NHI Mgmt Group analysis

MiCA compliance is an identity governance problem as much as a legal one. The guide is useful because it shows that CASP readiness depends on how reliably an organisation verifies identity, documents decisions, and preserves control evidence. Licensing is the visible checkpoint, but the underlying discipline is whether identity and compliance operations can produce defensible records at the pace regulators expect. Practitioners should treat MiCA readiness as control orchestration, not document collection.

The common misconception is that MiCA absorbs AML/CFT obligations. It does not. That separation forces teams to understand which obligations sit in MiCA and which sit in AMLD, TFR, and national rules, otherwise they will design the wrong control boundaries and misstate their own compliance posture. The practitioner takeaway is that regulatory mapping must be explicit, or the control framework will look complete while still missing core obligations.

Evidence pack governance: the application itself becomes the control test when regulators want proof of governance, approvals, and operating discipline. A strong pack is not a narrative summary, it is a structured demonstration that identity, screening, escalation, and oversight all work together. This is where many programmes fail, because the business can perform the controls but cannot evidence them consistently. Practitioners should build evidence collection into the operating model before submission starts.

Crypto compliance teams should expect identity assurance to carry more weight as licensing deadlines harden. When grandfathering ends, organisations that relied on transitional flexibility will need stable onboarding, verification, and exception handling processes. The market signal is clear: compliance maturity will increasingly be judged by whether identity and governance controls are operational, repeatable, and auditable. Practitioners should align legal, compliance, and identity owners now.

From our research:

What this signals

Evidence-pack governance: MiCA programmes will be judged less by policy wording and more by whether the organisation can show repeatable identity, screening, and approval evidence on demand. That shifts the work from legal interpretation into operating discipline, where control ownership and artefact retention matter as much as the rule itself.

The identity signal for practitioners is clear: if onboarding, due diligence, and exception handling live in separate systems without a common evidence model, the licensing pack will remain fragile. A compliant posture needs one auditable path from identity verification to regulator-facing documentation, not a patchwork of local practices.

With 62% of all secrets duplicated and stored in multiple locations, per our 2025 State of NHIs and Secrets in Cybersecurity research, fragmented evidence handling is a direct governance risk. Teams preparing for MiCA should treat control evidence like any other sensitive asset and standardise where it is created, stored, and reviewed.


For practitioners

  • Map MiCA obligations to control owners Break the programme into authorisation, identity verification, screening, recordkeeping, and oversight tasks. Assign a named owner to each control so the licensing pack does not become a cross-functional blind spot.
  • Separate MiCA from AML/CFT control design Document which requirements come from MiCA and which come from AMLD, TFR, and national laws. This prevents teams from building a single control narrative that cannot withstand regulator review.
  • Build an evidence pack before submission starts Collect policy, approval, exception, and review artefacts in the same format regulators will expect. Treat the MiCA application pack as an operating record, not a one-time filing.
  • Tighten identity verification and screening workflows Review onboarding, enhanced due diligence, and sanctions screening for consistency across jurisdictions. Where human review is involved, make escalation criteria explicit and auditable.
  • Prepare for the end of grandfathering flexibility Identify entities relying on transitional arrangements and set a remediation plan before full licensing deadlines apply. The goal is to remove dependence on temporary relief before it becomes a business risk.

Key takeaways

  • MiCA readiness is not just a legal exercise. It depends on identity verification, screening, approvals, and evidence retention operating as one governable system.
  • The guide’s key clarification is that AML/CFT and Travel Rule obligations sit outside MiCA, so teams must map the controls separately instead of assuming one regulation covers the other.
  • The organisations most likely to struggle will be those that can describe compliance but cannot prove it through a structured application pack and repeatable operating evidence.

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 CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4MiCA readiness depends on controlled access and identity verification evidence.
NIST CSF 2.0GV.RM-01Regulatory mapping and ownership are central to MiCA governance.
NIST SP 800-63Identity proofing and verification underpin customer and counterpart onboarding.

Use identity proofing principles to standardise onboarding evidence across jurisdictions.


Key terms

  • MiCA: MiCA is the European Union’s Markets in Crypto-Assets Regulation, which sets the authorisation and conduct perimeter for crypto-asset service providers and issuers. In practice, it defines who can operate in the market and under what governance expectations, while other EU and national rules still shape screening and identity controls.
  • CASP: A Crypto-Asset Service Provider is an organisation that offers regulated services involving crypto-assets, such as custody, exchange, or transfer activities. For compliance teams, the key issue is that CASP status brings licensing, governance, and control evidence obligations that must be maintained continuously, not only at application time.
  • AML/CFT: Anti-money laundering and counter-financing of terrorism controls are the policies, workflows, and evidence used to prevent illicit financial activity. For crypto organisations, AML/CFT typically includes identity verification, due diligence, sanctions screening, and monitoring steps that sit alongside, not inside, MiCA.
  • Travel Rule: The Travel Rule requires certain originator and beneficiary information to travel with crypto transfers under applicable law. Operationally, it turns transaction handling into an identity and data-quality problem, because firms must collect, validate, and exchange enough information to support traceability and supervision.

What's in the full article

SumSub's full guide covers the operational detail this post intentionally leaves for the source:

  • A clearer breakdown of MiCA scope across CASPs, issuers, ARTs, and EMTs.
  • The licence-preparation checklist regulators use to assess governance and operational readiness.
  • Practical guidance on AML/CFT, Enhanced Due Diligence, and Travel Rule obligations.
  • The application pack materials needed to evidence compliance in practice.

👉 SumSub's full guide covers the licensing checklist, application pack, and compliance detail behind MiCA readiness.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-07-01.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org