The Cyber Resilience Act: What Software Vendors in the EU Market Need to Change
For two decades, "secure by default" was a marketing phrase a SaaS vendor could use without any regulator caring whether it was true. The Cyber Resilience Act ends that. From 2026 onwards, the EU treats cybersecurity as a product safety property — comparable to electrical safety or radio interference — and from December 2027 most software placed on the EU market will need a CE mark backed by genuine engineering evidence. The shift is bigger than NIS2, broader than the AI Act, and most software teams have not started preparing.
The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Vulnerability and incident reporting obligations begin to apply from 11 September 2026, and the bulk of the substantive obligations — essential cybersecurity requirements, conformity assessment, CE marking — become enforceable on 11 December 2027. By then, every "product with digital elements" placed on the EU market needs to demonstrate compliance, with fines up to €15 million or 2.5% of worldwide turnover for the worst categories of breach.
This post is a practical orientation for technical leaders: what counts as a covered product, how the regulation treats SaaS, what "security-by-default" means in concrete engineering terms, how the open-source carve-out actually works, and a CRA readiness checklist you can run against your codebase today.
Who the CRA actually covers
The CRA applies to "products with digital elements" — hardware or software products whose intended or reasonably foreseeable use includes a direct or indirect data connection. That is a deliberately wide net. Embedded firmware, IoT devices, desktop applications, mobile apps, browser extensions, libraries shipped commercially, on-prem enterprise software, smart-home appliances and connected industrial equipment all sit squarely inside. So do dependencies: if you place a commercial component on the market that other manufacturers integrate, you are a manufacturer under the CRA in your own right.
The regulation classifies products by risk into three tiers. The default tier covers the vast majority of consumer and B2B software and only requires self-assessment against the essential cybersecurity requirements. "Important" products — Class I includes things like password managers, browsers, network management tools, and identity systems; Class II includes hypervisors, firewalls, HSMs and similar high-trust components — require either harmonised standards or third-party conformity assessment. "Critical" products (smart meter gateways, smart-cards used for high-assurance authentication) need European cybersecurity certification under the Cybersecurity Act.
Where the line gets interesting for many readers is SaaS. Pure cloud services are largely governed by NIS2 and not by the CRA. But the moment your SaaS ships any kind of installable component — a desktop sync agent, a mobile app, a browser extension, a self-hosted on-premise edition, an SDK or CLI you distribute to customers — that component is a product with digital elements and falls under the CRA. The "remote data processing solutions" definition in the Act also drags in cloud back-ends that are necessary for a covered product to function as intended. Treat the boundary as fuzzy and assume more, not less, of your stack is in scope.
What "essential cybersecurity requirements" actually demand
Annex I of the CRA is short, but each requirement maps to substantial engineering work. Three blocks stand out.
Security-by-default and security-by-design. Products must be delivered with a secure default configuration, not require unsafe steps to "make it work", and minimise attack surface. In practice that means no default credentials, ports closed by default, optional features off by default, principle-of-least-privilege everywhere, and documented hardening guidance. If your installer prompts a user to "disable the firewall to continue", you have a problem.
Confidentiality, integrity, availability. The Act requires appropriate technical and organisational measures across the lifecycle: encryption at rest and in transit using state-of-the-art algorithms, integrity protection for stored data and updates, protection of authentication credentials, defence against denial-of-service, and resilience against unauthorised access. Crucially, security updates must be free and delivered automatically by default for the entire support period, which manufacturers must define and which the Act expects to align with reasonable user expectations — generally five years or the product's expected lifetime, whichever is shorter.
Vulnerability handling across the support period. This is the obligation most teams underestimate. You must maintain a coordinated vulnerability disclosure (CVD) process, provide a contact channel for researchers, address vulnerabilities "without delay" and supply free security patches, document fixes in a software bill of materials, and report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT — with an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days.
The 24-hour clock is not a typo. Engineering, product, legal and communications all need pre-approved playbooks because nobody writes those well at 03:00 with a live exploit.
The open-source carve-out, and what it does not cover
Open-source software has been the most contentious part of the CRA. The final text introduces a new actor — the "open-source software steward" — and clarifies that non-commercial development of free and open-source software is outside the regulation. A maintainer publishing a library on GitHub for the love of it does not become a manufacturer. A foundation or steward governing critical OSS faces a lighter, principle-based set of obligations rather than the full manufacturer regime.
The line is monetisation and integration. The moment a company offers OSS commercially — paid support, a hosted edition, a vendor distribution, a hardware bundle — the commercial offering is regulated like any other product. And if you, as a manufacturer, integrate OSS components into your own commercial product, you are responsible for the cybersecurity properties of those components in your shipping product. This will reshape how mid-size SaaS teams treat their dependency tree: an unmaintained transitive dependency is no longer just a risk register entry, it is a CE-marking blocker.
A CRA readiness checklist for software teams
Most teams need 12–18 months of focused work to get to genuine compliance. Start now. The first ninety days should produce concrete artefacts, not slide decks.
Scope and inventory. Catalogue every product or product component you place on the EU market, every distribution channel (direct, OEM, app stores, white-label), and where any installable, embeddable, downloadable or self-hostable artefact exists in your portfolio. Decide for each whether it is in CRA scope, in NIS2 scope, both, or neither, and document the reasoning. Borderline cases — desktop agents, sync clients, SDKs, on-prem editions — need a written legal/engineering position, not vibes.
Software bill of materials. Generate an SBOM in CycloneDX or SPDX format for every release of every covered product, automated in CI, signed and archived. Without an SBOM you cannot answer the only question that matters in a Log4Shell-style incident: "are we exposed?" A serious code quality audit usually finds dependency hygiene to be the weakest link long before architecture is.
Vulnerability handling. Publish a security.txt and a coordinated disclosure policy. Set up a monitored security@ inbox, a CVE-numbering arrangement (you are eligible to be a CNA once you have a process), and a service-level for triage and patching. Wire incident reporting into your on-call runbook with explicit owners for the 24-hour ENISA early warning.
Secure-by-default review. Run a focused review of installation defaults, default credentials, default open ports, default telemetry, and the smallest viable feature set required to start. Anything that requires a user to weaken security to use the product needs to be redesigned, not documented around.
Update infrastructure. Confirm you can ship signed, automatic security updates to every supported install across the declared support period. For long-tail self-hosted customers this often surfaces uncomfortable truths — air-gapped installs, abandoned versions, vendored forks. Decide your support window and end it explicitly for everything else.
Conformity assessment path. For default-tier products, prepare technical documentation, an EU declaration of conformity, and a CE marking process. For Class I/II products, plan for harmonised standards (the European standardisation organisations are publishing these through 2026) or notified-body assessment. Budget a year for documentation work alone.
Legacy and acquired code. This is where the engineering bill becomes real. PHP 5 era code, abandoned forks, third-party plugins your team can no longer rebuild, Windows installers nobody has touched in three years — none of that ships as CE-marked product without remediation. If your portfolio includes anything in that category, dedicated legacy code modernization work needs a slot in the 2026 roadmap.
The strategic frame
The CRA is not a checklist exercise — it is a structural change in how software liability works in Europe. From late 2027 onwards, "we patched it when we found out" stops being a defensible posture. Insurance premiums, enterprise procurement questionnaires, and public-sector tenders will all start asking for CRA documentation before they ask for feature lists.
The companies that come out of this well are the ones that treat the next eighteen months as a forced opportunity to professionalise security engineering: real SBOMs, real vulnerability handling, real update channels, real defaults. Most of that work is what a competent engineering team should already be doing — the regulation simply ends the era where skipping it was free.
If you are a technical leader at a European software company and you are still unsure how the CRA maps onto your specific product portfolio, that is a useful conversation to have early rather than late. Contact us at hello@wolf-tech.io or visit wolf-tech.io — eighteen years of European software work, including substantial legacy modernisation under regulatory pressure, sits behind every recommendation we make.