The Cyber Resilience Act for one-person businesses and open-source projects

Do you count as a manufacturer?

Article 3(13) defines a manufacturer as a natural or legal person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its name or trademark — "whether for payment, monetisation or free of charge". Three things follow from that sentence, and they decide most small-business cases.

You do not have to build it

Having it designed, developed or manufactured is enough. A brand that commissions a device and sells it under its own logo is the manufacturer — not the factory, and not the developer it hired.

You do not have to charge for it

"Monetisation" covers the models that do not look like a sale: a free app that feeds a paid service, hardware sold at cost to land a subscription, an ad-funded tool. Free of charge does not mean out of scope.

No company required

A natural person can be a manufacturer. There is no minimum size, no turnover threshold and no registration to hide behind.

A product with digital elements

Software or hardware, plus remote data processing that the product needs to work — including software and hardware components placed on the market separately (Article 3(1) and (2)). A library you publish is a product if you place it on the market yourself.

If that describes you, Articles 13 and 14 are yours, with two dates to keep apart: reporting since 11 September 2026, and the rest of the obligations from 11 December 2027. The dated state of play — the four dates, the three deadlines, the fines and what the coverage gets wrong — is in our note on the reporting clock; this page is the version that stays useful as the dates pass.

Wenn du das Produkt eines anderen patchst

Art. 22 ist die zweite Tür in die Herstellerrolle — und die, durch die ein Systemintegrator, ein Managed-Service-Provider oder ein Wiederverkäufer geht, ohne es zu wollen. Wer anders als der Hersteller, der Einführer oder der Händler ein Produkt mit digitalen Elementen wesentlich verändert und dieses Produkt dann auf dem Markt bereitstellt, gilt nach Art. 22(1) als Hersteller im Sinne der Verordnung. Art. 22(2) sagt, welche Pflichten daraus folgen: die aus Art. 13 und 14 — für den Teil des Produkts, den die wesentliche Veränderung betrifft, oder für das ganze Produkt, wenn die Veränderung seine Cybersicherheit als Ganzes betrifft. Es ist genau dieser begrenzte Satz von Pflichten, nicht jede Pflicht der Verordnung. Und Art. 22 entlässt den ursprünglichen Hersteller nicht aus den Teilen, die er nicht angefasst hat; die praktische Folge ist, wie die unten zitierte Praktiker-Analyse es formuliert, ein Produkt mit zwei Pflichtenträgern.

Der Notfall-Patch, den du auf fremdem Code auslieferst, weil Warten keine Option war, kann also der Moment sein, in dem du Hersteller wirst — wenn zwei Voraussetzungen erfüllt sind, und beide sind enger, als die Schlagzeile nahelegt. Erstens muss die Änderung eine wesentliche Veränderung sein: nach Art. 3(30) eine Änderung nach dem Inverkehrbringen, welche die Konformität des Produkts mit den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I berührt oder den Zweck ändert, für den das Produkt bewertet wurde. Erwägungsgrund 39 sagt ausdrücklich, dass ein Sicherheitsupdate, das das Cybersicherheitsrisiko senken soll und den Zweck nicht ändert, keine wesentliche Veränderung ist — das betrifft meist Fälle, in denen das Update nur kleinere Anpassungen des Quellcodes mit sich bringt — während ein Funktionsupdate, das Konnektivität hinzufügt oder Art oder Leistung des Produkts ändert, in der Regel eine ist. Zweitens muss das geänderte Produkt auf dem Markt bereitgestellt werden: Ein Patch für deinen eigenen internen Betrieb ist das in der Regel nicht, die Lieferung eines geänderten Produkts an einen Kunden in der Regel schon. Wo eine Mandanten- oder Managed-Service-Instanz nie so richtig den Besitzer wechselt, ist der Teil dieser Grenze, den keine von uns gelesene Quelle klärt.

