What the Cyber Resilience Act asks of a small software company

If you sell software into the European Union — a product, an app, a connected device, a paid plugin — there is a regulation with your name on it, and its first real deadline lands on 11 September 2026. The European Union's Cyber Resilience Act (CRA) is the first law to put horizontal cybersecurity requirements on nearly every "product with digital elements" sold in the EU market. It applies based on where your product is sold, not where your company sits. A five-person software company in Austin selling a paid app to German customers is in scope.

Most of what has been written about the CRA is aimed at device manufacturers with regulatory departments. This piece is the small-software-company version: what the law actually asks, which dates matter, and what a small team should do about it this quarter — calmly, without a compliance department.

Am I in scope?

Broadly: if you place a product with digital elements on the EU market in the course of a commercial activity, the CRA applies to you as its manufacturer. "Product with digital elements" is deliberately wide — software products, mobile and desktop apps, connected hardware, and components sold for money. A few boundaries matter for small companies:

Pure services are mostly out. Software-as-a-Service (SaaS) offered purely as a remote service is generally outside the CRA (it falls under other EU rules). The exception: a remote data-processing part of a product that cannot work without it. If you ship an app whose cloud backend is integral to the product, the backend rides along.

Open source has a carve-out, commerce does not. Free and open-source software developed and supplied outside a commercial activity is out of scope. Monetise it — paid version, paid support as the business — and you are a manufacturer like anyone else.

Size is not an exemption. There is no small-company carve-out. The law contains some lighter-touch support for small and medium-sized enterprises, but the obligations themselves apply regardless of headcount.

If you are genuinely unsure, that question — "is what we sell into the EU a product with digital elements?" — is the first thing to resolve, in writing, because everything below hangs on it.

The two dates

The CRA entered into force in December 2024, with its obligations arriving in two waves:

11 September 2026 — the reporting duty starts. From this date, manufacturers must report two kinds of event: any actively exploited vulnerability in their product, and any severe incident affecting the product's security. And this duty applies to products already on the EU market, not just new releases. This is the deadline that matters this year.

11 December 2027 — the main obligations apply. From this date, products placed on the EU market must meet the full set: essential cybersecurity requirements designed in, a documented risk assessment, a vulnerability-handling process, and a coordinated disclosure policy. The set also includes technical documentation — including an inventory of the software components you build on (a Software Bill of Materials, or SBOM). It also includes security updates provided through a defined support period (in most cases at least five years), and Conformité Européenne (CE) marking backed by a conformity assessment. For most ordinary products that assessment is self-assessment; products in the "important" or "critical" classes face third-party involvement.

Penalties for non-compliance scale up to €15 million or 2.5% of worldwide turnover for breaches of the essential requirements. The dates, duties, and figures in this piece follow the regulation's text and the European Commission's published guidance on Cyber Resilience Act reporting obligations. The Commission's digital-strategy pages are the authoritative place to confirm them as implementation firms up. Enforcement, as with most EU product law, is expected to build gradually — but printed on a contract renewal, "are you CRA-compliant?" will arrive well before any regulator does.

What the reporting duty actually requires

The September 2026 duty is a clock, and it is short. When you become aware that a vulnerability in your product is being actively exploited, or that a severe incident has hit your product's security:

Within 24 hours: an early warning to your national Computer Security Incident Response Team (CSIRT) and the European Union Agency for Cybersecurity (ENISA). It's filed through the EU's single reporting platform. The early warning is short — essentially "this is happening."

Within 72 hours: a fuller notification — the nature of the vulnerability or incident, what you know, and any corrective measures available or under way.

Then a final report: for an exploited vulnerability, no later than 14 days after a fix is available, describing the vulnerability and the remedy. For a severe incident, the final report is due within a month of the 72-hour notification.

In some cases you must also inform the affected users of your product, in plain language, about the issue and the fix. If this cadence sounds familiar, it is the same shape as the General Data Protection Regulation (GDPR) breach clock — which we have written about. It's pointed at product security rather than personal data, with a 24-hour first beat. The two clocks can run simultaneously: one incident can be both a personal-data breach and an actively exploited product vulnerability.

What a small company should do this quarter

Nothing below requires a consultant. It requires a decision, a document, and a drill.

1. Settle the scope question. One page: what we sell into the EU, whether it is a product with digital elements, and which parts (backend included or not). Date it and revisit when the product changes.

2. Make sure vulnerability reports can reach you. You cannot report what never arrives. A monitored security@ address and a simple disclosure page — what to send, what reporters can expect — is the minimum. This is also simply good practice, CRA or not; our piece on receiving your first vulnerability report walks the process that starts when the first email lands.

3. Define your internal 24-hour path. The hard part of a 24-hour clock is not the form — it is the internal journey from "an engineer learned this" to "the company filed." Decide now: who is told, who decides it is reportable, who files, and who covers when that person is on leave. Write it as a one-page runbook and put the reporting-platform address on it.

4. Start the component inventory. An SBOM sounds enterprise; in practice modern build tools can generate a dependency inventory cheaply. Turning that on now means the 2027 documentation requirement becomes an export, not an archaeology project.

5. Put a support-period sentence in your product docs. Decide how long you provide security updates for what you sell, and say it. You will need it for 2027; buyers are already asking for it today.

The quiet upside

It is worth saying plainly: for a small vendor that already takes product security seriously, the CRA mostly demands proof of things worth doing anyway. That means a way to hear about flaws, a process to fix them, updates for a sensible period, and honesty when something is exploited. The vendors for whom this is painful are the ones for whom it was always going to be painful. Getting the reporting muscle in place a year early is cheap; building it during your first actively exploited vulnerability is the expensive way.

When you want this ready to use

Two Sylvan Assurance toolkits meet the CRA from opposite ends. The PSIRT Response toolkit builds the standing function: the disclosure policy, intake, triage, and advisory templates a Product Security Incident Response Team (PSIRT) runs on. The First 4 Hours toolkit's PSIRT CRA-Ready edition is built for the live moment: the first-hours playbooks with the CRA reporting clocks, escalation trees, and notification templates wired in. Editions from $49. The companion Sylvan Press field guide, PSIRT, covers the function in three volumes.

The free PSIRT readiness check at sylvanassurance.com/free/psirt scores your governance, technical, and communication readiness in about five minutes. It runs entirely in your browser. Your answers are never transmitted.

Prefer the long form? The companion Sylvan Press title, PSIRT, covers the same ground in depth.