The Cyber Resilience Act has been treated, in most financial institutions, as somebody else's regulation. It imposes obligations on manufacturers of products with digital elements, and banks, e-money institutions and CASPs do not, on the whole, manufacture software. That framing was defensible until this month. Since 11 September 2026, every manufacturer whose software is on the Union market has been obliged to report actively exploited vulnerabilities and severe incidents to a CSIRT and ENISA within 24 hours of becoming aware of them, and the ENISA Single Reporting Platform through which those reports are filed went live on the same day. From 11 December 2027 the full conformity obligations apply, and the software running inside your critical or important functions will carry, or will be supposed to carry, a CE marking and an EU Declaration of Conformity.

That matters to you for a direct reason. Article 28(4) and 28(5) of DORA require you to assess your ICT providers' information security standards before you contract, and Article 28(3) requires you to record their products in your register of information. Whether a vendor has understood the CRA, and what it says when you ask, is now one of the sharpest tests you have of that vendor's security maturity. We have spent the last year reviewing vendors' CRA positions, and the same errors recur. This piece sets them out, and ends with the questions we suggest putting to any software vendor whose product supports a critical or important function. It is written for the financial entity, but a vendor reading it as a checklist will be a better vendor for it. Nothing in it concerns any particular client.

The grandfathering that does not grandfather

The first thing most vendors say is that the CRA does not really apply to them until December 2027, and that products already on the market are exempt. Both halves are wrong in ways that matter.

Article 69(3) provides that the Article 14 reporting obligations apply to all products with digital elements placed on the market before 11 December 2027. Every version of every product already deployed at your institution has been within the reporting obligation since 11 September 2026. Article 69(2) provides that products placed on the market before 11 December 2027 are subject to the other requirements only if they are substantially modified after that date, and Article 3(30) defines a substantial modification as a change following placing on the market that affects compliance with the essential requirements or modifies the intended purpose. The Commission's guidance of 27 July 2026 confirms that a substantially modified product is treated as newly placed on the market, and that security updates are not substantial modifications whereas functional changes may be.

For hardware with a five-year model cycle, that is a real transition period. For software released weekly with feature content, it is nothing. A version that is inside the grandfathering on 11 December 2027 will have been substantially modified, and therefore newly placed on the market with full obligations, within weeks. The only customers protected by Article 69(2) are the ones who freeze on a pre-December 2027 version and never update, which is not a position a DORA financial entity can take. A vendor whose plan is to "deal with the CRA in 2027" is telling you that its December 2027 releases will be non-compliant.

The classification trap in the access-control layer

The CRA sorts products into default, important (Annex III, in two classes) and critical (Annex IV). A default product self-assesses under Module A. A Class I important product may self-assess only if it fully applies a harmonised standard, common specification or European cybersecurity certification scheme covering it, and otherwise needs third-party assessment by a notified body. No harmonised standard has yet been cited in the Official Journal for any category, so today every Class I product needs a notified body. Vendors know this, and the incentive to find themselves in the default category is strong.

Article 7(1) makes the test the core functionality of the product against the Annex III categories, and Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 supplies the technical descriptions. Class I, point 1 covers identity management systems and privileged access management software, and the technical description expressly includes access management systems that control access of natural persons, legal persons, devices or systems to digital resources. That description catches more than single sign-on products. A great deal of enterprise and financial infrastructure software contains a permissioning, gateway or policy-enforcement layer whose whole purpose is to authenticate callers and decide what they may read and do. We have seen more than one vendor argue that such a layer is not identity management because it governs access to a database, or a ledger, or a message bus, rather than to "IT systems". We do not think that distinction is as safe as it is presented. A component whose core function is deciding who may access what is an access management system whatever the resource.

