The response should begin with a shared technical record and separate legal assessments. The developer needs to assess the SDK. The fintech needs to assess its app and financial operations. Their contract should let each obtain the evidence and assistance needed to act within its own deadline.
Executive Summary
- A commercially supplied SDK can be a product with digital elements, including when its network connection is indirect. A customer app can be a separate product. SaaS requires a different analysis, including whether remote processing forms part of a covered product. (CRA, arts 2(1), 3(1), (2), (6), (10), (22).)
- The developer is the SDK manufacturer if it develops or commissions the software and markets it under its own name. The fintech can separately be the app manufacturer. Importer or distributor status requires its own supply-chain facts. (CRA, art. 3(13), (16), (17).)
- Each manufacturer assesses reporting for its own product. The Commission’s published draft guidance distinguishes component exploitation from exploitation in the downstream product. A severe product-security incident provides a separate reporting trigger. (CRA, arts 3(42), 14(1), (3), (5); Commission, C(2026) 5252, Annex, para. 218.)
- A covered financial entity retains its Digital Operational Resilience Act (DORA) reporting responsibility. Personal-data incidents require separate EU and, where applicable, Brazilian assessments. A CRA filing cannot be treated as completion of those processes. (Regulation (EU) 2022/2554, art. 19; Regulation (EU) 2016/679, arts 33–34; Lei nº 13.709/2018, art. 48.)
- Contracts should require prompt evidence sharing and remedial assistance now. Most CRA design, support and conformity duties apply from 11 December 2027, subject to the transition for products already placed on the market. (CRA, arts 13, 69(2), 71; Annex I.)
Identify the distributed SDK and the affected app
The first record should identify the supplied code, affected versions, deployment locations and intended functions. An SDK can contain runtime libraries, development tools and interfaces to remote services. Record which part contains the weakness and whether it reaches the released app. A package name or dependency listing alone cannot establish the affected execution path.
The CRA covers separately marketed software components. Its connection test includes an indirect data connection through a larger system. A commercially licensed SDK integrated into a connected app can therefore qualify even if the SDK never opens its own internet connection. One enterprise customer can be enough to establish commercial supply; charging each end user is unnecessary. (CRA, arts 2(1), 3(1), (6), (10), (21), (22).)
Assess the app independently. An app developed or commissioned by the fintech and supplied under its name to EU users can be another covered product. Software developed exclusively for internal use has a different market-supply analysis. Receiving an SDK for internal development does not, by itself, establish that the fintech has placed an app on the market. (CRA, arts 3(13), (21), (22); Commission, C(2026) 5252, Annex, section 2.1.)
For a service accessed only remotely, identify whether any software product is supplied to the customer. Pure SaaS generally falls outside the CRA. Remote processing belongs to a covered product where its software is designed and developed by the manufacturer, or under its responsibility, and its absence would prevent one of the product’s functions. Moving part of an app to a server does not establish an exemption. An independently developed third-party API also does not automatically become the fintech’s remote processing solution. (CRA, art. 3(1), (2), recitals 11–12; Commission, C(2026) 5252, Annex, sections 2.2 and 8.1.)
Neither AI functionality nor supply to a financial institution creates a general CRA exclusion. The product-specific exclusions must actually apply. Non-commercial free and open-source development requires separate treatment, but an open-source licence does not exempt a commercial SDK merely because its source is available. The downstream manufacturer must still assess its own product. (CRA, arts 2, 3(13), (22), (48), recitals 17–20.)
Assign manufacturer and supply-chain responsibilities
On the own-brand supply route, the Brazilian developer is the SDK manufacturer. Its location outside the EU does not remove Article 14 duties for a covered product supplied on the EU market. If the fintech develops or commissions its own branded app, it is the manufacturer of that app. A supplier agreement can allocate investigation and filing work, but cannot alter the statutory tests. (CRA, arts 3(13), 14(1), (3), (7).)
Importer status requires an EU-established person that first places a foreign-branded product on the EU market. A distributor makes that product available subsequently without affecting its properties. The fintech’s purchase and integration of the SDK do not alone establish either role. Examine who supplies the Brazilian-branded component, to whom, and under whose name. Keep that assessment separate from the fintech’s manufacture of its app. (CRA, art. 3(16), (17), (21), (22).)
Rebranding and substantial modification can also bring manufacturer duties under Articles 21 and 22 when those provisions apply from 11 December 2027. For current reporting, establish manufacturer status under Article 3(13) and apply Article 14. Do not present the later importer and distributor obligations as already operative. (CRA, arts 19–22, 71.)
The timetable affects existing releases. Article 14 has applied since 11 September 2026, including to covered products placed on the market before 11 December 2027. Reporting does not depend on a new sale or substantial modification. The Commission’s published draft guidance explains that it continues after support ends. Most other CRA duties begin on 11 December 2027; products already placed before that date generally enter those duties only following a substantial modification from that date. (CRA, arts 69(2)–(3), 71; Commission, C(2026) 5252, Annex, para. 210.)
For products placed on the market from 11 December 2027, complete the applicable risk assessment, technical documentation and conformity procedure before release. Issue the EU declaration of conformity and affix the CE marking. Product classification and core functionality determine the route; AI functionality or financial use alone does not. (CRA, arts 7–8, 13(1)–(2), (12), 28, 30–32; Commission Implementing Regulation (EU) 2025/2392.)
Establish the reporting trigger and start the correct clock
A vulnerability is not automatically an actively exploited vulnerability. Article 3(42) requires reliable evidence of exploitation by a malicious actor in a system without its owner’s permission. A vulnerability identifier, severity score, proof of concept or authorised penetration test alone does not establish that trigger. Evidence of exploitation can come from outside the manufacturer’s own systems. (CRA, arts 3(40)–(42), 14(1).)
The developer should investigate whether exploitation affects its SDK. The fintech must connect the evidence to its app. Under the Commission’s published non-binding draft guidance, the fintech need not report a component vulnerability as actively exploited in its app if it cannot be exploited there or has not been exploited there. That distinction requires a product-specific assessment. Missing reports from customers do not establish that exploitation has not occurred. Preserve the technical basis and reassess when new evidence arrives. (CRA, art. 14(1); Commission, C(2026) 5252, Annex, para. 218.)
Separately assess severe incidents. Article 14(5) covers actual or potential harm to the product’s protection of sensitive or important data or functions. The protected attributes are availability, authenticity, integrity and confidentiality. It also covers an incident that has led, or can lead, to malicious code’s introduction or execution in the product or a user’s systems. Either branch can suffice. The fintech cannot close the CRA assessment merely because active exploitation of the SDK remains unconfirmed. (CRA, arts 3(43)–(44), 14(3), (5).)
Investigate suspicious information immediately. The published draft guidance treats awareness as a reasonable degree of certainty after the initial assessment. Waiting for management approval or a completed forensic report cannot provide an automatic extension. Record discovery, assessment and awareness separately for each manufacturer and each trigger. (CRA, art. 14(2), (4); Commission, C(2026) 5252, Annex, paras 211–215.)
Once the relevant manufacturer becomes aware:
- Submit an early warning without undue delay and within 24 hours.
- Supply the fuller vulnerability or incident notification without undue delay and within 72 hours of the same awareness event. Include the available assessment, affected product information and corrective or mitigating measures. The later deadline is not another 72 hours after the early warning.
- For an actively exploited vulnerability, submit the final report within 14 days after a corrective or mitigating measure becomes available. An effective mitigation can start this clock before a permanent patch exists.
- For a severe incident, submit the final report within one month after the fuller incident notification. The coordinator can also request intermediate updates. Later stages need not repeat relevant information already supplied. (CRA, art. 14(2), (4), (6).)
Use the operational Single Reporting Platform run by ENISA, the EU cybersecurity agency. Reports go to ENISA and the designated national computer security incident response team (CSIRT) coordinator, subject to restrictions on onward disclosure. For an EU manufacturer, the relevant establishment is normally where product-cybersecurity decisions are predominantly taken. The fallback is its EU establishment with the highest employee count. (CRA, arts 14(7), 16(2).)
For the Brazilian manufacturer without an EU main establishment, select the CSIRT coordinator in the Member State determined by the ordered alternatives in Article 14(7): where the authorised representative handling the highest number of its products is established; then where the importer is established; then where the distributor is established; finally the Member State with the highest number of users. The importer and distributor tests concern the highest number of products placed or made available. The fintech’s home state is not automatically the supplier’s reporting destination.
Appoint a filer and backup, prepare their EU Login access and follow current ENISA registration instructions when a report is required. Keep legal deadline calculations outside platform reminders. Each manufacturer must establish that its own notification was made; the supplier’s filing does not automatically discharge the fintech’s duty for its app. (CRA, art. 14; ENISA, Single Reporting Platform FAQs, questions 8–9, 18, 26, updated 15 October 2026.)
Manufacturers must also inform impacted users and, where appropriate, all users, with necessary protective measures. The SDK supplier’s users can include the fintech; the app manufacturer has its own user audience. Article 14(8) requires timely communication without prescribing one universal customer-notice deadline. A confidentiality clause should permit required notifications. A request to restrict sensitive information’s dissemination does not suspend the manufacturer’s filing clock. (CRA, arts 14(8), 16(2).)
Run financial-sector and privacy assessments in parallel
The fintech must identify whether its legal entity falls within DORA. Credit institutions, payment institutions and other listed financial entities are covered, subject to the Regulation’s exclusions. The commercial description “fintech” is insufficient. A financial institution can have DORA duties for its operations and CRA duties as an app manufacturer at the same time. (Regulation (EU) 2022/2554, art. 2; CRA, arts 2, 3(13), 14.)
DORA requires the financial entity to classify and report major ICT-related incidents. The classification considers affected services and prescribed thresholds. Successful malicious unauthorised access that may cause data losses has a specific route to major classification; a confirmed outage is unnecessary. A discovered weakness without an incident does not automatically meet that test. (DORA, arts 17–19; Commission Delegated Regulation (EU) 2024/1772, arts 6, 8–9.)
The general initial-notification deadline is as early as possible, within four hours of major classification and no later than 24 hours after awareness. If classification occurs more than 24 hours after awareness, notification is due within four hours of classification. An intermediate report follows within 72 hours of the initial notification, even without a status change. The final report follows within one month of the intermediate or latest updated intermediate report. Entity-specific weekend rules require checking; credit institutions cannot defer initial or intermediate reports on that basis. (Commission Delegated Regulation (EU) 2025/301, art. 5.)
The financial entity files through its competent authority’s prescribed channel using the required forms. Outsourcing submission leaves it responsible, and the outsourcing arrangement itself requires authority notification. Where a major incident affects clients’ financial interests, DORA also requires client information without undue delay. For payment-sector entities identified in Article 23, the assessment extends to operational or security payment-related incidents. (DORA, arts 19, 23, 46; Commission Implementing Regulation (EU) 2025/302, arts 1, 4, 6.)
The wider controls are addressed in Licentium’s guide to DORA compliance requirements. The SDK response still needs its own evidence and notification decisions.
A personal-data breach activates another assessment. The EU General Data Protection Regulation (GDPR) requires controller notification unless the breach is unlikely to risk individuals’ rights and freedoms. Where required, notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of awareness. A processor must notify its controller without undue delay. High-risk breaches can also require communication to affected individuals, subject to Article 34’s exceptions. Neither a security weakness alone nor a CRA notice determines these outcomes. (Regulation (EU) 2016/679, arts 4(12), 33–34.)
Brazil’s General Data Protection Law (LGPD) requires a separate scope and processing-role assessment. For a personal-data incident capable of causing relevant risk or damage, the controller generally has three business days to notify ANPD and affected individuals. Both periods run from awareness that personal data were affected. Article 6 preserves any specific legislative deadline for notification to ANPD. Qualifying small processing agents can have doubled periods; size alone does not establish eligibility. ANPD guidance requires processor escalation without unjustified delay and the supply of necessary information. Software licensing alone does not establish that the developer processes customer data. (Lei nº 13.709/2018, arts 3, 46, 48; Resolução CD/ANPD nº 15/2024, arts 4–6, 9; Resolução CD/ANPD nº 2/2022, arts 3, 14; ANPD, Comunicação de Incidente de Segurança, question 6.)
Agree remediation support and evidence before the next release
The parties should adopt a security schedule now, with commitments identified as contractual where the CRA’s later duties have not begun. A financial entity receiving ongoing ICT services already needs the applicable DORA terms, including incident assistance at no additional cost or at a cost fixed in advance. Services supporting critical or important functions require additional controls. (DORA, arts 3(21), 28, 30(2)–(3).)
The schedule should address these decisions:
- Require reciprocal notice of credible vulnerabilities, exploitation evidence and relevant incidents through monitored security contacts. Initial notice should precede a complete investigation. The proposed contractual trigger should be broader than statutory reportability, so the fintech can assess its app and shorter financial-sector clocks.
- Allocate investigation, containment, patch creation, testing, release and installation. The supplier should provide affected-version information, exposure conditions, mitigations and signed updates where the delivery system supports them. The fintech should verify deployment and decide whether an affected feature must be disabled. Any timetable must reflect the actual severity and required reporting, rather than copying the CRA’s 24-hour filing limit into a supplier-response allowance.
- Identify supported versions, the support end date and replacement arrangements. From 11 December 2027, applicable CRA support periods must reflect expected use and generally last at least five years; a product expected to be used for less has a corresponding shorter period. Five years is not a universal maximum. The app manufacturer must address any gap between its own required support and the supplier’s commitment. (CRA, art. 13(8), (19).)
- Allocate upstream notices and fixes. When Article 13(6) applies, a manufacturer identifying a vulnerability in an integrated component must notify its manufacturer or maintainer and address it. If it develops a corrective modification, it must share the relevant code or documentation. Agree reciprocal cooperation now. Security updates must generally be free under the later CRA requirements, with a specific exception for an agreement with a business user concerning a tailor-made product. (CRA, arts 13(6), 71; Annex I, Part II, points 2 and 8.)
- Preserve the evidence needed for each decision: component inventory, affected versions, exploitation assessment, awareness times, report receipts, notices, patch testing and deployment records. The later CRA requires a machine-readable software bill of materials covering at least top-level dependencies. Its technical-document retention and update-availability periods are distinct: generally ten years from market placement for the former, and ten years from issue for each update, subject to longer support-period rules. (CRA, art. 13(9), (13); Annex I, Part II, point 1.)
Confirm ownership and rights to integrate, distribute, modify and supply fixes for proprietary and third-party code. Check Brazilian ownership rules and permitted-use exceptions against the actual development and licence terms. Record missing rights before deployment. (Lei nº 9.609/1998, arts 2, 4–6.) Check whether technical functions or end use bring the supply within Brazil’s sensitive-goods controls. Where they apply, obtain the required authorisation before export; an AI label establishes no clearance. (Lei nº 9.112/1995, arts 1–3.)
Incident evidence should contain only necessary personal data and use controlled access. Check the reciprocal adequacy decisions adopted in January 2026 before choosing a transfer mechanism between the EU and Brazil. The EU decision covers Brazilian controllers and processors subject to the LGPD. Adequacy leaves processing-contract, security and breach-notification duties in place. Further transfers need their own assessment. (Regulation (EU) 2016/679, arts 28, 32, 44–45; Commission Implementing Decision (EU) 2026/179, art. 1; Resolução CD/ANPD nº 32/2026.)
The broader agreement can be reviewed through AI supplier contracts for EU and UK enterprise sales. If continuity depends on access to source code or models after supplier failure, the separate analysis of software escrow for AI supplied to a bank addresses that recovery decision.
The next release should proceed through a documented gate. Engineering confirms which versions remain exposed and tests the chosen remedy. Each legal reporting owner records its trigger decision and completes notices already due. Procurement closes support, rights and cooperation gaps. A report receipt alone does not establish that the affected product is safe to release.
Review vulnerability-reporting obligations. Share the SDK and app architecture, supplier terms and incident procedure so Licentium can scope the product-role assessment, notification sequence and contract amendments.