sota.io
2026-04-16·15 min read·

DORA + CRA Dual Compliance: Fintech Manufacturers Building Software Products with Digital Elements (2026)

The EU cybersecurity regulatory landscape contains a largely unacknowledged double bind for a specific class of fintech company: organisations that are simultaneously financial entities under DORA and manufacturers under the Cyber Resilience Act. Most compliance guides address one regime or the other. Almost none address both simultaneously — yet for a neobank that publishes an open-banking SDK, a payment service provider that ships a merchant plugin, or a crypto-asset service provider (CASP) with a self-custodial wallet app, both apply in full.

DORA (Regulation 2022/2554) entered force in January 2025 and imposes ICT risk management, incident reporting, and third-party oversight obligations on financial entities. CRA (Regulation 2024/2847) entered force in December 2024, with most requirements applying from December 2027 — but the critical vulnerability reporting obligation in Art.16 applies from September 2026, 15 months earlier.

For fintech manufacturers, the overlap creates three categories of conflict: shared security obligations with different authority recipients, incident reporting clocks that run simultaneously but at different speeds, and supply chain rules that impose obligations from both directions at once.

This guide maps the full DORA–CRA dual compliance matrix for fintech manufacturers, resolves the conflicts, and provides a Python implementation and developer checklist.

1. Who Is a "Fintech Manufacturer" Under Both Regimes?

The dual-coverage zone is more specific than it first appears. Not every fintech is a CRA manufacturer. Not every software manufacturer is a DORA financial entity. The overlap is the intersection.

DORA Financial Entity (Art.2(1))

DORA applies to:

The key question: Is your company regulated as a financial entity by a national competent authority (BaFin, FCA, AFM, ACPR, etc.) or the ECB? If yes, DORA applies.

CRA Manufacturer (Art.3(13))

CRA defines a "manufacturer" as any natural or legal person that develops or manufactures products with digital elements and places them on the EU market. "Products with digital elements" (Art.3(1)) are hardware or software products that process or transmit data connected to a network or device.

Fintech products that qualify:

The distinction: If your fintech company uses software from a third-party cloud provider, you are a CRA user, not a manufacturer. If your fintech company develops and distributes software that others use, you are a CRA manufacturer — even if that software is open-source and free.

The Overlap Profile

A fintech manufacturer is typically:

  1. Neobank + developer platform: Licensed as a credit institution or e-money institution (DORA Art.2(1)(a)/(b)) that also offers a public API SDK, webhooks library, or embeddable payment UI component (CRA manufacturer)
  2. CASP + wallet manufacturer: MiCA-regulated crypto-asset service provider that distributes a self-custodial wallet application (CRA manufacturer for the wallet software)
  3. Payment institution + plugin publisher: PSD2 payment institution that distributes a WooCommerce or Shopify checkout plugin (CRA manufacturer for the plugin)
  4. Regtech/compliance SaaS + fintech: A company that is both a financial sector ICT service provider and a manufacturer of compliance software sold to regulated entities

2. DORA Obligations for Financial Entities

DORA imposes five pillars of ICT resilience on in-scope financial entities.

Pillar 1: ICT Risk Management Framework (Art.5–16)

Art.5: Management body accountability — the board must adopt and review the ICT risk management framework annually, approve digital resilience strategies, and bear direct responsibility for ICT risk tolerance.

Art.6: ICT risk management framework must cover identification, protection, detection, response, and recovery. The framework must be documented, maintained, and tested.

Art.9: ICT security requirements — financial entities must implement:

Art.11: Business continuity and disaster recovery — recovery time objectives (RTO) and recovery point objectives (RPO) must be defined for each critical ICT system. Maximum tolerable downtime and maximum tolerable data loss must be formally documented.

Art.13: Learning and evolving — financial entities must post-incident review, threat intelligence sharing, and integrate lessons into ICT risk management.

Pillar 2: ICT Incident Management and Reporting (Art.17–23)

Art.18: Incident classification — financial entities must classify ICT-related incidents based on criteria specified in RTS adopted by the European Supervisory Authorities (ESAs). Classification determines whether an incident is "major" and triggers reporting.

