The Cyber Resilience Act's reporting clock: 24 hours, 72 hours, 14 days — and 11 December 2027

The timeline in four dates

The instrument is Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements, published in the Official Journal on 20 November 2024 (OJ L, 2024/2847). It also amends Regulation (EU) No 168/2013, Regulation (EU) 2019/1020 and Directive (EU) 2020/1828. Nothing about the dates is a national choice: Article 71 fixes them for the whole Union, so a one-person business in Vienna, Berlin or Lisbon meets the same days.

10 December 2024 — in force: Article 71(1): the Regulation entered into force on the twentieth day following publication. The Commission's own pages say "in force since December 2024". In force is not the same as applicable — see the next three entries.
11 June 2026 — Chapter IV only: The machinery for notifying conformity assessment bodies (Articles 35 to 51) started applying on this date. For most small sellers this is background: it is about the bodies that assess products, not about your product.
11 September 2026 — Article 14, reporting: The reporting obligations began applying — Article 71(2). ENISA's Single Reporting Platform went live the same day. Article 69(3) makes this the one duty that reaches all in-scope products already on the market, including anything you placed on the market before 11 December 2027.
11 December 2027 — everything else: The default application date (Article 71(2)): essential cybersecurity requirements, conformity assessment, technical documentation, CE marking, information to the user, support periods.

One transitional rule matters for sellers with old stock and old firmware in the field. Under Article 69(2), a product placed on the market before 11 December 2027 is caught by the rest of the Regulation only if, from that date, it is subject to a substantial modification — and Article 69(3) carves Article 14 out of that relief entirely. The Commission's guidance puts the same thing in one sentence: the reporting obligations apply to in-scope products, "including products with digital elements placed on the market before 11 December 2027", and they keep applying after the product is no longer supported.

The clock: 24 hours, 72 hours, 14 days

Article 14 is short and unusually concrete. When you become aware of an actively exploited vulnerability in your product, you notify the CSIRT designated as coordinator in the relevant member state and ENISA at the same time — in practice, one submission through the SRP.

24 hours — early warning: Without undue delay and in any event within 24 hours of becoming aware (Article 14(2)(a)). It is thin: an indication of the vulnerability, plus, where applicable, the member states in which you know the product has been made available.
72 hours — the notification: General information about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken and measures users can take, and how sensitive you consider the information (Article 14(2)(b)).
14 days — the final report: No later than 14 days after a corrective or mitigating measure is available — not 14 days from the exploit (Article 14(2)(c)). It describes the vulnerability, its severity and impact, what you know about the actor exploiting it, and the update or other remedy.
Severe incidents — a different ladder: Article 14(3) to (5) covers severe incidents affecting the security of the product: 24 hours for the early warning, 72 hours for the notification, and a final report within one month of the 72-hour notification.
On request — an intermediate report: The coordinating CSIRT may ask for a status update (Article 14(6)).
Users, separately: Article 14(8) requires you to 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. A regulator may step in and inform them if you do not.

The deadline starts when you "become aware", not when the exploit happened. The Commission's guidance reads that as a reasonable degree of certainty after an initial assessment — where a third party, a researcher or a customer brings something to your attention, the assessment is what decides the moment (guidance, paragraph 213). Two consequences worth knowing. First, the guidance says you are not required to report exploitation you already knew about before 11 September 2026; there is no retroactive catch-up (paragraph 217). Second, because the reporting duty applies to products already on the market, it can outlive the support period, while the vulnerability-handling duties do not (paragraph 210).

One platform, one notification

Article 16 creates a single reporting platform, built, run and maintained by ENISA. That is the route Article 14(7) prescribes: you submit through the electronic notification end-point of the CSIRT designated as coordinator of the member state where the manufacturer has its main establishment — the place where decisions about the cybersecurity of the product are predominantly taken. A manufacturer with no establishment in the Union works down an order of fallback: authorised representative, then importer, then distributor, then the member state with the most users.

ENISA announced on 11 September 2026 that it had deployed the initial operating capability of the SRP. On its own account, the platform lets a manufacturer "report once": the coordinating CSIRT that receives the notification passes it on to the CSIRTs of the member states where the product is available, while the notification is simultaneously available to ENISA (Article 16(2)). ENISA says it will keep expanding functionality "based on operational experience and user needs" — which is a polite way of saying the first version is not the finished one.

