CRA focuses on secure digital products and manufacturer responsibilities. DORA focuses on the resilience of financial entities and their ICT operations and dependencies. The frameworks can overlap through technology supply chains, but CRA product conformity does not replace DORA operational-resilience duties.
CRA Regulates Products; DORA Regulates Financial Operational Resilience
The most useful distinction is the regulatory object. The CRA establishes cybersecurity requirements for products with digital elements made available on the Union market and gives duties to manufacturers, importers, distributors and other relevant economic operators. DORA, Regulation (EU) 2022/2554, creates a digital operational resilience framework for covered financial entities. It requires those entities to manage ICT risk, detect and handle ICT-related incidents, test digital operational resilience and manage risks arising from ICT third-party service providers. DORA has applied since 17 January 2025. A bank using commercial software therefore asks DORA questions about resilience and third-party dependence while the manufacturer of the software can separately need to answer CRA questions about the security and conformity of the product.
DORA Starts With Financial-Entity Status
DORA's scope analysis begins with whether the organisation is one of the financial entities covered by the Regulation. Its framework reaches numerous financial-sector categories and establishes proportionate ICT risk-management requirements for those entities. The financial entity must understand which business functions depend on ICT, identify assets and dependencies, assess vulnerabilities and cyber threats, maintain protection and prevention measures, develop continuity and recovery capabilities and document its resilience framework. The analysis is therefore organisation and service oriented. A company does not become subject to DORA merely because it manufactures a connected product. Conversely, a financial entity can have extensive DORA duties even where it manufactures no products at all.
CRA Starts With the Product and Economic-Operator Role
CRA analysis begins from a different direction. Teams determine whether there is a product with digital elements within scope, how that product is made available on the Union market, and which organisation acts as manufacturer, importer or distributor. The manufacturer then addresses product cybersecurity risk, Annex I requirements, vulnerability handling, security updates, technical documentation, support-period commitments and conformity assessment. These obligations follow the product and the economic-operator role rather than the customer's status as a financial entity. A software product supplied to a bank can therefore remain subject to CRA analysis because it is a product with digital elements, while the bank separately evaluates its use of that technology under DORA.
An ICT Vendor Can Sit Between Both Frameworks
The technology supply chain creates an important practical overlap. DORA defines ICT third-party service providers and imposes extensive requirements on financial entities for managing contractual arrangements and dependencies on ICT services. Certain providers can also fall within the EU oversight framework for critical ICT third-party providers. Separately, a technology company can be a CRA manufacturer when it develops and markets a covered product with digital elements. The same commercial relationship may therefore involve product-security evidence generated by the vendor under the CRA and operational, contractual and resilience controls required from the financial customer under DORA. The legal roles are not interchangeable: being a CRA manufacturer does not automatically make an organisation a critical ICT third-party provider under DORA, and the reverse is also not automatic.
CRA Product Security Can Support DORA Supply-Chain Risk Management
The CRA itself recognises the connection with DORA. Its recitals state that the CRA can facilitate compliance with supply-chain security obligations of entities within the scope of Regulation (EU) 2022/2554 when they use products with digital elements. This makes product-level CRA evidence useful to financial-sector procurement and supplier-assurance processes. A financial entity may want information on secure development, vulnerability handling, security updates, support periods and product security controls when assessing an ICT dependency. That does not mean CRA conformity is a substitute for the DORA third-party risk framework. DORA also addresses contractual provisions, concentration and dependency risks, exit strategies, continuity, monitoring and the operational importance of the ICT service to the financial entity.
The Incident Reporting Regimes Have Different Triggers
Both regulations include incident-related obligations, but the events and regulated actors are different. CRA Article 14 requires manufacturers to report specified actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. DORA requires financial entities to detect, classify and report major ICT-related incidents under its financial-sector framework and related technical standards. A vulnerability in a commercial product could therefore create an Article 14 assessment for the manufacturer while exploitation of that vulnerability at a bank could separately create a DORA incident assessment for the financial entity. Organisations should avoid assuming that one regulatory report automatically discharges every other reporting obligation. A reporting matrix should identify the legal entity, event trigger, competent authority, required information and applicable timetable for each regime.
DORA Goes Much Further Into Operational Resilience
DORA contains areas that are not equivalents of CRA product conformity. Financial entities need an ICT risk-management framework, governance and accountability arrangements, business continuity and recovery capabilities, testing programmes and procedures for learning from ICT incidents. Some entities are subject to advanced threat-led penetration testing requirements. DORA also requires systematic management of ICT third-party arrangements, including contractual and oversight considerations. CRA product-security work can contribute to the quality of technology entering that environment, but it does not establish whether the financial institution can continue critical or important functions during disruption, restore systems, manage outsourcing concentration or meet DORA governance requirements. This is why a financial organisation should not merge CRA and DORA into a single cybersecurity checklist.
When One Organisation May Need Both CRA and DORA Workstreams
An organisation can encounter both regulations when it performs multiple legal roles. A financial-sector technology company might itself qualify as a covered financial entity under DORA while also manufacturing a software or hardware product that falls within CRA scope. A financial group could develop a product that is later commercially supplied to other entities, raising CRA market-placement questions alongside its DORA responsibilities. A non-financial software manufacturer may primarily have CRA duties while its financial customers impose DORA-driven contractual and assurance requirements. The practical response is to map obligations by role. Use one product record for CRA scope, risk, conformity and vulnerability evidence, and a separate but connected DORA control map for financial operational resilience, ICT assets, third-party dependencies, testing, continuity and incident management.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.