Weil die Antwort eine vertragliche ist, empfiehlt das Comply.Land-Dossier zu nachträglichen Änderungen nach dem Inverkehrbringen eine Break-Glass-Vereinbarung, geschlossen vor einem Vorfall und nicht während eines: Sie legt im Voraus fest, welche Eingriffe als nicht wesentlich gelten, welche Nachweise im Moment der Änderung festgehalten werden und wie der Fix zurück in den unterstützten Build des ursprünglichen Herstellers findet — und, sonst eine Entscheidung innerhalb einer 24-Stunden-Frist, bei der beide Seiten annehmen können, die andere melde schon, wer von beiden die Meldung nach Art. 14 abgibt. Das Dossier selbst ist eine kommerzielle Publikation, die wir nicht gelesen haben; gelesen haben wir die kostenlose Newsletter-Ausgabe vom 25. September 2026, die es vorstellt.

Ein Datum gehört neben dieser Frage auf die Zeitleiste. Die überarbeitete Produkthaftungsrichtlinie — Richtlinie (EU) 2024/2853 — muss bis zum 9. Dezember 2026 in nationales Recht umgesetzt sein (Art. 22(1)) und gilt für Produkte, die nach diesem Datum in Verkehr gebracht oder in Betrieb genommen werden (Art. 2(1)); die Richtlinie 85/374/EWG wird am selben Tag aufgehoben (Art. 21). Dieselbe Logik — du hast es verändert, also bist du es — trägt sie haftungsrechtlich: Nach Art. 8(2) gilt jede Person, die ein Produkt außerhalb der Kontrolle des Herstellers wesentlich verändert und es danach auf dem Markt bereitstellt oder in Betrieb nimmt, als Hersteller dieses Produkts, und das Regime ist eine verschuldensunabhängige Haftung, die Software ausdrücklich als Produkt erfasst. Die Frist steht in der Richtlinie; ob dein Mitgliedstaat sie schon umgesetzt hat, haben wir nicht geprüft.

Your name on someone else's device

This is the case that catches people: a seller buys a white-label connected product — a camera, a tracker, a smart plug, a sensor board — has a logo printed on it or on the box, and offers it in its own shop. Nothing about the firmware was written by the seller, and the seller may never have spoken to the original developer. Under the CRA that seller is the manufacturer.

The reverse case is written into Article 21: an importer or a distributor becomes the manufacturer — and takes on Articles 13 and 14 — if it places a product on the market under its own name or trademark, or carries out a substantial modification of a product already on the market. Article 22 extends the same logic to anyone else who substantially modifies a product and makes it available.

What has to exist before 11 December 2027

The main body of the Regulation applies from 11 December 2027 (Article 71(2)). Products placed on the market before that date are caught only if they are substantially modified afterwards — with the reporting duty as the exception, since it already applies to everything in scope (Article 69(2) and (3)). Here is what a manufacturer has to have in place, in the order you would actually build it.

1. A documented cybersecurity risk assessment

Required by Article 13(2) and (3): an analysis of the risks based on intended purpose, reasonably foreseeable use and conditions of use, taken into account through planning, design, development, production, delivery and maintenance, and updated during the support period. It is part of the technical documentation, and the guidance treats it as the anchor of the whole system rather than as paperwork.

2. A product built to the essential requirements

Annex I, Part I: designed, developed and produced to ensure an appropriate level of cybersecurity based on risk; no known exploitable vulnerabilities at release; secure by default configuration; updates possible, automatic where applicable and enabled by default with a clear opt-out; protection against unauthorised access; confidentiality and integrity of data; data minimisation; availability of essential functions; and the ability to remove data securely.

3. A vulnerability-handling process

Annex I, Part II: identify and document vulnerabilities and components (including the SBOM below); remediate without undue delay, with security updates kept separate from feature updates where technically feasible; regular tests and reviews; public disclosure of fixed vulnerabilities; a coordinated vulnerability disclosure policy; a contact address for reports; secure distribution of updates.

4. A conformity assessment