Confidentiality: ENISA states the platform carries security measures to protect the confidentiality of what you submit. The Regulation also allows the dissemination of a notification to be delayed on justified cybersecurity grounds — for instance while a coordinated vulnerability disclosure is running (Article 16(2)).
Help, in your language?: ENISA published an FAQ, user manuals, tutorial videos, a glossary and a factsheet in several EU languages, plus a help desk. Article 17(6) also requires the coordinating CSIRTs to run helpdesk support for reporting, with particular attention to micro, small and medium-sized enterprises.
Voluntary reports, on the same rails: Article 15 lets anyone — not just the manufacturer — report a vulnerability, a cyber threat, an incident or a near miss voluntarily through the same platform. Article 17(4) states that notifying does not by itself increase the notifier's liability.

Who is bound, and the size question

"Manufacturer" is defined in Article 3(13) 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 own name or trademark — whether for payment, for monetisation or free of charge. Your name on the box or in the app store listing is what decides it.

Importers (Article 19) and distributors (Article 20) have their own duties — verification before placing a product on the market, cooperation with market surveillance, not making non-compliant products available — but the Article 14 reporting duty sits on the manufacturer. Until it doesn't: under Article 21, an importer or distributor who places a product on the market under its own name or trademark, or who carries out a substantial modification of a product already on the market, is treated as the manufacturer and becomes subject to Articles 13 and 14 itself.

The Regulation contains no general size threshold. A micro-enterprise is as much a manufacturer as a large one, and the duties in Articles 13 and 14 do not shrink with headcount. What exists for small businesses is targeted relief, and it is worth naming precisely because coverage blurs it: a simplified form for the technical documentation that micro-enterprises and small enterprises may use, which the Commission is to specify by implementing act (Article 33(5)); proportionate conformity-assessment fees (Article 32(6)); awareness-raising, training and dedicated advisory channels that member states are to provide (Article 33(1)); and the two carve-outs from fines in Article 64(10) set out below. Article 33(4) requires the Commission to advertise available Union financial support — which is how the SECURE call below is meant to reach you.

Free and open-source software is treated separately. Only FOSS that is made available on the market and supplied in the course of a commercial activity falls within the Regulation; the Commission's own open-source page says that FOSS not monetised by its manufacturer should not be considered a commercial activity, and that the CRA does not apply to developers who merely contribute source code to software that is not under their responsibility. A third role exists in Article 3(14): the open-source software steward, a legal person that, other than as a manufacturer, systematically and on a sustained basis supports the development of specific FOSS products intended for commercial activities and ensures their viability.

A correction to how this is usually reported. We have seen it written that open-source software stewards have been inside the reporting clock since 11 September 2026. That is not how we read it, and not how the Commission reads it. Article 71(2) brings forward only Article 14 and Chapter IV; the provision that extends Article 14(1) to stewards is Article 24(3), which is not in that early list. The Commission's reporting page states it in terms: stewards are subject to the reporting obligations under Article 24(3) "from 11 December 2027", and ENISA's launch page says the same. Manufacturers are in since 11 September 2026; stewards follow with the main body of the Regulation.

Fines, and the two places size counts

Penalties are set by member states, within ceilings fixed by Article 64. The top tier is the one that circulates: non-compliance with the essential cybersecurity requirements in Annex I and with the obligations in Articles 13 and 14 attracts administrative fines of up to €15,000,000 — or, if the offender is an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher (Article 64(2)).

The second tier: Up to €10,000,000 or 2% of worldwide turnover for the duties of authorised representatives, importers and distributors and other obligations in Articles 18 to 23, plus a list of further articles (Article 64(3)). Wrong information given to a notified body or a market surveillance authority: up to €5,000,000 or 1% (Article 64(4)).
Size is a factor: When a market surveillance authority sets the amount, it must take account of the nature, gravity and duration of the infringement, of previous fines — and of the size of the operator, "in particular with regard to microenterprises and small and medium sized-enterprises, including start-ups" (Article 64(5)(c)).
Micro and small enterprises are exempt from one fine only: Article 64(10)(a): no administrative fine for manufacturers that qualify as micro-enterprises or small enterprises for failing to meet the 24-hour deadline (Article 14(2)(a) or 14(4)(a)). The obligation remains; the fine does not.
Open-source software stewards are outside fines entirely: Article 64(10)(b): "any infringement of this Regulation by open-source software stewards" is excluded from the administrative fines in paragraphs 3 to 9. That is not a licence to ignore the reporting duty — it is a statement about money.

