An EU customer requests a Cyber Resilience Act compliance commitment, a support period and evidence for its product file. Before signing, the supplier needs to establish what it supplies, which duties it owns and what engineering can substantiate. Licentium’s CRA legal-readiness review connects those decisions to the customer agreement and release process.
Cyber Resilience Act requirements already include manufacturer reporting, which has applied since 11 September 2026. Most product, support and conformity duties apply from 11 December 2027, with a transition for products placed earlier. The engagement produces a product and role map, legal requirements for the evidence file, a reporting decision process and a lifecycle contract schedule. These outputs identify commitments that can be accepted and conditions that must be closed before the relevant release. (Regulation (EU) 2024/2847, the CRA, Articles 13–14, 69 and 71.)
Suppliers and products covered
The review is designed for overseas AI, fintech software development kit (SDK) and connected-software suppliers selling into the EU, including businesses in India, Vietnam and Kenya. It addresses a company supplying an installable AI component and a related hosted service for European financial products.
The installed component and hosted functions need separate examination. A separately marketed software component can qualify where its intended or reasonably foreseeable use includes a direct or indirect data connection. Remote processing forms part of 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. Standalone SaaS requires a different assessment; calling a bundle a service does not decide its scope. (CRA, Articles 2(1), 3(1)–(2), (6), (10), (22); recitals 11–12.)
Products developed exclusively for internal use, non-commercial open-source development and sector-specific exclusions need their own scope decision. A financial customer or an AI label creates no general exemption. The review records which component, version and hosted function each conclusion covers. (CRA, Articles 2–3; recitals 17–20.)
Four outputs for the product and customer agreement
Product scope and economic operators
The first output maps the supplied products, distribution routes, branding and responsible entities. The supplier can be the component manufacturer while its customer separately manufactures the finished application. An EU customer is not automatically an importer: that role depends on who first places the foreign-branded product on the EU market. A distributor’s role concerns subsequent supply without affecting the product’s properties. (CRA, Article 3(13), (16)–(17), (21)–(22).)
The map also identifies any EU authorised representative and the tasks covered by its written mandate. Core manufacturer duties cannot all be transferred through that appointment. From 11 December 2027, the review must also account for manufacturer responsibilities arising through rebranding or substantial modification. Open-source steward status has its own statutory conditions and does not follow merely from publishing source code. (CRA, Articles 3(14)–(15), 18, 21–24 and 71.)
The deliverable assigns evidence, reporting and contractual cooperation to named entities, and records the distribution facts still needed. Our analysis of product security accountability under the CRA explains the underlying role distinctions.
Legal requirements for the evidence and release file
The second output connects applicable legal requirements to the records that engineering must produce. It covers intended use, foreseeable deployment, architecture, cybersecurity risk assessment, third-party components, vulnerability handling, test evidence, user instructions and support-period justification. The release file identifies the owner of each record and any gap preventing the proposed compliance statement. (CRA, Article 13(2)–(8), (12)–(13), (18)–(20), Article 31 and Annex VII.)
Product classification determines the conformity route. The assessment tests core functionality against the important and critical categories and their technical descriptions. An AI component used by a bank is not automatically an important CRA product. Internal assessment is available for many products; specified categories require a different route. (CRA, Articles 7–8 and 32, Annexes III–IV; Implementing Regulation (EU) 2025/2392, Article 2 and Annexes I–II.)
Legal review defines the evidence requirements and checks the wording of declarations and customer assurances. Engineering supplies and validates technical evidence. A notified body or other qualified assessor must perform any assessment reserved to it. The manufacturer issues its EU declaration and affixes CE marking after the applicable conformity process. The engagement provides no CE certification or guaranteed compliance. (CRA, Article 13(12), Articles 28–32 and Annex VIII.)
Vulnerability reporting and customer notification
The third output is a decision process for two reporting triggers: an actively exploited vulnerability contained in the product, and a severe incident affecting its security. Engineering supplies the exploitation and impact evidence; the process records awareness, the affected product, the legal reporting owner and recipients. A vulnerability’s severity score alone does not establish active exploitation. (CRA, Article 3(42), Article 14(1), (3) and (5).)
Early warnings are due without undue delay and within 24 hours of awareness; fuller notifications without undue delay and within 72 hours of that same awareness. 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 fuller notification. Relevant information already supplied need not be repeated. Reports go through the Single Reporting Platform to the designated national computer security incident response team (CSIRT) coordinator and the EU Agency for Cybersecurity (ENISA). An overseas manufacturer’s reporting destination follows the ordered tests in Article 14(7), rather than automatically following its customer. Impacted users, and where appropriate all users, need separate information under Article 14(8). (CRA, Article 14(1)–(8).)
The contract should permit prompt preliminary notice, evidence sharing and required disclosures while protecting sensitive technical information. Each manufacturer remains responsible for its own product assessment. Our analysis of CRA reporting for AI SDKs in EU fintech apps explains the component and application reporting decisions.
Support and supply-chain contract schedule
The fourth output addresses supported versions, patch development, testing, secure delivery, installation responsibilities, component replacement and end-of-support arrangements. It separates statutory duties from additional service commitments negotiated with the customer.
When the later CRA duties apply, the support period must reflect expected use. It must generally last at least five years; a product expected to be used for less has a correspondingly shorter period. Longer expected use can require longer support. The end date must be disclosed at purchase. Upstream support expiry therefore needs a replacement or maintenance plan where the supplier’s own obligation continues. (CRA, Article 13(5), (8) and (19).)
Security updates must generally be free, with a specific contractual exception for tailor-made products supplied to business users. Update availability also differs from active support: each issued security update made available to users during the support period must remain available for at least ten years after issue or the remaining support period, whichever is longer. (CRA, Article 13(9); Annex I, Part II, point 8.)
Remediation may be limited to the latest software version placed on the market only if the manufacturer has placed subsequent substantially modified versions on the market and users can upgrade free of charge and without additional costs to adjust their hardware or software environment. (CRA, Article 13(10).)
The schedule allocates change notices, emergency fixes, migration costs, indemnities and liability limits. Compliance warranties should identify the product versions, applicable dates, integration assumptions and supporting evidence. Enforceability depends on the governing law and wording. A customer approval process must allow timely security action. Where the customer falls within the Digital Operational Resilience Act (DORA), the agreement also needs the applicable terms for information and communication technology services, including incident assistance and, for critical or important functions, enhanced audit and exit provisions. (Regulation (EU) 2022/2554, Articles 28–30.) Broader commercial terms can be addressed through AI supplier contracts for EU and UK enterprise sales.
Engagement sequence and input documents
Scoping begins with the product architecture and supply chain. Legal classification then identifies the applicable duties and dates. Engineering confirms the available evidence and remediation work. Contract drafting follows those findings, and the closing review records unresolved conditions, responsible people and the release decision they affect.
Provide the available documents:
- Product descriptions, architecture and data-flow diagrams, release history and intended-use statements.
- Component inventories, licences, supplier agreements and available security assessments.
- Customer contracts, procurement questionnaires, support policies and proposed compliance warranties.
- Incident procedures, security contacts, hosting locations and countries from which staff access customer data.
- Contracting entities, branding, EU distribution arrangements and the proposed governing law.
Home-country rules and permissions
Home-country rules change the reporting and evidence process. Indian covered entities must report listed cyber incidents to India’s Computer Emergency Response Team (CERT-In) within six hours of noticing them or being notified. Vietnamese cross-border personal-data transfers can require an impact-assessment dossier filed within 60 days of the first transfer, subject to statutory exceptions. A covered Kenyan data processor must notify its controller of a personal-data breach without delay and, where reasonably practicable, within 48 hours of awareness. (India, CERT-In Directions, 28 April 2022, paragraph (ii); Vietnam, Law 91/2025/QH15, Article 20(1)–(2), (6); Kenya, Data Protection Act 2019, sections 4 and 43(3).)
Encryption functions, hosted data-processing services and any regulated financial activity need their own permission analysis. The input documents must establish the proposed functions and data flows.
Questions before commissioning
Can the work wait until December 2027?
Manufacturer reporting already applies, including to covered products placed before the general application date. Earlier products generally enter the later requirements if substantially modified from 11 December 2027. The review therefore starts with existing releases and the current reporting process. (CRA, Articles 69(2)–(3) and 71.)
Does using open-source software remove manufacturer duties?
It does not remove duties for a commercial product that incorporates it. Component due diligence and vulnerability handling must be addressed when the relevant duties apply. A qualifying open-source steward has a distinct regime, including reporting from 11 December 2027. (CRA, Articles 13(5)–(6), 24 and 71.)
Must every customer receive the full software bill of materials?
The CRA requires a machine-readable component record covering at least top-level dependencies when its vulnerability-handling duties apply. It does not impose a general duty to provide that record to every customer. Integration information and authority access have separate requirements; customer access should be negotiated accordingly. (CRA, Annex I, Part II, point 1; Annex II, points 8(f) and 9; Annex VII, point 8.)
Can legal review approve an insecure release?
The release recommendation must reflect the technical evidence and applicable requirements. Missing evidence can require testing, a narrower product or delayed release. Penetration testing, remediation, statutory representation and conformity assessment require their own agreed scope and appropriately qualified providers.
Does CRA readiness settle every EU requirement?
The product may also need AI Act analysis, while hosted services and personal-data handling can raise separate duties. Financial-sector procurement requires the customer’s DORA position to be checked. The engagement identifies those dependencies so the CRA conclusion is not used beyond its product-security scope. (CRA, Article 12; Regulation (EU) 2016/679, Articles 28, 32–34 and 44–49; DORA, Articles 28–30.)
Assess CRA duties for your software product
Contact Licentium with the component and hosted-service description, target EU markets and customer terms. The consultation will define the product-role assessment, evidence requirements and lifecycle commitments requiring review.