Update: 28 July 2026
What is the Cyber Resilience Act and why does it matter for software houses? The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is the first horizontal EU law imposing mandatory cybersecurity requirements on software and hardware made available on the Union market. If your company builds and supplies software commercially – own products, mobile apps, components and, in many cases, bespoke software delivered to clients – the CRA now dictates how you design, maintain and report on it.
Canonical Definition: The Cyber Resilience Act (Regulation (EU) 2024/2847) establishes horizontal cybersecurity requirements for products with digital elements made available on the EU market, covering secure design, vulnerability handling, conformity assessment and CE marking.
Cyber Resilience Act for software houses – key takeaways:
- The CRA entered into force on 10 Dec 2024; vulnerability and incident reporting duties (Article 14) apply from 11 Sep 2026, and the full requirements from 11 Dec 2027.
- Almost any software supplied commercially on the EU market and capable of a direct or indirect connection to a device or network is in scope – including mobile apps and components sold separately.
- Software provided purely as a service (SaaS) and free and open-source software developed outside a commercial activity are excluded.
- Manufacturer duties include risk assessment, security by design, an SBOM, free security updates and vulnerability handling throughout the product’s support period.
- Penalties reach EUR 15m or 2.5% of total worldwide annual turnover, whichever is higher.
- A software house doing only contract development is not always a “manufacturer” under the CRA – but the requirements will still land in its contracts, pushed down by manufacturer clients.
- Through its vCISO service, Patronusec takes software houses through product inventory, CRA classification and the build-out of a compliant vulnerability handling process – without hiring a full-time CISO.
Table of Contents
What is the Cyber Resilience Act and which products does it cover?
The Cyber Resilience Act is an EU regulation which, from 11 Dec 2027, requires every product with digital elements placed on the Union market to meet the essential cybersecurity requirements of Annex I and to pass a conformity assessment concluded with CE marking. As a regulation, it applies directly in all Member States without national transposition.
A product with digital elements means a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. For a software company this translates into: desktop and mobile applications, licensed B2B systems, firmware, commercially supplied libraries and SDKs, and software embedded in clients’ devices.
Regulation (EU) 2024/2847 catches a product when three conditions are met together: it is a product with digital elements, it is made available on the EU market in the course of a commercial activity, and its intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.
Outside the scope remain products covered by sectoral rules (medical devices, vehicles, civil aviation, military equipment), software provided purely as a service (SaaS), and free and open-source software developed outside a commercial activity. Mind the trap: SaaS is excluded from the CRA, yet digital service providers may fall under the NIS2 Directive – the two regimes complement rather than exclude each other. If your firm runs managed or cloud services, review your NIS2 position in parallel with the CRA analysis.
Does a software house fall under the CRA?
A software house falls under the CRA as a manufacturer if it makes software available on the EU market in a commercial activity – its own products and, as a rule, bespoke software delivered to paying clients. It is not the manufacturer where it only provides development services and the product reaches the market under the client’s brand.
The manufacturer definition is decisive: a manufacturer develops or manufactures a product with digital elements, or has it designed, developed or manufactured, and markets it under its own name or trademark. Four typical market scenarios follow:
- Own product (licence, application, component) – the software house is the manufacturer with the full set of Article 13 and Article 14 obligations.
- Bespoke development delivered to a client – software built to individual specification and supplied commercially is, as a rule, also within scope; the finer boundaries are being clarified in the European Commission’s guidance (the March 2026 draft went through public consultation).
- Outsourcing / body leasing, product under the client’s brand – the client placing the product under its own name is the manufacturer. The software house has no direct CRA duties then, but the client-manufacturer must exercise due diligence over components and subcontractors – so SBOMs, secure SDLC and vulnerability handling commitments will arrive via the contract.
- Pure SaaS – outside the CRA, with potential NIS2 obligations instead.
Decision tree – is your company a CRA manufacturer:
- Do you build software or hardware with digital elements? → NO: the CRA does not concern you. YES: continue.
- Is the product made available on the EU market in the course of a commercial activity (sale, licence, monetisation)? → NO (e.g. purely non-commercial open source): out of scope. YES: continue.
- Can the product connect, directly or indirectly, to a device or network? → NO: out of scope. YES: continue.
- Do you supply only a service (SaaS) without placing a product on the market? → YES: outside the CRA; check NIS2. NO: continue.
- Does the product reach the market under your name or brand? → YES: you are the manufacturer (full obligations). NO: your client is the manufacturer, and you answer contractually as a supplier in their chain.
Patronusec Insight: From our project experience, software houses rarely first hear about the CRA from a regulator – they hear about it from contract annexes. Enterprise clients are already writing SBOM delivery, secure SDLC evidence and vulnerability patching SLAs into agreements, passing their manufacturer duties down the supply chain. Working in the vCISO model, we help teams answer those clauses before they block a signature – from a coordinated vulnerability disclosure policy to documented development practices.
Which CRA deadlines apply in 2026 and 2027?
The CRA applies in stages: from 11 Jun 2026 the provisions on conformity assessment bodies apply, from 11 Sep 2026 the duty to report actively exploited vulnerabilities and severe incidents (Article 14), and from 11 Dec 2027 all remaining requirements, including conformity assessment and CE marking.
| Date | What changes | What it means for a software house |
|---|---|---|
| 10 Dec 2024 | Regulation (EU) 2024/2847 enters into force | Transition period starts |
| 11 Jun 2026 | Chapter IV applies (Arts. 35-51) – notified bodies | Certification infrastructure for important and critical products goes live |
| 11 Sep 2026 | Article 14 applies – vulnerability and incident reporting | 24 h early warning to ENISA via the Single Reporting Platform – covers products already on the market |
| 11 Dec 2027 | Full application of the CRA | New products without conformity (incl. CE marking) cannot be placed on the EU market |
| 11 Jun 2028 | EU type-examination certificates issued under earlier rules expire | End of the transition for legacy certificates |
The most overlooked fact: the Article 14 reporting duty from 11 Sep 2026 covers all in-scope products made available on the market – including those released before the regulation applies in full. A manufacturer has 24 hours from becoming aware of an actively exploited vulnerability to submit an early warning, 72 hours for the follow-up notification, and at most 14 days (vulnerabilities) or 1 month (incidents) for the final report. Notifications go through the Single Reporting Platform operated by ENISA and are handled by the national CSIRT chosen at registration.
Could your team detect and report an actively exploited vulnerability within 24 hours today?
By 11 Sep 2026 every software manufacturer needs a working detect – assess – notify routine for ENISA reporting. Within our vCISO service we build that process end-to-end: roles, qualification criteria for events, notification templates and a dry-run of the procedure – so that your first real report is not also the first test of the process.
What obligations does the CRA impose on software manufacturers?
The CRA requires three things of a manufacturer: designing and maintaining the product securely (Article 13 and Annex I Part I), running a vulnerability handling process throughout the support period (Annex I Part II), and reporting actively exploited vulnerabilities and severe incidents (Article 14). Compliance is demonstrated through conformity assessment and CE marking.
In practice, the catalogue of duties looks like this:
- Cybersecurity risk assessment of the product – documented, kept up to date, and feeding design decisions across planning, development, delivery and maintenance.
- Security by design and by default – the product is placed on the market without known exploitable vulnerabilities and with a secure default configuration.
- SBOM (Software Bill of Materials) – a component inventory covering at least top-level dependencies, kept within the technical documentation; CycloneDX and SPDX are the formats used in practice.
- Vulnerability handling across the support period – a coordinated vulnerability disclosure (CVD) policy, an intake channel, testing, and free, prompt security updates; the support period is, as a rule, no shorter than 5 years.
- Technical documentation – retained for at least 10 years after the product is placed on the market and available to market surveillance authorities.
- Conformity assessment – for most software (the default category) the manufacturer’s self-assessment suffices; important products of Class I and II (Annex III) and critical products (Annex IV) require a notified body or certification – the technical category descriptions are set out in Implementing Regulation (EU) 2025/2392.
There is good news for teams already operating under ISO 27001 or a secure SDLC: most Annex I requirements map onto familiar practices (risk analysis, change management, security testing, vulnerability management). Regular penetration testing and vulnerability scanning are, in effect, the minimum evidence that a vulnerability handling process works in reality rather than only on paper.
How does the CRA differ for a large and a small software house?
The essential requirements are identical regardless of company size – what differs is the scale of exposure, the conformity assessment route and the available reliefs. A large software house with a product portfolio enters the full manufacturer regime for each product separately; a small, project-based house will most often meet the CRA inside its clients’ contracts.
Large software house (own products, 100+ staff):
- Every product in the portfolio needs its own classification (default / important Class I or II / critical) and its own technical documentation – the inventory alone is often a bigger project than implementing the controls.
- Annex III products (password managers, identity management systems, browsers and similar) mean assessment with a notified body – and notified body capacity in 2027 will be constrained, so booking slots early is part of the plan, not an option.
- Duties do not end at release: the support period, per-release SBOMs and 24-hour reporting demand a standing product security function, not a one-off compliance project.
Small software house (up to roughly 50 staff, mostly bespoke development):
- If you deliver software to order in the course of a commercial activity, do not assume you are out of scope by default – the supply model and whose brand the product carries decide the matter.
- Where your client is the manufacturer, the CRA will reach you as contractual clauses: an SBOM with every release, patching commitments under defined SLAs, documented development practices. Firms that have these ready win tenders against firms that are only starting.
- The regulation provides reliefs for micro and small enterprises, including simplified technical documentation and an exemption from fines for missing the 24-hour reporting deadline – but no relief from the essential requirements themselves.
Patronusec Insight: The most common trap we see in smaller teams is parking the CRA “for 2027” – while the first hard collision comes earlier: 11 Sep 2026 (reporting) and today’s contract negotiations, where large clients already demand CRA readiness. Acting as an external security officer in the vCISO model, we prepare smaller software houses for both moments within weeks, building on the team’s existing engineering practices instead of erecting compliance from scratch.
Which 3 steps should a software house take before 11 September 2026?
The three minimum steps are: (1) inventory and classify products against the CRA scope, (2) stand up a vulnerability handling and reporting process compliant with Article 14, and (3) close the gaps in the development process – SBOM, secure SDLC and technical documentation. The order matters: without step 1 you do not know what steps 2 and 3 apply to.
Step 1 – inventory and classification (2-4 weeks). List everything the firm supplies commercially: products, applications, components, firmware, software delivered to clients. For each item, determine whether it is in scope, who the manufacturer is, and the category (default / important Class I or II / critical). The outcome drives the conformity route and the budget.
Step 2 – vulnerability handling and reporting process (4-8 weeks). Publish a coordinated vulnerability disclosure (CVD) policy with an intake channel (e.g. security.txt), define what qualifies as an “actively exploited vulnerability” and a “severe incident”, assign roles, and rehearse the 24 h / 72 h / 14 day notification flow. From 11 Sep 2026 this process must work for all products on the market, not just new ones.
Step 3 – SBOM, SDLC and documentation (continuous, start now). Wire SBOM generation into the CI/CD pipeline, consolidate secure development practices (code review, security testing, dependency management) and begin maintaining technical documentation per product. This is the longest of the three steps – which is why it starts first even though its hard deadline is 11 Dec 2027.
What penalties apply for non-compliance with the CRA?
Breaching the essential cybersecurity requirements or the obligations of Articles 13 and 14 carries fines of up to EUR 15m or 2.5% of total worldwide annual turnover, whichever is higher. Breaches of other obligations carry up to EUR 10m or 2% of turnover, and supplying incorrect information to authorities up to EUR 5m or 1% (Article 64).
Fines are not the only exposure. Market surveillance authorities can order a product’s withdrawal from the market or its recall – for a software company that means a ban on selling a flagship product across the EU. Contractual risk comes on top: a client-manufacturer fined because of a supplier’s component will pursue recourse under the contract. From a software house board’s perspective, the CRA is therefore a revenue continuity risk, not merely a compliance line item.
FAQ – CRA for software houses
Does SaaS fall under the CRA?
No – software provided purely as a service is outside the CRA’s scope. The exception is remote data processing solutions integral to a product with digital elements (for instance, a mobile app’s back end without which the app cannot function). SaaS providers should instead verify whether they fall under the NIS2 Directive.
Does bespoke software developed for a client fall under the CRA?
As a rule, yes, where it is supplied in the course of a commercial activity – the CRA contains no general carve-out for made-to-order software. The allocation of duties depends on who places the product on the market under their brand: if the client does, the client is the manufacturer and the developer answers contractually within their supply chain.
Is open-source software covered by the CRA?
Free and open-source software developed and supplied outside a commercial activity is out of scope. Monetisation – paid support, enterprise editions, dual licensing – brings a product into scope. Organisations that systematically support commercially used open-source projects fall under the lighter “open-source software steward” regime.
From when must vulnerabilities be reported under the CRA?
From 11 Sep 2026. A manufacturer has 24 hours from awareness to file an early warning about an actively exploited vulnerability or severe incident, 72 hours for the follow-up notification, and up to 14 days (vulnerability) or 1 month (incident) for the final report, via ENISA’s Single Reporting Platform.
Does the CRA cover products placed on the market before 2027?
Partly. The Article 14 reporting duty from 11 Sep 2026 covers all in-scope products made available on the market, regardless of release date. The full essential requirements apply to products placed on the market from 11 Dec 2027; earlier products must comply once they undergo a substantial modification.
How long does CRA preparation with Patronusec take?
It depends on the number of products and process maturity – inventory and classification typically take 2-4 weeks, and building the Article 14 reporting process a further 4-8 weeks. After a free scope-assessment call we present a fixed work plan and pricing in the vCISO model, billed hourly instead of a full-time hire.
What to read next
- NIS2 – scope and entity obligations – if you run digital or managed services, review the regime running in parallel to the CRA.
- ISO 27001 – the management system on which Annex I requirements are most easily built.
- Penetration testing – evidence that your vulnerability handling process works in practice.
Cyber Resilience Act for software houses – free consultation
Patronusec combines an assessor’s perspective (accredited QSA, ISO 27001, DORA and NIS2 projects) with a hands-on penetration testing team – so CRA preparation is grounded in real engineering processes, not theory.
In a free 30-minute consultation we will help you:
- pre-classify your products against the CRA’s scope and categories,
- assess how ready your vulnerability handling process is for Article 14 (11 Sep 2026),
- identify the gaps between your current SDLC and Annex I requirements,
- plan the preparation in the vCISO model – without hiring a full-time CISO.
Book a free consultation | vCISO | NIS2 | Penetration testing
