A product security lead at a US company that sells a desktop design application and a companion mobile app gets an email from her European channel partner. The partner is updating its supplier register and wants “a copy of your CE certificate under the Cyber Resilience Act” by the end of the month. The VP of Sales forwards it with one line: “Can we just buy this from someone?” Within a day, two consultancies offering “CRA certification packages” have replied to a LinkedIn post asking for recommendations.
For almost all software there is no such certificate to buy, because none is required. CE marking under the CRA is, in the typical case, a self-declaration by the manufacturer. It sits on top of technical documentation and a vulnerability handling process that must run for the whole support period. And one part of that process, reporting actively exploited vulnerabilities, has been mandatory for two months already, including for every version of the app this company has sold into the EU over the past few years.
This article is for CTOs, product security leads and compliance owners at companies that build and sell software, or devices running software, on the EU market, wherever they are headquartered. It defends one position that some advisers will dispute: CRA preparation should start with the support period and the ability to report, not with the question of CE certification. Companies that start with the certificate spend their budget on the least urgent element and leave the one that is already a legal duty without an owner. The analysis is based on the text of Regulation (EU) 2024/2847, the European Commission services’ “FAQs on the Cyber Resilience Act” (version 1.4, 4 September 2026) and the Commission’s CRA implementation pages.
Why is “do you have a CE certificate?” the wrong place to start?
Because it treats the CRA as a certification regime, when for most products it is a product lifecycle regime. The regulation sets two kinds of requirement. The first concerns product properties (Annex I, Part I): no known exploitable vulnerabilities at release, secure-by-default configuration, the ability to fix vulnerabilities through updates, access control, encryption, data minimisation and a limited attack surface. The second concerns processes (Annex I, Part II): identifying components and vulnerabilities, remediating them without delay, regular security testing, disclosing fixed vulnerabilities, a coordinated vulnerability disclosure policy and secure update distribution.
You can check the first set at release time. You have to run the second set for years. CE marking states that both are in place; it replaces neither. The Commission FAQ is explicit that the CE marking cannot be affixed before a conformity assessment procedure has been completed with a positive result, and for the vast majority of software it is the manufacturer who carries out that procedure.
The second reason is the order of deadlines. The full requirements, including conformity assessment and CE marking, apply from 11 December 2027. But Article 14, the duty to report actively exploited vulnerabilities and severe incidents, has applied since 11 September 2026, and Article 69(3) extends it to every in-scope product, including those placed on the market before December 2027. The US company in our example is therefore bound today to send an early warning within 24 hours if it learns that someone is exploiting a flaw in its app, and it has no obligation yet to carry a CE mark.
A better reply to the channel partner would read roughly: “Our products fall into the CRA default category. We will complete conformity assessment under module A before 11 December 2027. Our Article 14 reporting process has been live since September 2026; our vulnerability contact point and disclosure policy are here. The support period for the current major version ends in month X of year Y.” That tells a buyer more than a copy of any certificate.
Which software falls under the Cyber Resilience Act, and which does not?
Article 2(1) covers products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The Commission FAQ breaks this into three cumulative tests: the item meets the definition of a product with digital elements, it is made available on the market, and it has a data connection, even an indirect one.
The definition in Article 3(1) covers software and hardware together with their remote data processing solutions, including components placed on the market separately. In practice: an app downloaded from an app store, a program installed from a vendor website, firmware sold separately, printer drivers, a laptop’s operating system, an integrated circuit, an industrial machine. “Indirect connection” is broad. The FAQ cites an offline text editor or a calculator app, which do not open connections themselves but run on an operating system that does. Only products whose intended use includes no connection at all are outside: a dishwasher or coffee machine whose firmware has no connectivity.
“Making available on the market” means supply for distribution or use on the EU market in the course of a commercial activity, whether paid or free (Article 3(22)). A manufacturer is anyone who develops or manufactures a product, or has one designed, developed or manufactured, and markets it under its own name or trademark, “whether for payment, monetisation or free of charge” (Article 3(13)). An ad-funded free app or a free client for a paid service does not escape scope by having no price tag.
Geography does not help either. A manufacturer based in the US, UK or anywhere else is covered once its product is made available in the EU. It may appoint an authorised representative by written mandate (Article 18), but the core obligations of Article 13 cannot be delegated to that representative, and EU importers may only place compliant products on the market (Article 19). If you have no main establishment in the EU, Article 14(7) tells you which national CSIRT receives your reports: the one in the Member State of your authorised representative, then importer, then distributor, then where most of your users are, in that order.
The exclusions are specific. The CRA does not apply to products covered by the EU regulations on medical devices (2017/745) and in vitro diagnostics (2017/746), on vehicle type approval (2019/2144), to products certified under the aviation regulation (2018/1139), or to marine equipment (Directive 2014/90/EU). Delegated Regulation (EU) 2025/1535 also excluded products under Regulation 168/2013 on two- and three-wheel vehicles, except pedal-assisted L1e vehicles. Products developed or modified exclusively for national security or defence are excluded; dual-use products are not. Two more exclusions matter for engineering teams: tools built for your own use are not placed on the market, according to the FAQ, unless you also sell them; and Article 4(3) allows unfinished software (alpha, beta, release candidates) to be offered for a limited testing period with a visible notice that it does not comply.
What about SaaS, cloud backends and custom-built software?
Every CTO at a product company asks this, and the answer is less comfortable than many hope. Recital 12 states that cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements are not covered, and that SaaS, PaaS and IaaS are covered by the NIS2 Directive instead. Pure browser-based SaaS with no installed client is therefore not a product under the CRA.
The line is drawn by the definition of remote data processing in Article 3(2): processing at a distance for which the software is designed by the manufacturer or under its responsibility, and without which the product could not perform one of its functions. Recital 12 gives the example of a smart home manufacturer’s cloud features that let users control the device remotely. If you sell a mobile or desktop app and your backend is required for its functions, that backend is in scope together with the app. Risk assessment, data protection, vulnerability handling and documentation must cover both. The FAQ announced separate guidance on remote data processing, and the Commission’s non-binding guidance of 27 July 2026 (C(2026) 5252) covers, according to the Commission’s announcement, scope in relation to remote data processing and free and open-source software.
The architectural consequence is practical. A company that runs a SaaS product and also ships a mobile app whose features work only through its API effectively lives under two regimes: NIS2 for the service, if it meets the Directive’s size thresholds, and the CRA for the app plus the part of the backend that is its remote data processing. Draw that boundary on a component diagram before anyone concludes “we are SaaS, so this does not apply to us”.
The second case matters to software development firms and their clients: tailor-made software. The Commission FAQ (entry 4.2.5) gives as an example of a tailor-made product custom-developed software built for a specific business user, or products integrated into a customer’s tightly controlled environment under specific contract terms. The signal is important: the Commission assumes such software is within the CRA when supplied in a commercial activity. For tailor-made products, the manufacturer and business user may contractually depart from only two requirements, secure-by-default configuration and free security updates. Everything else applies. A CRM platform sold to many businesses with minor customisation is not tailor-made.
Who is the manufacturer then, the developer or the client? It depends on who markets the product under its own name. A client that commissions a product and sells it under its brand is the manufacturer, because the definition includes having a product designed or developed. A development firm delivering a system under its own name to one client is a less clear case that needs legal analysis of the actual contract. We covered the contracting side in our article on security by design and zero trust vendor requirements; the point here is to settle the question in the contract, not after the first incident.
When is open source in scope, and what is an open-source software steward?
Free and open-source software is in scope only when it is made available on the market, which means supplied in the course of a commercial activity. Recital 18 spells it out: FOSS that its manufacturer does not monetise is not supplied in a commercial activity, and a component intended for integration by other manufacturers is made available on the market only if its original manufacturer monetises it. Financial support from companies, contributions by companies or a regular release cadence do not, by themselves, make a project commercial. The regulation also does not apply to people who contribute code to projects they are not responsible for.
Between the manufacturer and the non-commercial project, the CRA creates a third role: the open-source software steward. It is a legal person, other than a manufacturer, whose purpose is to provide sustained support for the development of specific FOSS products intended for commercial activities and to ensure their viability (Article 3(14)). Recital 19 mentions foundations and entities that publish FOSS in a business context, including non-profits. Stewards have a light regime under Article 24: a cybersecurity policy for secure development and vulnerability handling, cooperation with market surveillance authorities and, from 11 December 2027, reporting obligations to the extent they are involved in development. Stewards do not affix CE marking and, under Article 64(10), are not subject to administrative fines.
For manufacturers building on open source, the key provision is Article 13(5). You must exercise due diligence when integrating third-party components, including FOSS that was never made available on the market. You are responsible for the product as a whole, every library included. When you find a vulnerability in a component, you report it to whoever maintains it and, if you wrote a fix, share the code (Article 13(6)). The FAQ lists examples of due diligence: checking a component’s update history, checking vulnerability databases, software composition analysis, security testing, sandboxing highly critical components, checking the component’s support period and reviewing its SBOM where available.
This shifts weight to a place many teams underestimate. If a library you depend on stops being maintained during your support period and a vulnerability appears, FAQ entry 4.3.7 is plain: you must remediate by other means, such as replacing the component or developing the patch yourself. Choosing a dependency becomes a commitment that runs five years or longer.
Is your product important or critical, and what does that change?
The product class decides whether you need a notified body at all. The regulation has four tiers: the default category, important products of class I and class II (Annex III), and critical products (Annex IV). Classification follows the product’s core functionality, not the components it contains. Technical descriptions of each category are set out in Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025.
Class I lists nineteen categories, including identity and privileged access management systems, standalone and embedded browsers, password managers, anti-malware software, VPN products, network management systems, SIEM systems, boot managers, PKI and certificate issuance software, operating systems, routers, modems and switches, microprocessors and microcontrollers with security functions, smart home products with security functions (door locks, security cameras, baby monitors, alarm systems) and connected toys with interactive or location features. Class II covers hypervisors and container runtime systems, firewalls and intrusion detection or prevention systems, and tamper-resistant microprocessors and microcontrollers. Critical products are hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes, and smartcards and secure elements.
Two FAQ principles prevent over-reading. Integrating an important product into another product does not make the host product important: a news app with an embedded browser is not a browser, and a laptop with a secure element is not a smartcard. It also cuts the other way: extra functions do not take a product out of its category. An operating system with a calculator is still an operating system. SOAR software that can perform SIEM functions is generally not a SIEM, because its core function differs.
| Category | Examples from the regulation and FAQ | Permitted conformity assessment | Notified body |
|---|---|---|---|
| Default | mobile app, game, editor, most business software | module A (internal control), or B+C, H | not required |
| Important, class I | operating system, browser, password manager, VPN, SIEM, router | module A only with full application of harmonised standards, common specifications or certification at “substantial” level or higher; otherwise B+C or H | depends on standards |
| Important, class II | hypervisor, container runtime, firewall, IDS/IPS | B+C, H or a European certification scheme | required |
| Critical | smartcard, secure element, smart meter gateway | B+C, H, or certification if the Commission mandates it | required |
| FOSS in class I or II | e.g. an open-source OS monetised by its manufacturer | module A, provided the technical documentation is made public | not required |
The awkward row is class I. Module A is available only if the manufacturer has fully applied harmonised standards. Those standards are being developed under standardisation request M/606, which according to the FAQ covers 15 horizontal standards (grouped into three deliverables) and 26 vertical standards for the Annex III and IV categories. The original adoption deadlines for the European standardisation organisations were 30 August 2026 for the secure development and vulnerability handling standards, 30 October 2027 for the product properties standard (Annex I, Part I) and 30 October 2026 for the vertical standards. On 10 November 2026 the Commission amended the request, extending by three months the deadline for all vertical standards and some horizontal ones. Module A for class I needs standards whose references have been published in the Official Journal of the EU. Before you plan a self-assessment for a class I product, check whether that reference exists for your category; if it does not, budget time and money for a notified body. The rules on notified bodies have applied since 11 June 2026, and the bodies will be listed in the NANDO database.
What does CE marking on software look like, and what is it not?
According to the Commission FAQ, CE marking is “a simple visual self-declaration of the manufacturer” that the product complies with all applicable EU harmonisation legislation, including the CRA. It is not a certificate, a quality label or proof that a third party checked the product. Even under modules B+C and H, where a notified body takes part, the manufacturer affixes the marking and signs the declaration of conformity, taking responsibility for it.
For software, Article 30(1) allows two forms: the CE marking goes on the EU declaration of conformity or on the website accompanying the product. In the second case, the relevant section must be easily and directly accessible to consumers. For devices, the usual rules apply: visible, legible and indelible, generally at least 5 mm high. Where a notified body was involved, its identification number follows the marking.
The declaration can be full (template in Annex V) or simplified (Annex VI), a single sentence with the web address of the full declaration. If several EU acts apply, for example the CRA and the Machinery Regulation, the manufacturer issues a single declaration covering all of them. The technical documentation (Annex VII) does not have to be shared with customers or the public, except for FOSS in class I or II assessed under module A. It must, however, be available to market surveillance authorities on request and kept for at least 10 years after the product is placed on the market or for the support period, whichever is longer (Article 13(13)).
That is why “CE certification”, the phrase procurement and sales teams type into search engines, misleads for most software. When a customer asks for a “CE certificate”, the answer is the declaration of conformity, the product category, the procedure used and, if a notified body was involved, the EU-type examination certificate. Paying a firm that is not a CRA notified body for a “certificate” changes nothing about the product’s legal status. Good application security consulting will tell you this in the first meeting. Timing matters too: CE marking under the CRA cannot be affixed before conformity assessment, and that assessment concerns requirements that apply from 11 December 2027.
What exactly must be reported since 11 September 2026?
Two types of event. The first is an actively exploited vulnerability: one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission (Article 3(42)). The second is a severe incident having an impact on the security of the product: one that affects or can affect the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or can lead to malicious code being introduced or executed in the product or in a user’s systems (Article 14(5)).
The deadlines are the same for both, with one difference in the final report:
- 24 hours from becoming aware: an early warning, naming the Member States where the product is available and, for incidents, whether unlawful or malicious action is suspected;
- 72 hours: a notification with general information about the product, the nature of the vulnerability or incident, measures taken and measures users can take, and how sensitive the manufacturer considers the information;
- 14 days after a fix or mitigation is available: the final report for a vulnerability (description, severity, impact, information on the attacker, details of the update);
- one month after the 72-hour notification: the final report for an incident (description, likely root cause, applied and ongoing mitigation).
Reports go through the single reporting platform run by ENISA, operational since 11 September 2026, to the coordinating CSIRT of the Member State of your main EU establishment, with simultaneous access for ENISA. Separately, you must inform impacted users, and where appropriate all users, about the vulnerability or incident and the mitigations they can apply, where appropriate in a structured, machine-readable format (Article 14(8)). If you do not do so in time, the CSIRT may.
Three FAQ clarifications change how an on-call process should be organised. First, a zero-day reported through a bug bounty programme or found by a lab you hired, with no evidence of malicious exploitation, is not subject to mandatory reporting; you may report it voluntarily under Article 15. Second, a vulnerability in a third-party component that cannot be exploited in your product is not actively exploited, but you must report it to the component’s maintainer. Third, for products placed on the market before December 2027 you must report even if you can no longer investigate, for example because the old build environment cannot be recreated; the other Annex I, Part II obligations do not apply to those legacy products.
The element most often underestimated is not the form but the question of who “becomes aware”, and how. The 24-hour clock starts when the manufacturer learns of active exploitation. The signal may come from a customer, a threat intelligence report, a government agency, an ethical hacker or your own telemetry. If a customer’s report sits in a support queue for three days before reaching anyone who can judge it, you have a legal problem, not just an operational one. The single point of contact for vulnerability reports required by Article 13(17) and Annex II therefore needs an escalation path to someone who can assess evidence within hours, as part of an established vulnerability management practice.
Micro and small enterprises cannot be fined for missing the 24-hour early warning deadline (Article 64(10)(a)). That relief concerns the penalty, not the duty: the 72-hour notification and final reports apply to them in full.
Why is the support period a pricing decision, not a line in your terms?
Because throughout that period you must handle vulnerabilities in the product and its components effectively, and the cost of that commitment grows with every year and every version you ship. Article 13(8) says the support period must reflect the time the product is expected to be in use, taking into account reasonable user expectations, the nature of the product and other EU law. It must be at least five years. It may be shorter only if the product is expected to be in use for less than five years, in which case it matches the expected use time.
The FAQ and Recital 60 add that five years is a floor, not a default. Routers, modems, switches, operating systems, video editing tools and above all industrial control systems are used for longer, so their support periods should be longer too. A shorter period is justified for, say, an app with a built-in limited lifespan, or software that by its nature only works under an active subscription and becomes unavailable when it ends. For FOSS monetised through paid support subscriptions, the support period equals the duration of the active subscription.
Three related commitments are easy to miss:
- The end date, at least month and year, must be clearly stated at the time of purchase (Article 13(19)). Where technically feasible, the product should notify users when the support period has ended.
- Every security update must stay available for at least 10 years after release or for the remainder of the support period, whichever is longer (Article 13(9)).
- The information used to set the support period goes into the technical documentation (Article 13(8)), so a market surveillance authority can ask why you chose five years for a product customers typically run for eight.
Why is this a pricing decision? Take an industrial device sold for ten years of production with a seven-year support period per batch. The FAQ (entry 4.5.3) explains that support periods attach to units placed on the market, so the last production year’s batch carries the obligation seven years further. In practice, the company maintains the ability to ship security fixes for seventeen years after launch. That means engineers, build environments, signing keys, dependency monitoring and on-call cover. If none of that is in the product price or the service contract, it comes out of margin.
Article 13(10) gives software one relief: a manufacturer that has released subsequent substantially modified versions may provide security fixes only for the latest one, provided users of earlier versions can move to it free of charge and without extra hardware or software costs. That is a strong argument for a versioning policy where upgrading to the latest major version is free and does not demand new hardware. We described how to release without breaking client integrations in our article on semantic versioning; under the CRA it also has a legal dimension, because Annex I requires security updates to be released separately from feature updates where technically feasible.
The support period also reshapes vendor contracts. A one-year maintenance agreement with a development partner does not cover a five-year manufacturer obligation. We worked through what application maintenance really costs at different SLA levels in our article on maintenance cost after launch; for CRA-covered products the horizon of that calculation must extend to the end of the support period of the last batch or version you sell.
What does the CRA actually require of an SBOM?
Less, and at the same time more, than much of the marketing suggests. Annex I, Part II, point 1 requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies.
Three things follow directly. First, the minimum is top-level dependencies, not the full transitive tree. Second, the regulation does not prescribe a format; Article 13(24) allows the Commission to specify format and elements through an implementing act. Until then, teams use formats common in the industry, such as SPDX or CycloneDX. Third, and this is the most frequent misunderstanding, the CRA does not require you to publish your SBOM. The SBOM is part of the technical documentation (Annex VII), and a market surveillance authority can demand it on a reasoned request. Annex II requires telling users where the SBOM can be accessed only “if the manufacturer decides to make available” it.
Earlier writing, including our own SBOM guide from December 2025, emphasised “providing” SBOMs. More precisely, the CRA requires you to produce and maintain one; sharing it with customers is a business decision. Customers subject to NIS2 or DORA will often ask for it in supplier questionnaires anyway, so keep a shareable version ready.
Why “more”? Because an SBOM generated once at release does not serve the provision’s purpose. The purpose is being able to answer “does our product contain component X in version Y?” within hours when a new vulnerability lands, and linking that to the reporting duty if the vulnerability is actively exploited. That requires an SBOM versioned with every release, retained for the support period and wired into vulnerability monitoring. Annex I also demands “effective and regular tests and reviews” of product security; the cheapest way to meet that is to make it an exit criterion for every change. We showed how to do that without bolting on a separate testing phase in our article on the Definition of Done.
What are the fines, and when can they be imposed?
Article 64 sets three tiers of administrative fines, in each case the higher of two amounts:
- up to EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, for breaching the essential requirements in Annex I and the obligations in Articles 13 and 14;
- up to EUR 10 million or 2% for breaching other obligations listed in Article 64(3), including importer and distributor duties and the rules on declarations of conformity, CE marking and technical documentation;
- up to EUR 5 million or 1% for supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities.
For any company with worldwide turnover above EUR 600 million, the percentage rather than the fixed amount sets the ceiling of the top tier. Member States lay down the penalty rules and the enforcing bodies. When setting a fine, authorities consider the nature, gravity and duration of the breach, previous fines and the size of the company, with particular regard to micro, small and medium-sized enterprises and start-ups. Fines can be combined with other measures, including orders to withdraw a product.
There is a nuance worth knowing but not worth building a strategy on. Article 71(2) applies Article 14 from 11 September 2026 and the rest of the regulation, Article 64 included, from 11 December 2027. Read literally, the reporting duty binds you today while the EU basis for administrative fines starts in December 2027. That does not make the duty empty. Failing to report is a breach of law that authorities and customers will see at the first incident, and liability for damage flows from other rules, including the new Product Liability Directive (EU) 2024/2853, whose interplay with the CRA the Commission FAQ discusses. How this nuance affects your exposure in a given Member State is a question for counsel who knows the national implementing rules.
A more realistic cost than a fine is withdrawal. Article 13(21) requires a manufacturer who knows or has reason to believe a product or its processes are non-compliant to take corrective action immediately or withdraw or recall the product. The FAQ notes this may arise mainly for hardware with a vulnerability that cannot be fixed. For a device maker, that risk outweighs any fine.
How should you sequence preparation for 11 December 2027?
A little over twelve months remain. Sequence matters, because some elements are mandatory already and others depend on standards that do not yet exist. The plan below assumes a default-category or class I product developed by an in-house team with external partners.
| Area | Legal basis | Must work by | What must exist | Owner |
|---|---|---|---|---|
| Vulnerability and incident reporting | Art. 14, Art. 69(3) | since 11 Sep 2026 (now) | ENISA platform access, 24/72-hour procedure, escalation path, report and user advisory templates | CISO or head of product security |
| Contact point and disclosure policy | Art. 13(17), Annex I Part II(5)–(6) | needed for reporting now; formally by 11 Dec 2027 | public reporting address, coordinated disclosure policy, response times | product security |
| Product classification | Art. 7–8, Reg. 2025/2392 | Q1 2027 | core functionality description, category, choice of module | CTO with compliance |
| Support period | Art. 13(8)–(9), (19) | before 2027/2028 pricing is set | justified period per product, cost in budget, end date in sales materials | leadership, product management |
| Risk assessment | Art. 13(2)–(4) | Q2 2027 | documented assessment covering remote data processing and components | security architect |
| SBOM and due diligence | Annex I Part II(1), Art. 13(5)–(6) | Q2 2027 | SBOM per release, dependency vulnerability monitoring, component selection policy | DevSecOps |
| Separate security updates | Annex I Part II(2), (7)–(8) | Q3 2027 | security fix channel independent of features, signing, automatic updates with opt-out | release engineering |
| Technical documentation and declaration | Art. 13(12)–(13), Art. 28, 31, Annexes V, VII | Q3–Q4 2027 | Annex VII documentation, declaration of conformity, CE page for software | compliance |
| Notified body (if required) | Art. 32 | book in H1 2027 | contract with a body listed in NANDO, type examination schedule | CTO |
The table shows the argument of this article. The first two rows are a legal duty, or its direct precondition, right now. The support period must be set before pricing is fixed for the years in which the product will fall under the CRA. Documentation and CE marking come last, because they summarise work done earlier rather than start it. If your organisation runs this list in reverse, the budget goes to whoever writes documentation and nobody owns the reporting rota.
Two notes on uncertainty. First, the standards deadlines have just moved, so a class I manufacturer counting on module A needs a fallback plan with a notified body. Second, the Commission’s July 2026 guidance includes, according to its announcement, 67 practical examples and flowcharts aimed at smaller companies. Walk through them with counsel when classifying your product; they are non-binding but show how the Commission reads the text.
What does the CRA change in contracts with vendors and external teams?
The manufacturer is responsible for the whole product, whoever wrote the code. If you use an external development partner, contractors or staff augmentation, the CRA obligations stay with you. The contract must therefore pass to the vendor the work without which you cannot meet your deadlines, without pretending to transfer responsibility the law does not let you transfer.
Five clauses carry practical weight. One: vendor response time to a vulnerability report measured in hours and aligned with your 24-hour clock, not in business days as in a typical SLA. Two: an SBOM for every release and notice of components whose support ends before yours. Three: your ability to ship a fix without the vendor, meaning access to source code, build environments, signing keys and documentation. Four: a vendor support commitment for vulnerability handling matched to your support period, or a clear takeover plan. Five: a duty to cooperate on notifications and final reports, including the technical data your 14-day report requires.
This matters most for embedded software, where device support periods are long and dependence on the firmware vendor is high. We covered that in our article on embedded software outsourcing, and the decisions to make before building an IoT device, including OTA updates and end of life, in our piece on IoT consulting.
A warning for companies that are vendors themselves. Under Article 22, a person other than the manufacturer, importer or distributor who substantially modifies a product and makes it available on the market becomes the manufacturer for the modified part, or for the whole product if the change affects its overall cybersecurity. A substantial modification is one that affects compliance with Annex I, Part I or changes the intended purpose (Article 3(30)). An integrator that reworks someone else’s product and resells it under its own name should run that analysis before signing.
What are the key takeaways for CTOs and compliance teams?
For software makers, the Cyber Resilience Act is first a law about how long and how fast you must respond to vulnerabilities, and only last a law about CE marking. For most products the CE mark is a self-declaration with no notified body involved. Its value depends entirely on the process behind it.
Remember six things. First, the duty to report actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, with 24-hour, 72-hour, 14-day and one-month deadlines, and it covers products sold before December 2027 too. Second, test scope honestly: an app with an essential backend is a product plus its remote data processing, and custom software for a business client sits within the CRA with two contractual exceptions. Third, classify by core functionality; only class I without harmonised standards, class II and critical products need a notified body. Fourth, the support period is at least five years, with the end date stated at purchase and updates available for ten years, so price it in. Fifth, produce and maintain an SBOM with every release, but the CRA does not require you to publish it. Sixth, fines reach EUR 15 million or 2.5% of turnover, but for device makers a withdrawal order is the bigger risk.
If you need engineers who can build the vulnerability handling process, SBOM generation in the pipeline, a separate security fix channel and an on-call rota ready for a 24-hour notification, see how our DevOps and DevSecOps engineers work: a specialist can join your team within two weeks, with a two-week replacement guarantee. Or book a call to walk through a preparation plan for 11 December 2027 for your product.