The recommended route is to retain the branded commercial distribution, define its supported releases and separate that commitment from the customer's integration responsibilities. Cyber Resilience Act (CRA) open-source rules require a product-specific assessment. An open repository does not exempt a commercial binary, and an upstream support contract cannot transfer the customer's statutory duties.
- The Egyptian supplier is the manufacturer of its branded commercial SDK when it supplies an in-scope product to the EU. Its location outside the EU does not remove that role. A genuinely non-commercial repository requires a separate assessment. (Regulation (EU) 2024/2847, the CRA, Arts 2(1), 3(13), 3(21)–(22); recitals 15–20.)
- If the French fintech markets the assembled product under its own name, it is that product's manufacturer. This conclusion does not depend on proving that every SDK modification is substantial. (CRA, Art 3(13).)
- Manufacturer reporting has applied since 11 September 2026. Most product, support and conformity duties apply from 11 December 2027, subject to transitional rules. Open-source stewards have a different timetable. (CRA, Arts 24, 69, 71.)
- Replace the expectation of “all security upstream” with release-specific commitments, rapid vulnerability cooperation and controls over customer modifications. Each party must retain the decisions and evidence required for its own product.
Classify each distribution path
The free repository
The CRA covers products made available commercially in the EU, including separately supplied software components. Their intended or reasonably foreseeable use must involve a direct or indirect connection to a device or network. Open-source status also requires the freedoms specified in Article 3(48), including access to source code and rights to use, modify and redistribute it. A public download alone does not establish that status. (CRA, Arts 2(1), 3(1), 3(22), 3(48).)
A genuinely non-commercial repository can fall outside manufacturer obligations. Commercial use by the French customer does not, by itself, commercialise the upstream project. Conversely, charging for the product, restricting commercially relevant access or monetising associated services can change the analysis. The actual offering and revenue arrangements matter. (CRA, recitals 17–20.)
The Commission's published draft guidance distinguishes a priced binary distribution from a separate community version. It also distinguishes optional consultancy for freely available, maintained software from services whose payment conditions access to the software or its benefits. Paid assistance therefore requires closer analysis than a blanket rule that any support fee commercialises every repository. (Commission, draft CRA guidance, C(2026) 5252 annex, paras 51–59; non-binding.)
A legal person supporting the community project may instead qualify as an open-source software steward. It must systematically and sustainably support development of specified software intended for commercial activities and ensure its viability. That status is unavailable to a natural person and does not replace manufacturer status for the same commercial product. Its later duties include a cybersecurity policy, authority cooperation and limited reporting tied to its involvement and development systems. The free repository's governance and support arrangements are therefore necessary facts. (CRA, Arts 3(14), 24.)
The branded binary
The developer sells and brands the supported distribution. Those facts satisfy the commercial and manufacturer elements, provided the SDK meets the connection and EU supply conditions. The result does not depend on whether customers can also obtain its source code. Identify the release, brand, intended use and EU supply route in the order form. (CRA, Arts 2(1), 3(13), 3(21)–(22).)
A source-available commercial licence may not meet the CRA's free and open-source definition. The parties should check the actual terms, rather than assume that the repository's licence governs every binary and dependency. The separate analysis of open-source licence terms for a supplier entering the EU explains why permission to distribute needs its own review.
A hosted component
A remote service can form part of the CRA product when two conditions are met. Its software must be designed and developed by the manufacturer, or under its responsibility. Its absence must also prevent the product from performing one of its functions. Record who controls development and which functions depend on the service. (CRA, Art 3(1)–(2).)
Standalone SaaS does not fall within the CRA merely because customers access it online. A generic third-party API is not automatically the SDK manufacturer's remote data processing solution. However, moving a required function to a supplier-controlled backend can keep it within the product boundary. Hosting location alone does not answer the question. (CRA, Art 3(2); recital 12.)
The French customer's product
If the fintech markets the assembled product under its own name, it has manufacturer responsibilities for that product. These include assessing the integration and, once Article 13 applies, exercising due diligence over incorporated components. The upstream supplier remains responsible for its own commercial SDK; that does not make it manufacturer of the entire customer product. (CRA, Arts 3(13), 13(3), 13(5).)
If the fintech instead first places the Egyptian-branded SDK on the EU market, it may be an importer. Later supply without affecting its properties may constitute distribution. Purchasing from Egypt does not automatically establish either role. Map the first EU supply, branding and onward distribution separately. (CRA, Art 3(16)–(17), (21)–(22).)
Assess modifications before promising coverage
A substantial modification is a change after market placement that affects compliance with the essential cybersecurity requirements set out in Annex I, Part I, or changes the assessed intended purpose. Either limb can suffice. Routine patches, recompilation and configuration changes are not automatically substantial; their effects require assessment. (CRA, Art 3(30).)
From 11 December 2027, an importer or distributor that places a product on the market under its own name or trademark or substantially modifies a product already placed on the market falls under Article 21's manufacturer obligations. Article 22 separately addresses another person who substantially modifies and makes the product available. Its responsibility concerns the affected part, or the whole product if the change affects the whole product's cybersecurity. (CRA, Arts 21–22, 71.)
This conversion analysis is distinct from manufacturing a new integrated product under Article 3(13). The French fintech cannot avoid its own product role by showing that an individual component change was minor.
Require a change notice identifying the baseline release, source changes, dependencies, configuration, intended use and security effects. The agreement should distinguish supported upstream builds from customer forks. Excluding bespoke engineering for an unapproved fork can define the purchased service, but cannot erase a party's applicable statutory duties.
Apply the dates to each obligation
As of 6 November 2026, Article 14 manufacturer reporting is already applicable. It covers awareness of an actively exploited vulnerability contained in the product and a severe incident affecting its security. An ordinary vulnerability report does not automatically satisfy either trigger. (CRA, Arts 14(1), 14(3), 14(5), 71.)
For both reporting routes, early warning is due without undue delay and within 24 hours of awareness. The next notification is due without undue delay and within 72 hours of awareness, unless the relevant information was already provided. Vulnerability final reports are due within 14 days after a corrective or mitigating measure becomes available. Severe-incident final reports are due within one month after the incident notification. Relevant information must also reach affected users as Article 14(8) requires. (CRA, Art 14(2), (4), (8).)
The parties need separate trigger assessments and coordinated submissions. The Egyptian manufacturer must identify its reporting destination under Article 14(7); a French customer does not automatically determine it. Contractual confidentiality must permit mandatory reporting. The related CRA reporting analysis for SDKs in fintech applications addresses the notification workflow.
Most remaining obligations apply from 11 December 2027. Products placed before that date generally enter the later requirements only if substantially modified from that date, while Article 14 still applies to earlier products. Article 24 steward obligations, including its limited reporting provisions, also start in December 2027. Do not treat a community steward as already subject to every manufacturer report. (CRA, Arts 24, 69(2)–(3), 71.)
Put security cooperation into the agreement
Use a distribution licence, a product and support schedule, and a vulnerability cooperation schedule. The customer contract should reflect the same boundaries. Six allocations need express treatment.
First, identify covered releases, dependencies and permitted uses. Confirm rights to modify and redistribute, attribution requirements, source-delivery obligations and restrictions on use of the supplier's brand. An open-source permission does not itself promise maintenance. French copyright law separately governs relevant reproduction, adaptation and distribution rights, subject to statutory exceptions. (Code de la propriété intellectuelle, Arts L122-6–L122-6-1; French text, unofficial English summary.)
Second, name security contacts and agree a short contractual notification deadline that leaves time for statutory assessment and reporting. Exchange affected versions, exploit information, customer impact and available mitigations. Neither party should have a contractual veto over the other's required report or user communication. Assign responsibility for monitoring upstream dependencies and informing their maintainers. From December 2027, Article 13(6) requires identified component vulnerabilities to be reported upstream and addressed. Where manufacturers develop a component fix, they must share the relevant code or documentation with its manufacturer or maintainer, using a machine-readable format where appropriate.
Third, allocate patch work by product. The Egyptian supplier should investigate and remediate its supported SDK releases. The French manufacturer should assess its changes, test integration and arrange deployment and communication for its customer product. Agree access to reproduction information, compatibility testing and emergency mitigation. Avoid promising a universal repair time unsupported by severity, architecture or available evidence. (CRA, Art 13(6); Annex I, Part II(2), (5), (7)–(8).)
Fourth, distinguish purchased assistance from statutory security support. Under the later regime, support must reflect expected use and generally last at least five years. A shorter expected use can justify less; a longer expected use can require more. Expiry of an annual support subscription cannot simply extinguish that obligation. Security updates must be free, subject to the narrow exception agreed with a business user for a tailor-made product. Each security update made available to users during the support period must remain available for at least ten years after issue or for the remaining support period, whichever is longer. (CRA, Art 13(8)–(9); Annex I, Part II(8).)
Fifth, address dependency end of life. Require advance notice, a replacement or maintenance plan, and allocation of migration work and cost. A component maintainer's withdrawal does not automatically shorten the downstream manufacturer's support commitment. Document the support rationale and communicate the end date at purchase. (CRA, Art 13(8), (19).)
Sixth, allocate commercial consequences: additional fork support, remediation costs, liability, insurance, termination assistance and access to necessary maintenance materials. Select governing law and dispute arrangements expressly. These are negotiation choices; they do not reassign public-law duties. If the French fintech is a financial entity within the Digital Operational Resilience Act (DORA), its information and communication technology contract also needs the applicable Article 30 terms. Outsourcing does not remove its responsibility under Article 28(1)(a). “Fintech” alone does not establish DORA status. (Regulation (EU) 2022/2554, Arts 2, 28, 30.)
Resolve the Egyptian supply conditions
At the Egyptian end, the rights file should match the product being sold. Record the source and binary versions, contributions, third-party licences and permissions needed for modification, distribution and support patches. The commercial contract should identify the rights granted to the French customer and the terms governing upstream components. Charging for a supported release does not establish ownership of every component or permission to remove licence conditions.
Domestic licensing also needs a documented position. The Arabic licensing application of Egypt's Information Technology Industry Development Agency (ITIDA) expressly includes software design, production and development, together with relevant hosting and outsourcing activities. Match the actual Egyptian operation to the applicable activity categories and obtain evidence of required permissions before commercial distribution. A CRA classification does not establish domestic permission. Keep the licence or supported exemption analysis with the supply records. (ITIDA, IT Activities Request Form, introduction and activity list; Arabic text, unofficial English summary.)
Describe any hosted component in the same file. The agreement should keep software supply and defined support distinct from operating financial services. Assess added services, including any access to customer data, before extending the offering.
Assemble the release evidence
For each commercial release, retain the product description, source commit, build identifier, integrity information, dependency inventory and licence record. Add the cybersecurity risk assessment, modification decisions, support-period rationale, integration instructions and vulnerability records. From December 2027, applicable CRA duties include technical documentation and conformity assessment, followed by an EU declaration of conformity and CE marking once conformity is demonstrated. (CRA, Arts 13(3)–(5), 13(12)–(13), 31–32; Annex VII.)
The software bill of materials must be machine-readable and cover at least top-level dependencies under Annex I, Part II(1). That does not create a blanket duty to publish it. Provide the integrator with the information necessary for compliant integration and documentation. Determine the conformity route from actual product functions and classification, rather than the word “fintech”. Important open-source products have a specific Article 32(5) option, conditional on public technical documentation. (CRA, Arts 7–8, 32; Annex II(8)(f), (9); Implementing Regulation (EU) 2025/2392.)
Start by recording the four product boundaries and EU supply routes. Then settle the rights and Egyptian licensing position, agree the support and cooperation schedules, and connect each release to its evidence. Establish the reporting workflow now and schedule the remaining conformity work against the applicable transition. Licentium's CRA readiness work addresses the role, evidence and contract questions involved.
Plan the CRA review
Review CRA roles in an open-source supply chain. Provide the distribution terms, product architecture and planned customer modifications so the assessment can address the actual supply model.