What 11 December 2027 adds

From that date the product itself has to meet the essential cybersecurity requirements of Annex I, Part I: designed, developed and produced to ensure an appropriate level of cybersecurity based on risk, secure by default, with data minimisation, protection against unauthorised access, and the ability to be fixed through security updates. The Commission's guidance is explicit that the security requirements are anchored in a documented cybersecurity risk assessment (Article 13(2) and (3)), which becomes part of the technical documentation.

Conformity assessment: For ordinary products, the internal control procedure (module A) is available: you assess and declare conformity yourself (Article 32(1)). For important products in classes I and II of Annex III, and critical products in Annex IV, the routes narrow and a notified body comes in — unless the manufacturer of FOSS in an Annex III category publishes its technical documentation, in which case internal control stays open (Article 32(5)).
CE marking: Affixed before the product is placed on the market (Article 30(3)); for software, either on the EU declaration of conformity or on the website accompanying the product, in a directly accessible section (Article 30(1)).
Technical documentation: Drawn up before the product is placed on the market and kept up to date at least for the support period (Article 31(1) and (2)), containing at least the elements in Annex VII. On a reasoned request, a market surveillance authority gets all of it (Article 13(22)).
Information to the user: Annex II lists the minimum: who the manufacturer is, a single point of contact for vulnerability reports, how to install updates securely, how to decommission the product — and the end date of the support period, which Article 13(19) also requires you to indicate at the time of purchase, at least month and year, with a notification to users when it expires where that is technically feasible.
Support period: Article 13(8): at least five years — unless the product is expected to be in use for less, in which case the support period matches the expected use time. Longer-lived products need longer support: the Commission's guidance (paragraph 126) says five years is a safeguard, not a default, and recital 60 is cited for the point that products reasonably expected to be used for longer than five years should get longer support.
Updates, and how long they stay available: Security updates must be disseminated without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge (Annex I, Part II, point 8). And a security update you issued during the support period must stay available afterwards for a minimum of 10 years or the remainder of the support period, whichever is longer (Article 13(9)). Note the difference: the ten years is about availability of an update, not about a decade of free updates.

The software bill of materials

The SBOM appears exactly once in the essential requirements: manufacturers must "identify and document vulnerabilities and components contained in products with digital elements, 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 of the products" (Annex I, Part II, point 1). Article 3(38) defines it as a formal record of details and supply-chain relationships of the components in the software elements.

Is it public?: No, not by default. It is part of the technical documentation under Annex VII, and a market surveillance authority can demand it on a reasoned request (Article 13(22)). Giving it to users is optional: Annex II, point 9 only requires that, if you decide to make it available, you tell users where to find it.
The format is not fixed yet: Article 13(24) lets the Commission specify the format and elements of the SBOM by implementing act, taking account of European or international standards and best practice. We have not seen such an act adopted.
Not covered by the July 2026 guidance: We searched the annex of C(2026) 5252 for the bill of materials and found no mention. The guidance covers scope, FOSS, substantial modification, support periods, important and critical products, risk assessment and reporting — not the SBOM.

The Commission's guidance

The Commission published practical guidance on 27 July 2026, and it is shorter to identify than the coverage suggests. It is C(2026) 5252: a Communication, plus an annexed guidance document. Both are downloadable from the Commission's own publication page, which also dates it. The guidance is non-binding and is issued on the basis of Article 26, which requires the Commission to publish guidance with a particular focus on helping micro-enterprises and SMEs.