For ordinary products you may use the internal control procedure (module A) — your own assessment, documented (Article 32(1)). For important products in classes I and II of Annex III the routes narrow, and for critical products in Annex IV a European cybersecurity certification scheme or an equivalent procedure is required. Manufacturers of FOSS in an Annex III category may keep using internal control if they make the technical documentation public when placing the product on the market (Article 32(5)).

5. The technical documentation

Drawn up before the product is placed on the market, updated at least during the support period, containing at least the elements in Annex VII (Article 31). Micro and small enterprises may use a simplified form the Commission is to specify by implementing act (Article 33(5)).

6. The EU declaration of conformity and the CE marking

The declaration states that the essential requirements are met (Article 28); the CE marking is affixed before placing on the market (Article 30(3)), and for software either on the declaration of conformity or on an easily and directly accessible section of the website accompanying the product (Article 30(1)). No CE marking, no lawful placing on the market.

7. The information that ships with it

Annex II: your name and contact details, a single point of contact for vulnerability reports and where your coordinated disclosure policy lives, the type of security support and the end date of the support period, how to install updates, how to switch off automatic updates, how to decommission the product and remove data securely.

8. A support period you have decided and can defend

See the next section. It must be documented, communicated, and it is the period during which you must actually handle vulnerabilities.

The software bill of materials

The SBOM is the inventory of what is inside your product, and the CRA asks for it once, in the vulnerability-handling requirements: identify and document vulnerabilities and components, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies" (Annex I, Part II, point 1). For a small team the practical consequence is that you need to know your dependency tree by name and version — which is also the only way you will ever answer the 24-hour question well enough to file a notification.

It is not a public document by default

It belongs to the technical documentation under Annex VII, and a market surveillance authority can require it on a reasoned request (Article 13(22)). Giving it to users is optional: Annex II, point 9 only says that if you do make it available, you have to say where.

The format is still open

Article 13(24) lets the Commission specify the format and elements by implementing act. We have not seen such an act adopted, so we name no format here — and we make no claim about any national reference document that circulates as orientation, because we have not verified it.

The support period and updates

The support period is the period during which you must ensure that vulnerabilities in the product, including in its components, are handled effectively (Article 13(8)). You determine it, and you determine it in light of how long the product is expected to be in use — user expectations, the nature and intended purpose of the product, and any Union law fixing its lifetime, with proportionality in view.

Five years is a floor and a safeguard — not a default

The support period must be at least five years, unless the product is expected to be in use for less, in which case it matches the expected use time. The Commission's guidance says the five years operates "only as a safeguard" and is "not to be considered as the default for all products"; products reasonably expected to be used for longer than five years should get longer support.

The date has to be visible

Article 13(19) requires the end date of the support period to be indicated at the time of purchase, in a clear and understandable manner, at least month and year — and, where technically feasible, a notification to users once it expires. "We support it for as long as we can" is not an answer under this provision.

How long an update stays available

A security update made available to users during the support period must remain available afterwards for a minimum of 10 years or the remainder of the support period, whichever is longer (Article 13(9)). The ten years is about availability of the update, not a promise to support the product for a decade.

Updates are free

Where security updates are available, they must be disseminated without delay and — unless otherwise agreed with a business user for a tailor-made product — free of charge, with advisory messages (Annex I, Part II, point 8).

Software gets one concession

For a software product you may, under Article 13(10), handle vulnerabilities only for the version you last placed on the market — provided users of older versions can get that version free of charge and without additional costs to adapt their environment. The Commission's guidance is explicit that routine operational effort (personnel time, testing, configuration, upgrading dependencies) does not count as an "additional cost", while new hardware or a replaced operating environment does.

The reporting clock for a team of one

This part is already live. Since 11 September 2026 a manufacturer who becomes aware of an actively exploited vulnerability in a product must notify the CSIRT designated as coordinator and ENISA — one submission through the Single Reporting Platform (Article 14(1) and (7), Article 16). Severe incidents affecting the security of the product follow the same route (Article 14(3)).