Art.19: Major ICT incident reporting — the most time-sensitive obligation under DORA:

Recipients: DORA incident reports go to the financial sector competent authority (BaFin for Germany, DNB for Netherlands, FCA for UK, ECB for significant credit institutions under SSM).

Pillar 3: Digital Operational Resilience Testing (Art.24–27)

Art.24: Threat-led penetration testing (TLPT) — significant financial entities must conduct TLPT against critical production systems at least every 3 years. TLPT must involve realistic red-team attack simulations, not just vulnerability scans.

Art.25: Advanced testing requirements — TLPT must follow the TIBER-EU framework or equivalent national frameworks. External testers must be independent and certified.

Art.26: Internal testing — all financial entities must annually test their ICT systems including critical applications. Testing scope must cover the systems supporting critical or important functions.

Pillar 4: ICT Third-Party Risk (Art.28–44)

Art.28: Third-party risk strategy — financial entities must document and maintain policies for managing third-party ICT providers. Cloud providers, data centers, and SaaS platforms used for critical functions require enhanced oversight.

Art.30: Contractual requirements — contracts with ICT third-party providers must include:

Art.31–44: Critical ICT third-party provider (CITP) oversight — the ESAs designate CITPs (major cloud providers, critical data providers) for direct oversight. Financial entities using designated CITPs must ensure their contracts satisfy the CITP oversight program.

3. CRA Obligations for Manufacturers

The Cyber Resilience Act imposes security requirements and market access obligations on all manufacturers of products with digital elements sold or distributed in the EU market.

Product Classification: Default vs. Important vs. Critical

CRA Annex III classifies products by risk level:

For fintech manufacturers: Payment SDKs and wallet apps typically fall in "default" or Class I category. Hardware secure elements (in payment terminals) can reach Class II. Most fintech software products require self-attestation unless they include network devices or security-critical components.

Core Manufacturer Obligations

Art.10(1): Essential cybersecurity requirements — manufacturers must ensure products satisfy Annex I, Part I (security properties) and Part II (vulnerability handling) requirements throughout the support lifecycle.

Annex I, Part I — Product security properties:

Annex I, Part II — Vulnerability handling:

Art.13: Manufacturer market obligations:

The September 2026 CRA Deadline: Vulnerability and Incident Reporting

Art.14(1): Manufacturers must establish and document a coordinated vulnerability disclosure (CVD) policy before placing products on the market. The CVD policy must specify:

Art.16(1) — CRITICAL — applies from 11 September 2026, 15 months before the December 2027 general CRA deadline:

Manufacturers must notify their national CSIRT (Computer Security Incident Response Team) within 24 hours of becoming aware of:

This is not an optional obligation deferred to 2027. It is mandatory as of September 2026 for any manufacturer with products in the EU market.

Art.16(2): Within 72 hours, a more detailed vulnerability notification must follow, including:

Recipients: CRA vulnerability/incident reports go to the national CSIRT (BSI's CERT-Bund for Germany, NCSC-NL for Netherlands, ANSSI CERT-FR for France). ENISA collects aggregated data via the single reporting platform.

4. The Dual Compliance Conflict Matrix

When a fintech company is simultaneously a DORA financial entity and a CRA manufacturer, the same underlying security event can trigger obligations under both regimes simultaneously. The conflicts arise in three areas.

Conflict 1: Incident Reporting — Parallel Clocks, Different Authorities

TriggerDORA Art.19CRA Art.16
Reporting authorityFinancial sector NCA (BaFin, DNB, FCA, ECB)National CSIRT (BSI, NCSC-NL, ANSSI)
Initial notification4 hours from major incident classification24 hours from awareness of actively exploited vulnerability
Intermediate report72 hours from initial notification72 hours detailed notification
Final report1 month from intermediate reportNo explicit deadline for final report
Incident scopeICT incidents affecting financial service continuitySecurity incidents affecting product security
Trigger threshold"Major ICT incident" (Art.18 classification criteria)"Actively exploited vulnerability" in own product

The conflict scenario: A fintech manufacturer discovers that its open-banking SDK contains a vulnerability that is being actively exploited in the wild, and the exploitation is causing service disruption that qualifies as a major ICT incident under DORA Art.18 classification criteria.

In this scenario:

Resolution: Fintech manufacturers need a bifurcated incident response playbook with parallel notification workflows from the moment a security event is detected. The classification triage must determine within minutes whether the event triggers DORA (financial service continuity impact) and/or CRA (actively exploited vulnerability in manufactured product). Both can be triggered simultaneously.

Conflict 2: Security Requirements — Overlapping but Not Identical

Control AreaDORA Art.9CRA Annex I, Part I
Vulnerability managementPatch and vulnerability management with defined SLAsNo known actively exploited vulnerabilities at market placement
Secure configurationAccess control policies, privilege minimisationSecure by default, minimal attack surface
CryptographyEncryption at rest and in transitEncrypted storage and transmission
AuthenticationStrong authentication, privileged access managementAccess control, authentication
ResilienceRTO/RPO for critical systems, DR testingResilience against DoS attacks
MonitoringAudit logging, threat intelligenceAuditability, event recording
SBOMNo explicit SBOM requirementMandatory SBOM (Annex I, Part II(1)(a))
CVDNo CVD policy requirementMandatory CVD policy (Art.14)
TLPTMandatory for significant entities every 3 yearsVulnerability testing required but not TIBER-EU

The gap: DORA does not require a software bill of materials or a coordinated vulnerability disclosure policy. CRA does. A fintech manufacturer that builds its DORA compliance around Art.9 security requirements without considering CRA Annex I, Part II will be missing two mandatory manufacturer obligations before September 2026.

Resolution: Build the security program to satisfy the union of both requirement sets. SBOM generation and CVD policy should be implemented as engineering baseline, not as add-ons when the CRA clock runs.

Conflict 3: Supply Chain — Obligations From Both Directions

As a DORA financial entity, the fintech manufacturer must assess the ICT third-party risk of the cloud providers, data centres, and SaaS platforms it uses. DORA Art.28 requires documented third-party risk policies, and Art.30 imposes contractual requirements on critical third-party providers.

As a CRA manufacturer, the fintech manufacturer must manage the open-source and third-party software components incorporated in its products. CRA Annex I, Part II requires an SBOM listing all components, and Art.14 requires CVD processes that cover vulnerabilities discovered in third-party components.

The dual-direction problem: The fintech manufacturer is simultaneously:

A vulnerability discovered in an open-source library embedded in the payment SDK can simultaneously:

Resolution: Map the supply chain obligations from both directions. Maintain separate processes for: (a) DORA third-party ICT risk register covering providers of services to the financial entity, and (b) CRA SBOM and component vulnerability management covering software components embedded in manufactured products.

5. The Hosting Variable: Why EU Infrastructure Matters for Both Regimes

Both DORA and CRA create strong incentives for EU-hosted infrastructure — but for different reasons.

DORA + CLOUD Act: DORA Art.30 requires financial entities to ensure their ICT third-party providers can be audited by EU supervisory authorities. US-headquartered cloud providers serving EU financial entities are subject to the US CLOUD Act, which enables US law enforcement to compel access to data stored anywhere globally. This creates a dual-compellability risk: the same financial data can be demanded by the EU NCA (DORA audit right) and a US court (CLOUD Act order) simultaneously. European sovereignty cloud providers or EU-incorporated subsidiaries with technical access barriers offer risk reduction.

CRA + CLOUD Act: CRA Art.16 requires manufacturers to report vulnerabilities and incidents to national CSIRTs. Technical vulnerability documentation (security architecture, test results, SBOM) that is stored on US-provider infrastructure is potentially accessible under CLOUD Act. For manufacturers seeking CE marking and technical documentation protection, EU-resident storage reduces cross-jurisdictional disclosure risk.

For fintech manufacturers: Platform choices for both the financial operations infrastructure (DORA) and the product development/distribution infrastructure (CRA) should account for CLOUD Act exposure. The safest position is EU-incorporated providers with contractual commitments against non-EU jurisdictional disclosure.

6. Python Implementation: FinTechDoraCRAComplianceMapper

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import datetime


class EntityType(Enum):
    CREDIT_INSTITUTION = "credit_institution"           # DORA Art.2(1)(a)
    PAYMENT_INSTITUTION = "payment_institution"         # DORA Art.2(1)(b)
    EMONEY_INSTITUTION = "emoney_institution"           # DORA Art.2(1)(c)
    INVESTMENT_FIRM = "investment_firm"                 # DORA Art.2(1)(e)
    CASP = "crypto_asset_service_provider"             # DORA Art.2(1)(r), MiCA


class ProductClass(Enum):
    DEFAULT = "default"           # Self-attestation allowed
    CLASS_I = "class_i"           # Annex III Part I — standard notified body or self + harmonised standard
    CLASS_II = "class_ii"         # Annex III Part II — mandatory notified body
    CRITICAL = "critical"         # Annex IV — mandatory EUCC certification


@dataclass
class SecurityIncident:
    """Represents a security event for dual-compliance triage."""
    incident_id: str
    detected_at: datetime.datetime
    description: str
    # DORA classification
    financial_service_disrupted: bool = False
    estimated_affected_clients: int = 0
    transaction_volume_affected_eur: float = 0.0
    # CRA classification
    vulnerability_actively_exploited: bool = False
    affected_product_versions: list[str] = field(default_factory=list)
    vulnerability_cvss_score: float = 0.0


@dataclass
class FinTechDoraCRAComplianceMapper:
    """
    Maps dual compliance obligations for fintech manufacturers under
    DORA (Regulation 2022/2554) and CRA (Regulation 2024/2847).
    """
    company_name: str
    dora_entity_type: EntityType
    cra_product_class: ProductClass
    competent_financial_authority: str   # e.g., "BaFin", "DNB", "FCA", "ECB"
    national_csirt: str                  # e.g., "BSI CERT-Bund", "NCSC-NL", "CERT-FR"

    def classify_incident(self, incident: SecurityIncident) -> dict:
        """
        Determine which reporting obligations are triggered and compute
        all notification deadlines from a single security event.
        """
        results = {
            "incident_id": incident.incident_id,
            "detected_at": incident.detected_at.isoformat(),
            "dora_triggered": False,
            "cra_triggered": False,
            "dora_deadlines": {},
            "cra_deadlines": {},
            "conflict_notes": [],
        }

        # DORA Art.18 major incident classification
        # Simplified criteria — real criteria in ESA RTS (JC 2024/69)
        dora_major = (
            incident.financial_service_disrupted
            and (
                incident.estimated_affected_clients > 100_000
                or incident.transaction_volume_affected_eur > 1_000_000
            )
        )

        if dora_major:
            results["dora_triggered"] = True
            initial = incident.detected_at + datetime.timedelta(hours=4)
            intermediate = initial + datetime.timedelta(hours=72)
            final = intermediate + datetime.timedelta(days=30)
            results["dora_deadlines"] = {
                "authority": self.competent_financial_authority,
                "initial_notification": initial.isoformat(),
                "intermediate_report": intermediate.isoformat(),
                "final_report": final.isoformat(),
                "regulation": "DORA Art.19",
            }

        # CRA Art.16 actively exploited vulnerability
        if incident.vulnerability_actively_exploited:
            results["cra_triggered"] = True
            cra_initial = incident.detected_at + datetime.timedelta(hours=24)
            cra_detailed = incident.detected_at + datetime.timedelta(hours=72)
            results["cra_deadlines"] = {
                "authority": self.national_csirt,
                "initial_notification": cra_initial.isoformat(),
                "detailed_notification": cra_detailed.isoformat(),
                "regulation": "CRA Art.16",
                "applies_from": "2026-09-11",
            }

        # Conflict analysis
        if results["dora_triggered"] and results["cra_triggered"]:
            results["conflict_notes"].append(
                "DUAL TRIGGER: Same incident triggers DORA Art.19 (4h to financial authority) "
                "and CRA Art.16 (24h to CSIRT). Two parallel notification workflows required. "
                "DORA report focuses on service continuity impact; CRA report focuses on "
                "product vulnerability technical details."
            )

        return results

    def audit_sbom_gap(self) -> dict:
        """
        Check DORA vs CRA gap for SBOM requirements.
        DORA Art.9: no SBOM requirement.
        CRA Annex I Part II(1)(a): mandatory SBOM.
        """
        return {
            "dora_sbom_required": False,
            "cra_sbom_required": True,
            "cra_sbom_applies_from": "2027-12-11",
            "gap": "SBOM is a CRA-only requirement. Implement as engineering baseline "
                   "regardless of DORA compliance status. Tools: Syft, CycloneDX, SPDX.",
            "recommendation": "Generate SBOM at build time (CI/CD). Maintain in SPDX 2.3 "
                               "or CycloneDX 1.5 format. Include all transitive dependencies.",
        }

    def audit_cvd_gap(self) -> dict:
        """
        Check DORA vs CRA gap for vulnerability disclosure policy.
        DORA: no CVD policy requirement.
        CRA Art.14: mandatory CVD policy before market placement.
        """
        return {
            "dora_cvd_required": False,
            "cra_cvd_required": True,
            "cra_cvd_applies_from": "2027-12-11",
            "cra_reporting_applies_from": "2026-09-11",  # Art.16 earlier deadline
            "gap": "CVD policy is a CRA-only requirement. Must be published before "
                   "September 2026 for Art.16 reporting compliance.",
            "recommendation": "Publish security.txt at /.well-known/security.txt. "
                               "Include PGP key, response SLA (<5 business days triage, "
                               "<90 days patch), and scope definition.",
        }

    def supply_chain_obligations(self) -> dict:
        """
        Map dual-direction supply chain obligations.
        DORA Art.28: assess providers your financial entity uses.
        CRA Annex I Part II: manage components embedded in your products.
        """
        return {
            "dora_direction": {
                "role": "Assessor of inbound ICT third-party risk",
                "obligation": "DORA Art.28 third-party risk policy + Art.30 contractual requirements",
                "scope": "Cloud providers, data centers, SaaS platforms used for financial operations",
                "key_requirement": "Contracts must include audit rights, SLAs, exit assistance, "
                                   "incident notification within defined timeframes",
            },
            "cra_direction": {
                "role": "Integrator of software components into manufactured products",
                "obligation": "CRA Annex I Part II SBOM + Art.14 CVD covering third-party components",
                "scope": "Open-source libraries, SDKs, frameworks embedded in distributed products",
                "key_requirement": "SBOM must list all components including transitive dependencies. "
                                   "CVD policy must cover vulnerabilities in third-party components.",
            },
            "conflict_scenario": (
                "Vulnerability in open-source library embedded in payment SDK "
                "simultaneously triggers: (1) CRA Art.16 reporting as manufacturer "
                "of affected product, (2) DORA Art.28 review as financial entity "
                "using that library's maintainer as implicit ICT third party."
            ),
        }

    def generate_compliance_roadmap(self) -> list[dict]:
        """
        Generate prioritised compliance roadmap with CRA 2026 deadline first.
        """
        roadmap = [
            {
                "deadline": "2026-09-11",
                "priority": "CRITICAL",
                "obligation": "CRA Art.16: vulnerability and incident reporting to CSIRT",
                "regime": "CRA",
                "action": f"Establish notification channel to {self.national_csirt}. "
                           "Deploy monitoring for actively exploited vulnerabilities in products. "
                           "Create DORA-CRA parallel notification workflow.",
            },
            {
                "deadline": "2025-01-17 (ALREADY ACTIVE)",
                "priority": "ACTIVE",
                "obligation": "DORA Art.19: major ICT incident reporting (4h/72h/1-month)",
                "regime": "DORA",
                "action": f"Ensure classification process identifies major incidents within minutes. "
                           f"4-hour notification workflow to {self.competent_financial_authority} must be operational.",
            },
            {
                "deadline": "2027-12-11",
                "priority": "HIGH",
                "obligation": "CRA Annex I: product security requirements + CE marking",
                "regime": "CRA",
                "action": "Conduct conformity assessment for all in-scope products. "
                           f"{'Self-attestation' if self.cra_product_class == ProductClass.DEFAULT else 'Notified body assessment'} "
                           f"required for {self.cra_product_class.value} classification.",
            },
            {
                "deadline": "2027-12-11",
                "priority": "HIGH",
                "obligation": "CRA Art.14: CVD policy + CRA Annex I Part II: SBOM",
                "regime": "CRA",
                "action": "Publish security.txt CVD policy. Generate SBOM in CycloneDX/SPDX "
                           "format at build time. Both should be implemented earlier "
                           "as engineering baseline before regulatory deadline.",
            },
        ]
        return roadmap

7. The 30-Item Fintech Manufacturer Dual Compliance Checklist

DORA ICT Risk Management (Art.5–16)

DORA Incident Reporting (Art.17–23)

DORA ICT Third-Party Risk (Art.28–30)

DORA Testing (Art.24–27)

CRA Vulnerability Reporting — September 2026 Deadline

CRA Product Security (Annex I)

CRA Market Obligations (Art.13–16)

EU Infrastructure for Dual Compliance

8. Implementation Timeline for Fintech Manufacturers in 2026

The September 2026 CRA Art.16 deadline is the immediate priority for any fintech manufacturer that currently distributes software products in the EU market.

Now (April–June 2026):

  1. Identify all products that qualify as "products with digital elements" under CRA
  2. Classify each product (Default / Class I / Class II / Critical)
  3. Draft CVD policy and publish at /.well-known/security.txt
  4. Integrate SBOM generation into CI/CD pipeline (Syft + CycloneDX recommended)
  5. Establish monitoring for actively exploited vulnerabilities in your product stack (CVE feeds, ENISA's vulnerability database)

July–September 2026: 6. Establish formal notification channel with national CSIRT 7. Test the 24-hour CRA Art.16 notification workflow 8. Build and test the DORA-CRA parallel notification playbook for dual-trigger incidents 9. Document which incidents trigger each regime (or both) based on your product/service profile

September 2026 onward: 10. CRA Art.16 vulnerability reporting obligation is live — no more preparation time

2027: 11. Complete conformity assessments for all in-scope products 12. File EU Declarations of Conformity 13. Ensure technical documentation ready for market surveillance authority inspection

Conclusion

The fintech manufacturer compliance challenge is not about choosing between DORA and CRA — both apply, simultaneously, to the same organisation. The architectural question is how to build a unified compliance infrastructure that satisfies the union of both requirement sets without duplicating work unnecessarily.

Three principles guide the approach:

  1. Bifurcated incident reporting: The same security event can trigger DORA Art.19 (4h to financial authority) and CRA Art.16 (24h to CSIRT) simultaneously. These are not redundant reports — they go to different recipients with different content requirements. Build parallel notification workflows from day one.

  2. SBOM and CVD are CRA-only requirements that should be engineering baseline: DORA does not require a software bill of materials or a coordinated vulnerability disclosure policy. But implementing both as engineering practice — regardless of regulatory mandate — reduces supply chain risk, accelerates incident response, and satisfies CRA requirements when the 2026 and 2027 deadlines arrive.

  3. EU infrastructure reduces dual-compellability exposure under both regimes: DORA's financial data and CRA's technical vulnerability documentation both face CLOUD Act risk on US-provider infrastructure. EU-resident infrastructure with contractual sovereignty protections reduces the exposure vector for both regulatory frameworks simultaneously.

For fintech manufacturers, the September 2026 CRA Art.16 reporting deadline is not 15 months away — it is less than 5 months away from today. The CVD policy, CSIRT notification workflow, and vulnerability monitoring infrastructure need to be operational before then.

This guide covers DORA Regulation (EU) 2022/2554, CRA Regulation (EU) 2024/2847, and their intersection as of April 2026. The Python implementation is illustrative; actual compliance requires legal counsel and review of current ESA regulatory technical standards.