What it covers: Scope, including remote data processing and FOSS; what counts as a substantial modification; how support periods work; important and critical products and their conformity assessment; cybersecurity risk assessment and integration of components; and the reporting obligations in Section 9.1 (paragraphs 209 to 217 are the operative part for Article 14).
What is in it for a small business: The Commission says particular attention was paid to micro-enterprises and SMEs, with 67 practical examples, use cases, flowcharts and graphs. It describes the guidance as non-binding clarity, and says further guidance will be considered as needed.
How it was made: Through the expert group on cybersecurity of products with digital elements and a public consultation earlier in 2026, and the Commission frames it as part of its simplification agenda alongside the Digital Omnibus published in November 2025.

The point of this section is that the reports we started from said the Commission had issued detailed guidance "without a document number or date". Both exist, both are on the Commission's site, and both took one search to find: C(2026) 5252, 27 July 2026. The Commission also maintains a Frequently Asked Questions page on CRA implementation, Section 5 of which ENISA points to for reporting questions.

The money: SECURE, closing 11 December 2026

SECURE ("Strengthening EU SMEs Cyber Resilience", Grant Agreement No. 101190325) is a three-year project started in January 2025 under the Digital Europe Programme (topic STRENGTHENCRA), and it distributes cascade funding to micro, small and medium-sized enterprises that want to prepare for the CRA. Its second open call is the one that matters now.

Open from 1 October 2026 to 11 December 2026: Applications go through the SECURE platform; the call page lists the guidelines and templates, including an annex on CRA scope and the eligible activities, services and goods.
€11.5 million in total: Co-financing of 50%, with grants of up to €30,000 per project.
Who can apply: Micro, small and medium-sized enterprises. The call is not a CRA subscription service: it co-finances concrete projects that improve your compliance and cybersecurity practice.
What previous projects did: Salzburg Research, a consortium partner, reports roughly 260 applications from 28 countries for the first call (€5 million pot) and says a large share of those projects were preparatory: gap and maturity analyses, analysis of regulatory requirements, governance and risk management.

Mind the two Decembers. The call closes on 11 December 2026. The requirements it helps you prepare for apply from 11 December 2027. If the money is the reason you would start at all, the reason expires a year earlier than the rules do.

What this means if you are small

A one-person software developer. If you sell the app, or monetise it, and it carries your name, you are the manufacturer. The reporting clock already applies to you, to every product you have placed on the EU market — including versions you have stopped supporting. Practically, that means one thing before anything else: a route by which a security report reaches you and is assessed, because the 24 hours start when you become aware, not when you open your inbox.

A small hardware brand. An OEM board with your logo on the case is a product you placed on the market under your own trademark, and the vulnerabilities that matter include the ones inside components you did not write. Article 13(6) requires you to report a vulnerability you find in a component to whoever manufactures or maintains it, and then to handle it in your own product too. You cannot outsource that by pointing at a supplier, which also means a supplier's silence is your exposure.

An open-source project. Donations are not automatically a commercial activity: the Commission's guidance says FOSS supported only through donations is unlikely to be considered placed on the market, even where donations exceed the costs of the project (paragraph 61). Individual contributors to software outside their responsibility are out of scope. If you are a legal person that sells support for a project others build on, you may be a steward — with a documented cybersecurity policy, cooperation with market surveillance on request, and reporting duties from 11 December 2027, without fines.

The whole picture for a small player — who counts as a manufacturer, what has to exist before 11 December 2027, how the reporting duty works in a team of one, how projects and stewards are treated, and a plain checklist — is in our explainer: the Cyber Resilience Act for one-person businesses and open-source projects.

What we could not establish