24 hours

An early warning, without undue delay and in any event within 24 hours of becoming aware: the vulnerability, and where applicable the member states where you know the product has been made available. For a severe incident the early warning is on the same clock.

72 hours

The notification: general information about the product, the nature of the exploit and the vulnerability, what you have done and what users can do, and how sensitive you consider the information.

14 days — or a month

The final report is due no later than 14 days after a corrective or mitigating measure is available for an actively exploited vulnerability. For a severe incident, within one month of the 72-hour notification. The coordinating CSIRT may also ask for an intermediate status update.

Users are a separate duty

Article 14(8): inform affected users — and where appropriate all users — of the vulnerability or incident and of the measures they can take, where appropriate in a structured, machine-readable format. If you do not do it in time, the coordinating CSIRT may inform them for you.

The clock starts when you become aware

The Commission's guidance reads "becoming aware" as a reasonable degree of certainty after an initial assessment of the event. That is why the operational question for a small team is not the deadline but the route: is there a published contact address where a researcher, a customer or a CSIRT can reach someone, and who assesses what arrives?

It can outlast the product

The reporting duty applies to in-scope products already on the market, and the Commission's guidance states that it continues after the product is no longer supported, unlike the vulnerability-handling duties. Retiring a product does not retire your inbox.

Where size does help

Article 64(10)(a): micro-enterprises and small enterprises are not subject to administrative fines for missing the 24-hour deadline. The obligation stands; the fine does not. The coordinating CSIRTs must also run helpdesk support for reporting, with particular attention to micro, small and medium-sized enterprises (Article 17(6)).

Open source: projects, stewards, contributors

Free and open-source software gets its own logic in the CRA. The starting point is the commercial-activity line: only FOSS made available on the market and supplied in the course of a commercial activity falls within the Regulation. The Commission's open-source page says FOSS that is not monetised by its manufacturer should not be considered a commercial activity, and that the CRA does not apply to developers who contribute source code to software that is not under their responsibility.

Donations

The Commission's guidance states that including a donation link does not by itself show an intention to make a profit, even where donations exceed the project's costs or cover reasonable compensation for contributors — and that FOSS supported only through donations is "unlikely" to be considered placed on the market. The exception is where donations are effectively a price for access to the software or to essential features.

Contributors

A person contributing code to a project they are not responsible for is not the manufacturer of it. The obligations sit with whoever puts the product on the market — which may be a company downstream that integrates your work.

Stewards

Article 3(14) defines an open-source software steward as a legal person that, other than as a manufacturer, systematically and on a sustained basis provides support for the development of specific FOSS products intended for commercial activities and ensures their viability. Article 24 requires such a steward to put in place and document a cybersecurity policy, including on documenting, addressing and remediating vulnerabilities, and to cooperate with market surveillance authorities on request.

Stewards and the reporting clock

Article 24(3) extends Article 14(1) to stewards to the extent they are involved in developing the product, and Article 14(3) and (8) to severe incidents affecting their own development infrastructure. Article 71(2) brings forward only Article 14 and Chapter IV, so the Commission and ENISA read the steward duty as applying from 11 December 2027 — not since 11 September 2026. Stewards are also outside administrative fines altogether (Article 64(10)(b)).

Voluntary attestation

Article 25 allows the Commission to set up voluntary security attestation programmes for FOSS, aimed at the due-diligence duty that manufacturers have when they integrate open-source components. If you maintain something that companies integrate, that is the mechanism designed for you — and it is voluntary by name.

The checklist

Not a compliance programme — a list of questions whose answers you should be able to write down. If you cannot answer one, that is where the work is.

Identity

Is your name or trademark on the product, the box, the app listing or the firmware? If yes, are you clear that you are the manufacturer — and if you are reselling someone else's device, do you have the technical documentation, risk assessment, support-period statement and update policy for the exact model you sell?

Reachability