The better argument is usually a different one, and it is in the second subparagraph of Article 7(1): the integration of an Annex III component into a product does not in itself make that product important. A platform whose core functionality is settlement, or trading, or record-keeping, with access control as one of its layers, is a default product even if the access-control layer would be Class I on its own. That defence holds only for as long as the component is never placed on the market separately, since Article 3(1) treats components placed on the market separately as products in their own right. The questions to put to the vendor are therefore whether its access-control layer is ever supplied, licensed or open-sourced as a standalone module, and whether its risk assessment records why the product's core functionality falls outside every Annex III category. A vendor that has not asked itself those questions has not classified its product; it has assumed a classification.

For completeness, the hypervisor and container runtime category in Class II and the firewall and intrusion detection category are the other traps we see in infrastructure software, and the same core-functionality analysis applies.

The backend nobody inventories

Article 3(1) defines a product with digital elements to include its remote data processing solutions, and Article 3(2) defines remote data processing as processing at a distance, designed and developed by or for the manufacturer, the absence of which would prevent the product from performing one of its functions. The Commission's guidance applies a three-part test and makes the point that what matters is who designed the backend, not who operates it. Software-as-a-service as such is outside the CRA, but a cloud component on which an installed product depends is inside it.

Vendors' component inventories are almost always drawn around what they ship. The hosted settlement gateway, the licence server, the update service, the relayer or the aggregation service that the installed software cannot work without is left off, on the basis that it is infrastructure rather than product. If the vendor designed it and the product cannot function without it, it is part of the product, it is within the essential requirements and the technical documentation, and a vulnerability in it that is exploited in the wild is reportable under Article 14. From the financial entity's side, this is also a DORA question, because that hosted component is a dependency of your critical function that will not appear in the vendor's architecture diagram or, consequently, in your register.

The open-source question vendors ask, and the one they do not

Almost every vendor whose product includes open-source components asks whether the free and open-source software provisions take those components out of scope. For the commercial product, the question is misconceived. The product is one product with digital elements; its components are part of it whatever their licence; and Article 13(5) requires the manufacturer to exercise due diligence when integrating third-party components, expressly including open-source components not supplied commercially, so that they do not compromise the product's security. The software bill of materials required by Annex I, Part II, point 1 must cover them. The licence of a component is relevant to the SBOM's licence fields and to the vendor's own open-source compliance, and to nothing else.

The question that is usually not asked concerns the vendor's separate public open-source distribution, where it has one. That distribution is made available in the Union, and whether it is made available in the course of a commercial activity turns on Recitals 15 and 18: charging a price, charging for support beyond cost recovery, or an intention to monetise, including through a platform through which the manufacturer monetises other services. A vendor that monetises the ecosystem around its open-source code may be the manufacturer of the public distribution with full obligations; if the public code is supported by a foundation rather than the vendor, the lighter open-source software steward regime in Article 24 may apply to the foundation. For the financial entity, the practical point is that when a vulnerability in that public codebase is exploited, someone is responsible for the Article 14 report and the fix, and you want to know who.

Support periods, security updates and the subscription that lapses

Article 13(8) requires the manufacturer to set a support period reflecting the expected period of use, of at least five years unless the expected use is shorter, and Annex II requires the end date to be stated in the information accompanying the product. Article 13(9) requires each security update issued during the support period to remain available for at least ten years. Annex I, Part II, point 8 requires security updates to be disseminated without delay and free of charge.

Those obligations are owed to users of the product placed on the market. They do not depend on the continuation of a services contract. A licence that provides, as most currently do, that a customer whose subscription lapses may keep using the software but will receive no updates, bug fixes or security patches is, from 11 December 2027 and for any version placed on the market after that date, inconsistent with the CRA as regards the security patches. Feature updates, non-security bug fixes, support and hosting can be conditioned on payment; security updates cannot. This is also the point at which the CRA and DORA's exit requirements converge: the transition period under Article 30(3)(f) DORA and the support period under Article 13(8) CRA both require the vendor to keep patching after the commercial relationship has changed, and one set of contract terms should satisfy both.

Article 14 in practice

The reporting obligation is the part of the CRA that is live, and it is the part vendors most often describe as done when it is not. The timelines are straightforward: an early warning within 24 hours of awareness, a notification within 72 hours, and a final report within 14 days of a corrective measure being available for an exploited vulnerability or within a month of the notification for a severe incident. The difficulties are elsewhere.