The same outlet, twice: The two CRA pieces we started from were published by the same outlet on the same day and appear to summarise the same rollout and the same guidance. We did not treat them as two confirmations of anything, and we did not open them: every statement above comes from the Regulation, the Commission, ENISA or the SECURE partnership. Where the coverage was wrong, we have said so and shown the source we read instead.
Any CRA provisions in the Digital Omnibus: The Commission describes the July 2026 guidance as part of its wider simplification agenda, "including through the Digital Omnibus published in November 2025" — a phrase it uses twice on the publication page. We have not read the Omnibus texts for anything they would change in the CRA, and this note assumes the Regulation as published. If a simplification package moves a CRA date, this page will be wrong until we correct it.
The implementing act on the SBOM format: Article 13(24) allows the Commission to specify the format and elements of the software bill of materials. We found no such act. We also did not verify the national reference documents that circulate as orientation for SBOM formats, so we assert nothing about them — and nothing about whether following one creates any presumption of conformity.
The delegated act on withholding notifications: Article 14(9) required the Commission to adopt a delegated act on the terms and conditions for the cybersecurity grounds in Article 16(2) — the grounds on which dissemination of your notification can be delayed — by 11 December 2025. We did not check whether it has been adopted.
What compliance costs: We have no usable cost estimate for a one-person business doing this properly. The SECURE grant ceiling of €30,000 for half of a project is a data point, not an answer, and it is a subsidy rather than a price. If you have priced the work for your own product, that is the contribution we would most like to have.
Whether 24 hours is realistic for a team of one: That is a judgement, not a fact, so we state none. The Regulation gives no allowance, the exemption in Article 64(10)(a) concerns the fine and not the deadline, and the only structural help we found is the CSIRT helpdesk in Article 17(6).

Sources

EUR-Lex — Regulation (EU) 2024/2847 of 23 October 2024 (Cyber Resilience Act) Source for the definition of manufacturer in Article 3(13) and of steward in Article 3(14); Article 13(2), (3), (6), (8), (9), (19), (22) and (24); Article 14 in full, including the 24-hour, 72-hour and 14-day deadlines, severe incidents, the intermediate report, the choice of CSIRT end-point and the duty to inform users; Articles 15 to 17; Articles 19 to 21 and 24(3); Article 26; Articles 29 to 33; Article 64; Articles 69 and 71; Annex I, Part II, points 1 and 8; Annex II, points 7 and 9; Annex VII. Read in full for this page
European Commission — C(2026) 5252, Annex: Commission guidance on the application of the Cyber Resilience Act (PDF, 27 July 2026) Source for the support period reading in paragraph 126 (five years as a safeguard rather than a default), the transitional commentary in paragraph 210, and the reporting sections in paragraphs 209 to 217, including "becoming aware" (213), the reporting ladder (215), stewards (216) and the absence of retroactive reporting (217). We also searched this document for the software bill of materials and found no reference to it. Read in full for this page
European Commission — Commission publishes new guidance to support timely Cyber Resilience Act implementation (27 July 2026) The publication page: the document reference C(2026) 5252 for both the Communication and the annex, the date, the non-binding character, the 67 practical examples, the Article 26 basis, the expert group and 2026 public consultation, and the Digital Omnibus context.
European Commission — Cyber Resilience Act: reporting obligations The Commission's own summary of the cascade, and the source for the date on which open-source software stewards become subject to the reporting obligations: Article 24(3) from 11 December 2027. Also the entry point for the Commission's FAQ on CRA implementation.
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 a commercial activity, and that contributors to software outside their responsibility are not covered.
ENISA — The CRA Single Reporting Platform is launched (press release, 11 September 2026) The initial operating capability of the SRP going live on 11 September 2026, the "report once" description of how the coordinating CSIRT disseminates and ENISA receives simultaneously, the confidentiality measures, the supporting materials and help desk, the statement that manufacturers' reporting applies from 11 September 2026 while the main requirements apply from 11 December 2027, and ENISA's own reading that steward reporting under Article 24(3) applies from 11 December 2027.
SECURE — Second Open Call (Grant Agreement No. 101190325) The call window of 1 October to 11 December 2026, the €11.5 million budget, grants of up to €30,000, the 50% co-financing rate, micro, small and medium-sized enterprises as the target applicants, and the project's funding under the Digital Europe Programme, topic STRENGTHENCRA.
Salzburg Research — €11.5 million in funding to boost cyber security in European SMEs (5 October 2026) A consortium partner's account of the second call as a short explanation of what previous SECURE projects contained: around 260 applications from 28 countries for the first call and a large share of preparatory measures. Used only for that, and not for the eligible activities of the second call.

Help us keep this right

This note is dated and it will decay: the SBOM implementing act, the delegated act on withholding notifications and any change carried by the Digital Omnibus all move the picture. If you have filed a notification through the SRP, been asked for a software bill of materials, or priced this work for a product of your own, we would rather have your experience than another summary: hello@kontorbund.com, or the Discord.

Everything on this page is shared experience with a date attached, and none of it is legal advice.