Is there a published address for security reports, and does someone read it? Is the coordinated vulnerability disclosure policy written down, even in three paragraphs?

The clock

Do you have an SRP account, and do you know which member state's CSIRT end-point applies to you — where your main establishment is, or the fallback order if you have none in the Union?

Inventory

Can you list the components and top-level dependencies of every version you have shipped, in a machine-readable way, and tell which version a given user is running?

Risk assessment

Is there a written cybersecurity risk assessment per product, and does it say how each Annex I, Part I requirement is met or why it does not apply?

Support

Have you decided the support period, written down why, and put the end date where buyers see it? Can you keep shipping security updates for that long — free of charge — and keep them available afterwards for at least ten years or the remainder of the period?

Conformity

Which assessment route applies: internal control, or a notified body? Is your product in Annex III or Annex IV at all?

Paperwork that has to exist early

Technical documentation (simplified form if you are a micro or small enterprise), the EU declaration of conformity, the CE marking, and the Annex II information for users — all before the product is placed on the market.

Money

Have you looked at the SECURE second call? It closes on 11 December 2026, a year before the requirements bite, and it co-finances half of a project up to €30,000.

What we could not establish

The implementing acts

Two are relevant to a small manufacturer and we have not seen either: the simplified technical documentation form under Article 33(5) and the SBOM format and elements under Article 13(24). Until they exist, "machine-readable" and "simplified" are open questions rather than requirements you can fail.

Costs

We publish no cost estimate for a one-person business doing this properly. We have none we can defend, and inventing one would be worse than leaving the line empty. Tell us what it cost you and we will say so, with your date attached.

Anything the Digital Omnibus changes

The Commission presents its July 2026 guidance as part of a simplification agenda that includes the Digital Omnibus published in November 2025. We have not read those texts for CRA changes, and this page assumes the Regulation as published.

What a CSIRT actually asks for on day one

ENISA publishes user manuals and an FAQ for the platform, and we have not walked through a live notification. If you have filed one, the sequence you followed is the most useful thing you could send us.

National enforcement

The penalties are national, within the ceilings in Article 64, and how each member state's market surveillance authority will treat a one-person business is not something we can describe from the sources we read.

Der eigene Test des Dossiers

Bei der Frage der wesentlichen Veränderung halten wir uns an den Wortlaut der Verordnung — Art. 3(30) mit Erwägungsgrund 39 — und nicht an die Vier-Faktoren-Formulierung in der kostenlosen Comply.Land-Ausgabe; das ist der Arbeitstest des Autors, um einen Eingriff einzuordnen, bevor er passiert. Das Dossier, das sie vorstellt, ist kostenpflichtig und liegt uns nicht vor; über seinen weiteren Inhalt sagen wir daher nichts.

Ob die Produkthaftungsrichtlinie schon nationales Recht ist

Die Umsetzungsfrist des 9. Dezember 2026 steht in Art. 22(1) der Richtlinie (EU) 2024/2853; die Umsetzungsakte einzelner Mitgliedstaaten haben wir nicht geprüft, und wie nationale Gerichte „wesentliche Veränderung“ nach Art. 8(2) bei einem geänderten Softwareprodukt lesen werden, können wir aus den gelesenen Quellen nicht beschreiben.

Sources