Awareness is the trigger, and most procedures do not say what it means or who has it, so the 24 hours are consumed by internal escalation. The definition of a severe incident in Article 14(5) has two limbs, and procedures routinely omit the second, which covers incidents that have led or could lead to the introduction or execution of malicious code in the product or in a user's systems; a compromised container image or build pipeline is caught by that limb whether or not any data has been touched. A non-EU manufacturer's coordinating CSIRT is determined by a cascade that the Commission's guidance reads as running through the Member State of its authorised representative, then its importer, then its distributor, and only then the Member State with the highest concentration of its users; a vendor that has reached the last step by counting customers has a determination that changes every time it wins a deal, and that would be fixed by appointing an authorised representative under Article 18, which we generally recommend. And user notification under Article 14(8) requires the manufacturer to inform impacted users; a vendor that sells to a small number of identifiable institutions and proposes to inform them by publishing a notice on its website has misread the obligation.

For a DORA financial entity, the last point has a specific edge. Your own clock under Article 19 DORA runs from awareness, and you will want a contractual commitment that the vendor tells you no later than it tells the regulator, and preferably within an hour of detection, so that you are never the last to know about an incident in your own critical function. The vendor's Article 14 procedure and your contract should be drafted to the same rule.

Standards, or the absence of them

Under Article 27, conformity with a harmonised standard cited in the Official Journal gives a presumption of conformity with the essential requirements it covers. As at the date of this article, none has been cited. The horizontal vulnerability-handling standard in the EN 40000 series is the most advanced, the generic security requirements standard is due late in 2027, and the vertical standard for identity management is in development with no public draft. For a default product this does not block self-assessment; it means the vendor's technical documentation has to demonstrate conformity with Annex I on its own terms, and the sensible vendor is structuring that documentation around the draft standards so that alignment can be claimed once they are cited. For a Class I product it means there is no self-assessment route today and will not be one for identity management before 2028, which is why the classification question above is not academic.

What to ask your vendors

The questions below are the ones we would put, in prose rather than a form, to any software vendor supporting a critical or important function. Which legal entity is the manufacturer for CRA purposes, and where is it established; if it is outside the Union, has it appointed an authorised representative, and which CSIRT has it identified as its coordinator. What is the product's classification, and where is the reasoning recorded; if the product has an access-control layer, is that layer ever supplied separately. Which hosted components does the installed product depend on, and are they within the vendor's technical documentation. What is the support period for the version you are running, when does it end, and are security updates available free of charge for that period irrespective of your subscription. Can you have the software bill of materials, in CycloneDX or SPDX, for the version you run, and how is it updated. Where are the EU Declaration of Conformity and the Annex II information, and which versions do they cover. What is the vendor's Article 14 procedure, who are its registered reporting representatives, when was it last tested, and what does it say about notifying you. Is there a coordinated vulnerability disclosure policy and a single point of contact for reports. And, finally, how does the vendor classify each release as a security update, a minor change or a substantial modification, since that classification is what determines whether the version you are about to install is a compliant product at all.

A vendor that can answer those questions has done the work. A vendor that cannot has told you something useful about its security programme that no questionnaire would have revealed.

How we can help

Axis Group advises software and infrastructure vendors on the Cyber Resilience Act and financial entities on the due diligence the CRA now makes possible. For a vendor, our review validates or corrects the applicability, manufacturer, product boundary and classification positions, tests the Article 14 procedure against the regulation and the Commission's guidance, reviews the contract terms on support periods and security updates against Annex I, and delivers a memorandum with tiered recommendations, a marked-up reporting procedure and a conformity roadmap to 11 December 2027. For a financial entity, we review vendors' CRA statements as part of DORA Article 28 due diligence and translate them into contract terms and register entries. The two regimes are converging on the same documents, and we advise on both.

If you would like to discuss a product, a vendor or a portfolio, get in touch.

This article is general commentary and not legal advice on any particular product or arrangement.