1. EUR-Lex — Regulation (EU) 2024/2847 of 23 October 2024 (Cyber Resilience Act) Source for the definitions in Article 3(1), (2), (13), (14) and (30) (substantial modification); Article 13 in full, including the risk assessment (2), (3), components (6), support period (8), update availability (9), the software concession (10), the support-period end date (19), the documentation on request (22) and the SBOM format (24); Article 14 in full; Article 16; Article 17(6); Articles 19 to 22, including Article 22(1) and (2); Articles 24 and 25; Articles 28 to 33; Article 64(10); Articles 69 and 71; Annex I, Parts I and II; Annex II; Annex VII; recital 39 (when a software change is a substantial modification). Read in full for this page
2. EUR-Lex — Richtlinie (EU) 2024/2853 vom 23. Oktober 2024 über die Haftung für fehlerhafte Produkte (überarbeitete Produkthaftungsrichtlinie) Quelle für die Umsetzungsfrist 9. Dezember 2026 (Art. 22(1)), die Geltung für Produkte, die nach diesem Datum in Verkehr gebracht oder in Betrieb genommen werden (Art. 2(1)), die Aufhebung der Richtlinie 85/374/EWG zum selben Tag (Art. 21), die Behandlung einer Person, die ein Produkt außerhalb der Kontrolle des Herstellers wesentlich verändert, als dessen Hersteller (Art. 8(2)) und Software als Produkt bei verschuldensunabhängiger Haftung (Erwägungsgrund 6 und Art. 4(1)). Für diese Seite direkt gelesen
3. European Commission — C(2026) 5252, Annex: Commission guidance on the application of the Cyber Resilience Act (PDF, 27 July 2026) Source for the "five years as a safeguard, not a default" reading (paragraph 126), the treatment of "additional costs" under Article 13(10) (paragraph 130), the reporting sections (paragraphs 209 to 217, including "becoming aware" and the continuation of reporting after support ends), and the donations analysis for FOSS (paragraphs 60 to 62). Non-binding. Read in full for this page
4. European Commission — Cyber Resilience Act: open source Confirms that only FOSS made available on the market in the course of a commercial activity is in scope, that FOSS not monetised by its manufacturer should not be treated as commercial, and that contributors to software outside their responsibility are not covered.
5. European Commission — Cyber Resilience Act: reporting obligations The reporting cascade as the Commission summarises it, and the date on which stewards become subject to the reporting obligations: Article 24(3) from 11 December 2027.
6. European Commission — Cyber Resilience Act: microenterprises and SMEs The support measures aimed at small businesses, including awareness-raising, training, testing and conformity-assessment support, regulatory sandboxes and the simplified technical documentation form.
7. ENISA — The CRA Single Reporting Platform is launched (press release, 11 September 2026) The SRP's initial operating capability going live on 11 September 2026, how a single submission reaches the other CSIRTs and ENISA, the supporting materials and help desk for manufacturers and stewards, and the statement that steward reporting under Article 24(3) applies from 11 December 2027.
8. SECURE — Second Open Call (Grant Agreement No. 101190325) The call window of 1 October to 11 December 2026, €11.5 million in total, grants of up to €30,000, 50% co-financing, and micro, small and medium-sized enterprises as the target applicants.
9. Comply.Land — The CRA Fringe, Ausgabe 3: "Who Becomes the Manufacturer When You Patch" (25. September 2026), mit dem Dossier Downstream Post-Market Modifications and Break-Glass Agreements Praktiker-Analyse, kein Recht, und eine kommerzielle Publikation: Quelle für die Empfehlung der Break-Glass-Vereinbarung (vorab als nicht wesentlich eingestufte Eingriffe, im Moment der Änderung gesicherte Nachweise, der Weg zurück in den unterstützten Build des ursprünglichen Herstellers), für den Punkt, dass der ursprüngliche Hersteller für alles verantwortlich bleibt, was er nicht angefasst hat, sodass ein Produkt zwei Pflichtenträger haben kann, für die Lesart, dass ein Patch für den eigenen internen Betrieb in der Regel kein Bereitstellen auf dem Markt ist, die Lieferung eines geänderten Produkts an einen Kunden aber in der Regel schon, für die ungeklärte Lage bei Mandanten- und Managed-Service-Konstellationen und für die Frage, wer nach Art. 14 meldet. Die kostenlose Newsletter-Ausgabe wurde gelesen; das Dossier selbst ist kostenpflichtig und liegt uns nicht vor.

For the dated state of play — the four application dates, the 24-hour, 72-hour and 14-day deadlines, the fines, the Commission's guidance and the SECURE call — see our note: the Cyber Resilience Act's reporting clock.