Cyber Resilience Act Article 14 Applies From 11 September

Cyber Resilience Act Article 14 applies from 11 September 2026. The rest of the Regulation doesn't apply until 11 December 2027 ^[A1]. If you commissioned software and shipped it under your own name, you're the manufacturer ^[A14]. The first clock is 24 hours ^[A5].

Read that in a US time zone and the question is whether it's yours. The CRA hooks on the market, not your address: it applies to products made available on the Union market, with no establishment requirement ^[US-I1]. If you have EU users, this is yours. If you genuinely have none, it isn't. The text follows through on it: the Regulation builds importer and authorised-representative roles specifically for manufacturers established outside the Union ^{[US-I2] [US-I3]}, and it reaches products already on that market before 11 December 2027 ^[US-I9].

Cyber Resilience Act Article 14 is the provision of Regulation (EU) 2024/2847 that requires the manufacturer of a product with digital elements to notify actively exploited vulnerabilities and severe incidents to the CSIRT designated as coordinator and to ENISA, and it applies from 11 September 2026 ^{[A1] [A4] [A8]}.

Key takeaways

• Article 14 applies from 11 September 2026; the Regulation as a whole applies from 11 December 2027, and Chapter IV (Articles 35 to 51) has applied since 11 June 2026 ^[A1].
• The first Article 14 deadline is an early warning within 24 hours of becoming aware, not 72 hours ^{[A5] [A9]}.
• You are the manufacturer if a product is designed or developed for you and marketed under your name or trademark, even if someone else wrote the code ^[A14].
• Article 14 reaches products placed on the market before 11 December 2027, so reporting is not grandfathered ^[A17].
• The CRA applies to products made available on the Union market with no establishment requirement, so a company outside the EU is covered where its product reaches that market ^[US-I1].

Cyber Resilience Act Article 14: what starts on 11 September, and what doesn't

The most common sentence written about this regulation is wrong, in a way that will cost somebody a bad week.

Article 71(2) of Regulation (EU) 2024/2847 reads in full: "This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026." ^[A1] Three dates, one sentence. The CRA compliance deadline for the Regulation as a whole is fifteen months away. Article 14 isn't, and Chapter IV (notification of conformity assessment bodies) has applied since June ^[A2].

So "the CRA applies from 11 September 2026" is folklore ^[F1]. Only Article 14 does. The Commission's own policy page says the main obligations apply from 11 December 2027, "with reporting obligations to apply as of 11 September 2026" ^[A58]. The Regulation entered into force on 10 December 2024 ^[A3]; what changes on Friday is which parts of it bite.

The second wrong sentence is that products already shipped are grandfathered until 2027. Article 69(2) is the general grandfathering rule: products placed on the market before 11 December 2027 are caught only if they undergo a substantial modification from that date ^[A18]. Article 69(3) derogates from it explicitly: the Article 14 obligations "shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027" ^[A17]. Reporting is not grandfathered ^[F6]. The estate you already shipped is in.

What follows is a description of published texts, not legal advice.

You are probably the manufacturer, even if you didn't write the code

Most engineering leaders read "manufacturer" and picture whoever wrote the code. The CRA doesn't define it that way.

Article 3(13) defines a manufacturer as "a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge" ^[A14]. The italicised clause is the whole argument. If you paid an agency, a nearshore team or a contractor to build something and it ships with your logo on it, you're the manufacturer for CRA purposes. The people who wrote the code aren't. Non-binding Commission guidance restates it plainly: the manufacturer is "the natural or legal person that supplies a product with digital elements under its name or trademark, and that does so in the course of a commercial activity" ^[A64].

That kills a comfortable assumption: only the vendor who wrote the code has to report ^[F8]. Two further articles close the remaining exits. Article 21 turns an importer or distributor into a manufacturer where it places a product on the market "under its name or trademark" or substantially modifies one already on the market ^[A15]. White-labelling someone else's product doesn't move the duty to them. It moves it to you. Article 22 does the same for substantial modification by anyone else, who becomes subject to Articles 13 and 14 for the modified part, or for the whole product where the modification affects its cybersecurity overall ^[A16].

The trigger is wide too: "making available on the market" is supply on the Union market "in the course of a commercial activity, whether in return for payment or free of charge" ^{[A25] [US-I4]}. Your free tier is not a hiding place.

The two things you have to report: actively exploited vulnerability and severe incident

Article 14 contains two duties, not one, and most write-ups collapse them into a single blurry obligation. Separate paragraphs, separate definitions, different final deadlines.

The first is the actively exploited vulnerability. Article 14(1) requires a manufacturer to notify "any actively exploited vulnerability contained in the product with digital elements that it becomes aware of" simultaneously to the CSIRT designated as coordinator and to ENISA ^[A4]. The definition is narrow and it matters: Article 3(42) defines it as "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" ^[A11]. A plain "vulnerability" is only "a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat" ^[A12], and that alone triggers nothing here.

Worth saying loudly, because the panic version of this post has your entire known-vulnerability backlog going reportable on day one. It isn't ^[F10]. Evidence of actual exploitation is the gate.

The second duty is the severe incident: Article 14(3) requires notification of "any severe incident having an impact on the security of the product with digital elements" to the same two recipients ^[A8]. Article 14(5) says when an incident is severe: where it "negatively affects or is capable of negatively affecting" the product's ability to protect "the availability, authenticity, integrity or confidentiality of sensitive or important data or functions", or has "led or is capable of leading to the introduction or execution of malicious code" in the product or a user's systems ^[A13].

Note "or is capable of". The incident trigger doesn't wait for demonstrated harm.

The CRA reporting clock is 24 hours, not 72

You carry a 72-hour number in your head, imported from GDPR and NIS2. The CRA reporting requirements in Article 14 set four deadlines. The first is 24 hours, not 72 ^[A5].

That last row is the one everyone loses: the two triggers don't share a final-report clock ^[A10]. "The CRA reporting deadline is 72 hours" is incomplete and misleading in both directions ^[F4].

The 24-hour early warning is thin by design — for a vulnerability, the Member States where you know the product has been made available ^[A5]; for an incident, at least whether it's suspected of being caused by unlawful or malicious acts ^[A9]. The 72-hour notification carries the substance: the product, the general nature of the exploit and the vulnerability, measures taken, measures users can take, and how sensitive you consider the information ^[A6].

Where does it go? To the notification end-point of the CSIRT designated as coordinator in the Member State of your main establishment, where decisions about your products' cybersecurity are predominantly taken, and simultaneously to ENISA ^[A45]. No main establishment in the Union? Article 14(7) gives a fallback ladder: your authorised representative's Member State, then the importer's, then the distributor's, then where most of your users are ^[A46]. An incident is the wrong time to work out which rung you're on.

Mechanically it's one submission. ENISA operates the platform under Article 16(1) ^[A42], and manufacturers report "only once" through it, with the receiving CSIRT passing the notification on to CSIRTs in the other territories where the product is available ^[A59]. As of the Commission's 31 July 2026 update it "will be operational by 11 September 2026", with testing under way ^[A43]; ENISA says it will be used for mandatory reporting from that date ^[A44].

The clause that should worry a B2B software business most isn't the regulator-facing one. Article 14(8) requires the manufacturer, on becoming aware of an actively exploited vulnerability or severe incident, to inform impacted users (and where appropriate all users) about it and, where necessary, about mitigation and corrective measures; where it doesn't do that in a timely manner, the notified CSIRTs may inform users directly ^[A47]. A customer-facing disclosure, with a regulator holding a backup switch.

On penalties, quote the article or don't quote the number. Article 64(2) sets the top tier and names Article 14 in it: fines up to EUR 15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher ^[A37]. A CRA fine figure without its article is folklore ^[F7]. One humane detail sits in a later paragraph: Article 64(10)(a) exempts microenterprises and small enterprises from the administrative fines in Article 64(3) to (9) for missing the 24-hour early warning specifically — not the 72-hour notification, not the final report ^[A40].

In scope even though people say it isn't: bespoke, SaaS, open source

Three exemptions get repeated confidently in engineering channels. All three are narrower than advertised, or don't exist at all.

Bespoke is not exempt. No bespoke, custom-made, tailor-made or single-customer exclusion exists anywhere in the Regulation. Article 2 does carry product-type exclusions, among them Article 2(7) for national security, defence and classified-information products ^[A27] — but none of them turns on a product having been built for a single customer. Recital 64 treats tailor-made products as regulated and grants one narrow deviation, available only where manufacturer and business user "have explicitly agreed to a different set of contractual terms" ^[A28]. That deviation is confined to two Annex I points: secure-by-default configuration and free-of-charge security updates. Article 14 is not among the requirements a contract can vary ^{[A29] [F2]}.

SaaS is not simply out. Recital 12 says cloud services designed and developed outside a manufacturer's responsibility are outside scope ^[A22], and puts standalone cloud service models ("Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS)") under NIS2 instead ^[A23]. But a "product with digital elements" expressly includes "its remote data processing solutions" ^[A20], and remote data processing means processing at a distance developed by or under the manufacturer's responsibility, "the absence of which would prevent the product with digital elements from performing one of its functions" ^[A21]. Non-binding Commission guidance draws the line: your own application deployed on third-party IaaS or PaaS may qualify as a remote data processing solution, while a third-party SaaS application you merely integrate does not, and is treated as a third-party component ^{[A24] [F5]}.

Open source is exempt only under a narrow condition. Recital 18 sets it: only free and open-source software supplied in the course of a commercial activity is in scope, and FOSS "not monetised by their manufacturers" isn't a commercial activity ^[A31]. A FOSS component supplied for integration by other manufacturers is "made available on the market" only if its original manufacturer monetises it ^[A32]. Two things narrow that further. Non-binding guidance says software under a free and open-source licence whose source is shared only with paying customers or a limited group is not FOSS within the meaning of Article 3(48) ^[A34]. And Article 24(3) applies Article 14(1) duties to open-source software stewards to the extent they're involved in developing the product ^[A35]. Stewards are shielded from administrative fines by Article 64(10)(b) ^{[A41] [A60]} — not the same as being out of scope ^[F3].

The commercial-activity test is broader than "we charge for it" too: Recital 15 says it can be characterised by charging for support beyond cost recovery, an intention to monetise, or donations exceeding development costs ^[A26]. And Article 2(1)'s gate catches nearly everything a modern team ships — products whose intended or reasonably foreseeable use "includes a direct or indirect logical or physical data connection to a device or network" ^[A54].

Does the CRA apply to US companies?

Yes, wherever the product is made available on the Union market. That was settled at the top of this post, and it doesn't turn on where you're incorporated. The harder question is what you already have at home that does the same job. On 11 September a US software company selling into the EU picks up a binding product-vulnerability reporting duty, and nothing in US federal law already has you doing that work. Four federal instruments come close enough to be worth checking. Here is where each one stops.

Start with the one you know. The SEC adopted its cybersecurity disclosure rules in 2023, adding Item 1.05 to Form 8-K, effective 5 September 2023 ^[US-A1]. The clock is four business days. It starts on the materiality determination, not on discovery: the amended instruction reads "A report pursuant to Item 1.05 is to be filed within four business days after the registrant determines that it has experienced a material cybersecurity incident" ^[US-A2]. That's the most commonly mangled fact in this area ^[US-X3]. It binds registrants, meaning companies reporting under the Securities Exchange Act of 1934, and does not reach private companies ^[US-A5]; it has been live since December 2023 for larger registrants and June 2024 for smaller reporting companies ^{[US-A6] [US-A7]}.

It's also a different object. Item 106 defines a cybersecurity incident as "an unauthorized occurrence, or a series of related unauthorized occurrences, on or conducted through a registrant's information systems" — the registrant's own systems, not vulnerabilities in the products it sells, owed to investors rather than a security regulator ^[US-A10]. A public company can owe both on one incident, and neither substitutes for the other.

Now the one most US readers get wrong. CIRCIA looks like the American answer: 72 hours for a covered cyber incident, 24 hours for a ransom payment ^{[US-B1] [US-B2]}. Those duties are not in force. The statute suspends itself — 6 U.S.C. 681b(a)(7), headed "Effective date", reads in full: "Paragraphs (1) through (4) shall take effect on the dates prescribed in the final rule issued pursuant to subsection (b)" ^[US-B5]. No final rule exists; every Federal Register document affecting the CFR part the rule would create is a proposed rule ^[US-C2]. CISA says so plainly: reporting "will not be required until the CIRCIA final rule goes into effect" ^[US-C5]. It gives no compliance date, and blames funding lapses ^[US-C6]. The statutory final-rule deadline expired around 4 October 2025 and was missed ^[US-B6], and as late as May 2026 CISA was still gathering input on the 2024 proposal ^[US-C3]. There is no live 72-hour federal clock ^[US-X2]. Even when the rule lands, CIRCIA binds covered entities in critical-infrastructure sectors, not software vendors generally ^[US-B4].

The closest analogue in kind is a medical-device statute. FD&C Act section 524B, effective 29 March 2023, requires a coordinated vulnerability disclosure and postmarket monitoring plan ^[US-D2], regular-cycle patching plus out-of-cycle fixes for critical vulnerabilities ^[US-D3], and a software bill of materials covering commercial, open-source and off-the-shelf components ^[US-D4]. Genuinely a product-security duty. But it attaches to a premarket submission, so it reaches only sponsors of FDA applications for internet-connected medical devices ^[US-D7], and unlike Article 14 it carries no incident-reporting clock ^[US-D8].

The procurement lever got switched off this year. OMB Memorandum M-26-05, dated 23 January 2026, says M-22-18 "imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments" and that "OMB Memoranda M-22-18 and M-23-16, a companion policy, are hereby rescinded" ^[US-E4]. The CISA Secure Software Development Attestation Form still exists, but agencies "may choose to use" it rather than being required to collect it ^{[US-E5] [US-E7]}. It was always a procurement condition, never a general law binding software vendors ^{[US-E9] [US-X6]}, and NIST SP 800-218 underneath it carries no independent force of law ^[US-F2].

The search lands somewhere blunt. No US federal statute or regulation imposes product-security or vulnerability-reporting duties on commercial software vendors selling to private-sector customers generally ^[US-G1]. Every federal instrument found hooks on securities-listing status, critical-infrastructure status, or sector regulation and procurement — none on "sells software" ^[US-G2]. That finding comes from checking each instrument's scope limit rather than reading the whole US Code, so take it as bounded rather than absolute ^[US-G4]. State law supplies one exception: California Civil Code 1798.91.04(a) requires a manufacturer of a connected device to equip it with reasonable security features ^[US-H1] — a design requirement with no reporting clock, covering physical devices rather than software sold on its own ^{[US-H3] [US-H5]}.

And one category error to retire. State breach-notification laws are not the US equivalent of Article 14: they trigger on unauthorised acquisition of residents' personal information and require notice to affected individuals, while Article 14 triggers on an exploited vulnerability or severe incident in a product and demands notice to a CSIRT and ENISA ^{[US-H4] [US-X4]}.

So the EU switched on a horizontal product-security reporting duty in the same year the US switched off its own software-assurance mandate. The weight lands back where it started: on how you evaluate the vendors building software under your name.

Inherited third-party components are your problem to report

Almost nobody ships only their own code. The Commission's non-binding guidance of 27 July 2026, C(2026) 5252 ^[A57], answers the question that follows.

Where a product contains an actively exploited vulnerability originating from a third-party component, the guidance says the product's manufacturer is required to notify it ^[A51]. Your dependency's bug, reported by you, on your clock. There's a real limit: where you know a third-party component holds a vulnerability that cannot be exploited in your own product, the guidance says it isn't an actively exploited vulnerability contained in your product and isn't subject to mandatory reporting, though you may notify it voluntarily under Article 15 ^[A52].

Read that limit carefully, because it's a discovery problem wearing a legal costume. "Cannot be exploited in my product" is a claim about your dependency graph and your reachable code paths. If you can't say what you ship and whether the vulnerable path is live, you can't make the call that keeps you outside the duty — you're guessing, under a 24-hour clock. Knowing what is actually in your build is a code audit checklist question long before it is a legal one.

Two more from the same guidance. The sleeper: unlike vulnerability handling obligations, which run only for a product's support period, "the reporting obligations continue to apply after a product with digital elements is no longer supported" ^[A19]. The integration you stopped maintaining in 2023 still generates a reporting obligation if somebody starts exploiting it.

And the caveat that makes the rest credible. There's no day-one amnesty sweep: a manufacturer "is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026" ^[A49]. You don't have to go back through your history. The converse holds: if you knew of a vulnerability before 11 September but not of exploitation, and exploitation then occurs or comes to your attention, it's an actively exploited vulnerability subject to the duty ^[A50].

So everything turns on "becoming aware". Guidance aligns that concept with the Guidelines 9/2022 on personal data breach notification under the GDPR, and says a manufacturer should assess a suspicious event immediately ^[A53]. If your GDPR breach process works, the muscle exists — it just has to point at your product instead of your data. While you're in there, check what your vendor security questionnaire asks suppliers about disclosure.

What to do before Friday, 11 September

Nothing in Article 14 asks you to be compliant on 11 September. It asks you to be capable of a 24-hour response.

That decomposes into four engineering questions, none of them legal. What do we actually ship, transitive dependencies included, in every product carrying our name in the EU? Who owns the 24-hour clock at 2am on a Saturday, and how do they get paged? Which Member State's CSIRT receives the notification, resolved in advance from the main-establishment test or the Article 14(7) ladder ^{[A45] [A46]}? And what does the Article 14(8) message to users look like, drafted before you need it ^[A47]?

The first question gates the other three, and it's the one most teams can't answer. A Code Audit is three days, two senior engineers, one production-worthy plan: architecture, security, data review, risks ranked by blast radius, a fixed-price quote to ship it prod-worthy. Optional: we ship the remediation. If remediation becomes ongoing work, Dev On Demand runs a single stream at $3,495/mo or dual at $6,795/mo, on a 3-day task cycle with daily async updates, a task-by-task approval gate and a 5-day first ship. Cancel any time, no notice period required. Knowing which third-party components you shipped is a prerequisite to reporting on them, and finding that out is what an audit does — it is not CRA compliance and it is not regulatory sign-off.

The Regulation is fifteen months out. The reporting duty is two days out, it reaches everything already on the market ^[A17], and it names you as the manufacturer if your logo is on the login screen ^[A14]. So the question worth answering this week isn't whether you're in scope. It's whether anyone at your company could name, today, the third-party component most likely to generate the first call.

Frequently asked questions

Does the CRA apply to a US company with no EU office?

Yes, wherever the product is made available on the Union market. The CRA applies to products made available on the Union market with no establishment requirement, so where a company is established does not decide the question ^[US-I1]. The Regulation builds importer and authorised-representative roles specifically for manufacturers established outside the Union ^{[US-I2] [US-I3]}.

When does Cyber Resilience Act Article 14 apply from?

Article 14 applies from 11 September 2026. Article 71(2) of Regulation (EU) 2024/2847 sets three different dates: the Regulation applies from 11 December 2027, Article 14 from 11 September 2026, and Chapter IV (Articles 35 to 51) from 11 June 2026 ^[A1].

What has to be reported under Article 14, and to whom?

Two things. Article 14(1) covers any actively exploited vulnerability contained in the product that the manufacturer becomes aware of ^[A4], and Article 14(3) covers any severe incident having an impact on the security of the product ^[A8]. Both go simultaneously to the CSIRT designated as coordinator and to ENISA, and the first deadline for each is an early warning within 24 hours of becoming aware ^{[A5] [A9]}.

Does Article 14 cover products already on the market?

Yes. Article 69(3) applies the Article 14 obligations to all in-scope products with digital elements placed on the market before 11 December 2027 ^[A17]. There is no day-one sweep of history, though: non-binding Commission guidance says a manufacturer is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026 ^[A49].

What are the penalties for failing to report under Article 14?

Article 64(2) sets the top tier and names Article 14 in it: fines up to EUR 15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher ^[A37]. Separately, Article 64(10)(a) exempts microenterprises and small enterprises from the administrative fines in Article 64(3) to (9) for missing the 24-hour early warning specifically ^[A40].

Is there a US equivalent to Article 14?

No federal one that matches it. SEC Form 8-K Item 1.05 must be filed within four business days after the registrant determines it has experienced a material cybersecurity incident, so the clock runs from the materiality determination, not from discovery ^[US-A2]. It covers the registrant's own information systems rather than vulnerabilities in the products it sells ^[US-A10]. CIRCIA's reporting duties are not in force, because they take effect only on the dates prescribed in a final rule that does not exist ^{[US-B5] [US-C2] [US-X2]}.

Sources

• [A1] Article 71(2) of Regulation (EU) 2024/2847 reads in full: "This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026." — http://publications.europa.eu/resource/celex/32024R2847
• [A2] The Cyber Resilience Act as a whole applies from 11 December 2027; only Article 14 applies from 11 September 2026, and Chapter IV (Articles 35 to 51, notification of conformity assessment bodies) from 11 June 2026 — three distinct dates carried in one sentence. — http://publications.europa.eu/resource/celex/32024R2847
• [A3] Regulation (EU) 2024/2847 entered into force on the twentieth day following publication in the Official Journal; published 20 November 2024, it entered into force on 10 December 2024. — http://publications.europa.eu/resource/celex/32024R2847
• [A4] Article 14(1): "A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA. The manufacturer shall notify that actively exploited vulnerability via the single reporting platform established pursuant to Article 16." — http://publications.europa.eu/resource/celex/32024R2847
• [A5] Article 14(2)(a) requires "an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it, indicating, where applicable, the Member States on the territory of which the manufacturer is aware that their product with digital elements has been made available". — http://publications.europa.eu/resource/celex/32024R2847
• [A6] Article 14(2)(b) requires a vulnerability notification "without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability", providing general information about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken, measures users can take, and how sensitive the manufacturer considers the information to be. — http://publications.europa.eu/resource/celex/32024R2847
• [A7] Article 14(2)(c) requires a final report on an actively exploited vulnerability "no later than 14 days after a corrective or mitigating measure is available", containing at minimum a description of the vulnerability including severity and impact, information where available on any malicious actor exploiting it, and details of the security update or corrective measures made available. — http://publications.europa.eu/resource/celex/32024R2847
• [A8] Article 14(3) imposes a second, parallel duty: "A manufacturer shall notify any severe incident having an impact on the security of the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator... and to ENISA." — http://publications.europa.eu/resource/celex/32024R2847
• [A9] For severe incidents, Article 14(4)(a) requires an early warning within 24 hours of becoming aware, including at least whether the incident is suspected of being caused by unlawful or malicious acts; Article 14(4)(b) requires an incident notification within 72 hours of becoming aware. — http://publications.europa.eu/resource/celex/32024R2847
• [A10] The final report clock differs between the two triggers: for an actively exploited vulnerability it is 14 days after a corrective or mitigating measure is available (Art. 14(2)(c)); for a severe incident it is "within one month after the submission of the incident notification under point (b)" (Art. 14(4)(c)). — http://publications.europa.eu/resource/celex/32024R2847
• [A11] Article 3(42) defines "actively exploited vulnerability" as "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". — http://publications.europa.eu/resource/celex/32024R2847
• [A12] Article 3(40) defines "vulnerability" as "a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat". — http://publications.europa.eu/resource/celex/32024R2847
• [A13] Article 14(5) defines when an incident is severe: where "(a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or (b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements." — http://publications.europa.eu/resource/celex/32024R2847
• [A14] Article 3(13) defines "manufacturer" as "a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge". — http://publications.europa.eu/resource/celex/32024R2847
• [A15] Article 21 provides that "An importer or distributor shall be considered to be a manufacturer for the purposes of this Regulation and shall be subject to Articles 13 and 14, where that importer or distributor places a product with digital elements on the market under its name or trademark or carries out a substantial modification of a product with digital elements already placed on the market." — http://publications.europa.eu/resource/celex/32024R2847
• [A16] Article 22(1) provides that a person other than the manufacturer, importer or distributor who carries out a substantial modification of a product with digital elements and makes it available on the market is considered a manufacturer, and by Art. 22(2) is subject to Articles 13 and 14 for the modified part, or for the entire product where the modification affects the cybersecurity of the product as a whole. — http://publications.europa.eu/resource/celex/32024R2847
• [A17] Article 69(3): "By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027." — http://publications.europa.eu/resource/celex/32024R2847
• [A18] Article 69(2) is the general grandfathering rule that Art. 69(3) overrides for reporting: "Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification." — http://publications.europa.eu/resource/celex/32024R2847
• [A19] Official Commission guidance states that, unlike vulnerability handling obligations which run only for a product's support period, "the reporting obligations continue to apply after a product with digital elements is no longer supported". — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A20] Article 3(1) defines "product with digital elements" as "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". — http://publications.europa.eu/resource/celex/32024R2847
• [A21] Article 3(2) defines "remote data processing" as "data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions". — http://publications.europa.eu/resource/celex/32024R2847
• [A22] Recital 12 states that "Cloud solutions constitute remote data processing solutions within the meaning of this Regulation only if they meet the definition laid down in this Regulation", that cloud-enabled functionalities letting users control a device at a distance fall within scope, and that "websites that do not support the functionality of a product with digital elements, or cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within the scope of this Regulation." — http://publications.europa.eu/resource/celex/32024R2847
• [A23] Recital 12 further states that Directive (EU) 2022/2555 (NIS2) "applies to cloud computing services and cloud service models, such as Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS)" — locating standalone cloud services under NIS2 rather than the CRA. — http://publications.europa.eu/resource/celex/32024R2847
• [A24] Commission guidance states that where a manufacturer deploys its own application on third-party IaaS or PaaS, that software "is designed and developed by the manufacturer, or under its responsibility, and may therefore qualify as RDPS", whereas a third-party SaaS application integrated into a product "is therefore not designed and developed by the manufacturer, or under its responsibility" and is instead treated like a third-party component. — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A25] Article 3(22) defines "making available on the market" as "the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge"; Article 3(21) defines "placing on the market" as "the first making available of a product with digital elements on the Union market". — http://publications.europa.eu/resource/celex/32024R2847
• [A26] Recital 15 sets the commercial-activity test: supply in the course of a commercial activity "might be characterised not only by charging a price for a product with digital elements, but also by charging a price for technical support services where this does not serve only the recuperation of actual costs, by an intention to monetise... or by accepting donations exceeding the costs associated with the design, development and provision of a product with digital elements." — http://publications.europa.eu/resource/celex/32024R2847
• [A27] There is no bespoke, custom-made, tailor-made or single-customer exclusion in Regulation (EU) 2024/2847; Article 2 carries product-type exclusions, among them Article 2(7), covering products "developed or modified exclusively for national security or defence purposes or... products specifically designed to process classified information". — http://publications.europa.eu/resource/celex/32024R2847
• [A28] Recital 64 treats tailor-made products as regulated and grants only a narrow contractual deviation: "Manufacturers should only be able to deviate from the essential cybersecurity requirements in relation to tailor-made products that are fitted to a particular purpose for a particular business user and where both the manufacturer and the user have explicitly agreed to a different set of contractual terms." — http://publications.europa.eu/resource/celex/32024R2847
• [A29] The tailor-made deviation is confined to two Annex I points — point (2), secure-by-default configuration, and point (8), free-of-charge dissemination of security updates — both of which say "unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements"; Article 14 is not among the requirements a tailor-made contract can vary. — http://publications.europa.eu/resource/celex/32024R2847
• [A31] Recital 18 sets the open-source condition: "only free and open-source software made available on the market, and therefore supplied for distribution or use in the course of a commercial activity, should fall within the scope of this Regulation", and "the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity." — http://publications.europa.eu/resource/celex/32024R2847
• [A32] Recital 18 also states that "the supply of products with digital elements qualifying as free and open-source software components intended for integration by other manufacturers into their own products with digital elements should be considered to be making available on the market only if the component is monetised by its original manufacturer", and that the Regulation "does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility." — http://publications.europa.eu/resource/celex/32024R2847
• [A34] Commission guidance narrows the FOSS definition further: "software distributed under a free and open-source licence but whose source code is only shared (or allowed to be shared) with paying customers or a limited group of users is not to be considered FOSS within the meaning of Article 3(48)". — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A35] Article 24(3) applies Article 14 duties to open-source software stewards: "The obligations laid down in Article 14(1) shall apply to open-source software stewards to the extent that they are involved in the development of the products with digital elements. The obligations laid down in Article 14(3) and (8) shall apply to open-source software stewards to the extent that severe incidents... affect network and information systems provided by the open-source software stewards for the development of such products." — http://publications.europa.eu/resource/celex/32024R2847
• [A37] Article 64(2) sets the top penalty tier and names Article 14 in it: "Non-compliance with the essential cybersecurity requirements set out in Annex I and the obligations set out in Articles 13 and 14 shall be subject to administrative fines of up to EUR 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." — http://publications.europa.eu/resource/celex/32024R2847
• [A40] Article 64(10)(a) exempts "manufacturers that qualify as microenterprises or small enterprises with regard to any failure to meet the deadline referred to in Article 14(2), point (a), or Article 14(4), point (a)" from the administrative fines in Art. 64(3) to (9) — an exemption covering only the 24-hour early-warning deadline, not the 72-hour notification or the final report. — http://publications.europa.eu/resource/celex/32024R2847
• [A41] Article 64(10)(b) exempts "any infringement of this Regulation by open-source software stewards" from those administrative fines. — http://publications.europa.eu/resource/celex/32024R2847
• [A42] Article 16(1) tasks ENISA with the platform: "For the purposes of the notifications referred to in Article 14(1) and (3) and Article 15(1) and (2) and in order to simplify the reporting obligations of manufacturers, a single reporting platform shall be established by ENISA. The day-to-day operations of that single reporting platform shall be managed and maintained by ENISA." — http://publications.europa.eu/resource/celex/32024R2847
• [A43] The Commission states of the Single Reporting Platform: "ENISA launched a public tender and has procured services from a contractor to assist with the development of the SRP. The Single Reporting Platform will be operational by 11 September 2026 (date of entry into application of the CRA reporting requirements). Functional and security testing are under way." — https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• [A44] ENISA states: "As of 11 September 2026 onwards, the SRP will be used by CSIRTs and manufacturers for mandatory reporting", and that the platform "could be used by any natural/legal persons for voluntary reporting"; its Assigned Representative registration and notification-submission guidance documents are dated 3/08/2026. — https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
• [A45] Article 14(7) routes the notification: it must be submitted "using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturers have their main establishment in the Union and shall be simultaneously accessible to ENISA"; main establishment is "the Member State where the decisions related to the cybersecurity of its products with digital elements are predominantly taken". — http://publications.europa.eu/resource/celex/32024R2847
• [A46] Article 14(7) third subparagraph provides a fallback order for a manufacturer with no main establishment in the Union: the Member State of (a) the authorised representative acting for the highest number of its products, then (b) the importer placing the highest number on the market, then (c) the distributor making available the highest number, then (d) where the highest number of users are located. — http://publications.europa.eu/resource/celex/32024R2847
• [A47] Article 14(8) adds a user-notification duty: after becoming aware of an actively exploited vulnerability or severe incident the manufacturer "shall inform the impacted users of the product with digital elements, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures", and where the manufacturer fails to do so in a timely manner the notified CSIRTs may inform users directly. — http://publications.europa.eu/resource/celex/32024R2847
• [A49] Commission guidance states that the CRA does not require retroactive reporting of active exploitation already known before the start date: "the manufacturer is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026". — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A50] Commission guidance states the converse: where a manufacturer knew of a vulnerability before 11 September 2026 but was not then aware of any active exploitation, and "after 11 September 2026, active exploitation subsequently occurs or the manufacturer becomes aware of it, the vulnerability is deemed an actively exploited one subject to the reporting obligation." — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A51] Commission guidance states that vulnerabilities inherited from dependencies are reportable by the product's manufacturer: "Where a product with digital elements contains an actively exploited vulnerability originating from a third-party component, the manufacturer of the product with digital elements is required to notify that actively exploited vulnerability." — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A52] Commission guidance states that where a manufacturer knows a third-party component contains a vulnerability that cannot be exploited in its own product, that vulnerability "does not qualify as an actively exploited vulnerability contained in its product with digital elements, and therefore it is not subject to mandatory reporting for that manufacturer", though it may be notified voluntarily under Article 15. — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A53] Commission guidance ties the "becoming aware" concept to existing practice: it "is aligned with recital 31 of Commission Implementing Regulation (EU) 2024/2690 and Section II(A) of the Guidelines 9/2022 on personal data breach notification under the GDPR", and requires that a manufacturer "should assess the suspicious event immediately to determine whether it constitutes an actively exploited" vulnerability. — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [A54] Article 2(1) sets the scope gate: "This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network." — http://publications.europa.eu/resource/celex/32024R2847
• [A57] The Commission published non-binding practical guidance on the CRA on 27 July 2026 as C(2026) 5252, stating that it clarifies "when certain products fall within the scope of the Cyber Resilience Act, including remote data processing solutions and free and open source software" and "How to meet reporting obligations and risk assessment requirements". — https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
• [A58] The Commission's own CRA policy page states: "The main obligations introduced by the Act will apply from 11 December 2027, with reporting obligations to apply as of 11 September 2026." — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• [A59] The Commission describes the reporting flow: "Manufacturers report only once through the CRA Single Reporting Platform (SRP). The notification is addressed to the Computer Security Incident Response Team (CSIRT) where they have their main establishment and, unless particularly exceptional circumstances apply, the information is made available simultaneously to ENISA. The CSIRT initially receiving the notification will share without delay the notification with all the other CSIRTs on the territory of which the product with digital elements has been made available." — https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• [A60] The Commission states that open-source software stewards are subject to Article 24 obligations including "reporting actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements", and that "In accordance with Article 64(10), open-source software stewards are not subject to administrative fines for infringements of the CRA." — https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
• [A64] Commission guidance states the manufacturer test in plain terms: the CRA "defines the manufacturer as the natural or legal person that supplies a product with digital elements under its name or trademark, and that does so in the course of a commercial activity (thereby placing it on the market)." — https://ec.europa.eu/newsroom/dae/redirection/document/131456
• [F1] Folklore, refuted. Claim: The Cyber Resilience Act applies from 11 September 2026. — Verdict: FALSE. The Regulation applies from 11 December 2027. Only Article 14 applies from 11 September 2026; Chapter IV (Articles 35 to 51) applied from 11 June 2026. All three dates sit in the single sentence at Art. 71(2). — http://publications.europa.eu/resource/celex/32024R2847
• [F2] Folklore, refuted. Claim: Bespoke or custom software built for one client is exempt. — Verdict: FALSE. No bespoke, custom-made, tailor-made or single-customer exclusion exists anywhere in the Regulation. Recital 64 and Annex I points (2) and (8) treat tailor-made products as in scope and allow contractual deviation on exactly two Annex I points — secure-by-default configuration and free-of-charge update delivery. Article 14 is not variable by contract. — http://publications.europa.eu/resource/celex/32024R2847
• [F3] Folklore, refuted. Claim: Open source is exempt from the CRA. — Verdict: FALSE as stated; the real condition is narrower. Only FOSS that is not monetised by its manufacturer falls outside the commercial-activity test. A FOSS component supplied for integration is "made available on the market" if the original manufacturer monetises it. Commission guidance further excludes from the FOSS definition any software whose source is shared only with paying customers or a limited group. And open-source software stewards carry Article 14(1) duties under Article 24(3). — http://publications.europa.eu/resource/celex/32024R2847
• [F4] Folklore, refuted. Claim: The CRA reporting deadline is 72 hours. — Verdict: INCOMPLETE AND MISLEADING. The CRA has a four-part clock, not a single 72-hour rule: 24-hour early warning, 72-hour notification, then a final report at 14 days after a corrective or mitigating measure is available for actively exploited vulnerabilities, or one month after the 72-hour notification for severe incidents. The 72-hour-only framing is imported from GDPR and NIS2. — http://publications.europa.eu/resource/celex/32024R2847
• [F5] Folklore, refuted. Claim: SaaS is entirely out of scope of the CRA. — Verdict: FALSE as stated; and the opposite overreach is also wrong. A standalone cloud service is dealt with by NIS2 per Recital 12. But a remote data processing solution designed and developed by or under the responsibility of the manufacturer, whose absence would stop the product performing one of its functions, is part of the "product with digital elements" under Art. 3(1)–(2). Software a manufacturer deploys on third-party IaaS or PaaS can qualify as an RDPS; a third-party SaaS application it merely integrates does not, and is treated as a third-party component. — http://publications.europa.eu/resource/celex/32024R2847
• [F6] Folklore, refuted. Claim: Products already on the market are grandfathered until 11 December 2027. — Verdict: FALSE for Article 14. Article 69(2) grandfathers existing products from the Regulation's requirements absent substantial modification, but Article 69(3) expressly derogates: Article 14 applies to all in-scope products placed on the market before 11 December 2027. Official guidance adds that reporting duties survive the end of a product's support period. — http://publications.europa.eu/resource/celex/32024R2847
• [F7] Folklore, refuted. Claim: A CRA fine figure quoted without an article number. — Verdict: Always attach the article. Art. 64(2) — up to EUR 15,000,000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher, and this is the tier that names Article 14. Art. 64(3) — up to EUR 10,000,000 or 2%. Art. 64(4) — up to EUR 5,000,000 or 1%. Fines are set and levied by Member States (Art. 64(1)), not by the Commission. — http://publications.europa.eu/resource/celex/32024R2847
• [F8] Folklore, refuted. Claim: Only the software vendor that wrote the code has to report. — Verdict: FALSE. Article 3(13) captures a person who "has products with digital elements designed, developed or manufactured, and markets them under its name or trademark". Article 21 turns an importer or distributor into a manufacturer where it places a product on the market under its own name or trademark. Article 22 does the same for anyone making a substantial modification. — http://publications.europa.eu/resource/celex/32024R2847
• [F10] Folklore, refuted. Claim: Every known vulnerability in your shipped estate has to be reported on day one. — Verdict: FALSE. The trigger is an actively exploited vulnerability — one with "reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". Official guidance confirms there is no retroactive reporting of active exploitation already known before 11 September 2026. — http://publications.europa.eu/resource/celex/32024R2847
• [US-A1] The SEC adopted final rules titled "Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure," Release Nos. 33-11216; 34-97989, adding Item 1.05 to Form 8-K and Item 106 to Regulation S-K. The adopting release states: "DATES: Effective date: The amendments are effective September 5, 2023." — https://www.sec.gov/files/rules/final/2023/33-11216.pdf
• [US-A2] The Form 8-K filing deadline for a cybersecurity incident runs from the materiality determination, not from discovery. The amended Form 8-K General Instruction B.1 text adopted by the SEC reads: "A report pursuant to Item 1.05 is to be filed within four business days after the registrant determines that it has experienced a material cybersecurity incident." — https://www.sec.gov/files/rules/final/2023/33-11216.pdf
• [US-A5] The SEC rule binds "registrants" — companies with reporting obligations under the Securities Exchange Act of 1934, i.e. US-listed public companies. The adopting release lists the amended forms as Form 8-K (17 CFR 249.308), Form 10-K (17 CFR 249.310), Form 20-F (17 CFR 249.220f) and Form 6-K, and amends Regulation S-K Items 106 and 601. It does not reach private companies. — https://www.sec.gov/files/rules/final/2023/33-11216.pdf
• [US-A6] Compliance dates, quoted from the adopting release: "The final rules are effective September 5, 2023. With respect to Item 106 of Regulation S-K and item 16K of Form 20-F, all registrants must provide such disclosures beginning with annual reports for fiscal years ending on or after December 15, 2023. With respect to compliance with the incident disclosure requirements in Item 1.05 of Form 8-K and in Form 6-K, all registrants other than smaller reporting companies must begin complying on December 18, 2023." — https://www.sec.gov/files/rules/final/2023/33-11216.pdf
• [US-A7] Smaller reporting companies received a delay, quoted from the adopting release: "smaller reporting companies are being given an additional 180 days from the non-smaller reporting company compliance date before they must begin complying with Item 1.05 of Form 8-K, on June 15, 2024." The SEC declined to exempt them entirely. — https://www.sec.gov/files/rules/final/2023/33-11216.pdf
• [US-A10] The SEC rule is a disclosure obligation owed to investors, not a product-security obligation. Item 106(a) defines "cybersecurity incident" as "an unauthorized occurrence, or a series of related unauthorized occurrences, on or conducted through a registrant's information systems" — it is scoped to the registrant's own systems, not to vulnerabilities in products the registrant sells. — https://www.ecfr.gov/current/title-17/section-229.106
• [US-B1] The CIRCIA covered-incident duty is 72 hours. 6 U.S.C. 681b(a)(1)(A) reads: "A covered entity that experiences a covered cyber incident shall report the covered cyber incident to the Agency not later than 72 hours after the covered entity reasonably believes that the covered cyber incident has occurred." — https://www.govinfo.gov/content/pkg/USCODE-2024-title6/html/USCODE-2024-title6-chap1-subchapXVIII-partD-sec681b.htm
• [US-B2] The CIRCIA ransom-payment duty is 24 hours. 6 U.S.C. 681b(a)(2)(A) reads: "A covered entity that makes a ransom payment as the result of a ransomware attack against the covered entity shall report the payment to the Agency not later than 24 hours after the ransom payment has been made." Subparagraph (B) adds that this "shall apply even if the ransomware attack is not a covered cyber incident subject to the reporting requirements under paragraph (1)." — https://www.govinfo.gov/content/pkg/USCODE-2024-title6/html/USCODE-2024-title6-chap1-subchapXVIII-partD-sec681b.htm
• [US-B4] CIRCIA binds "covered entities" in critical infrastructure sectors, not software vendors generally. The statute's reporting duties sit in Title 6 (Domestic Security), Chapter 1, Subchapter XVIII (Cybersecurity and Infrastructure Security Agency), Part D (Cyber Incident Reporting), and the precise population of covered entities is left to be defined by CISA's implementing rule. — https://www.govinfo.gov/content/pkg/USCODE-2024-title6/html/USCODE-2024-title6-chap1-subchapXVIII-partD-sec681b.htm
• [US-B5] CIRCIA's reporting duties are self-suspending until the final rule exists. 6 U.S.C. 681b(a)(7), headed "Effective date," reads in full: "Paragraphs (1) through (4) shall take effect on the dates prescribed in the final rule issued pursuant to subsection (b)." Paragraphs (1) through (4) are the 72-hour, 24-hour, supplemental-report and data-preservation duties. — https://www.govinfo.gov/content/pkg/USCODE-2024-title6/html/USCODE-2024-title6-chap1-subchapXVIII-partD-sec681b.htm
• [US-B6] CIRCIA's statutory rulemaking clock required an NPRM "Not later than 24 months after March 15, 2022" and a final rule "Not later than 18 months after publication of the notice of proposed rulemaking." Since the NPRM was published 4 April 2024, the 18-month final-rule deadline expired on or about 4 October 2025 and has been missed. — https://www.govinfo.gov/content/pkg/USCODE-2024-title6/html/USCODE-2024-title6-chap1-subchapXVIII-partD-sec681b.htm
• [US-C2] No CIRCIA final rule has been published. A Federal Register API query for all documents affecting 6 CFR part 226 (the part the CIRCIA rule would create) returns exactly four documents, all of type "Proposed Rule": 2024-04-04, 2024-06-03, 2026-02-13 and 2026-05-26. There is no document of type "Rule" in the series. — https://www.federalregister.gov/api/v1/documents.json?conditions%5Bcfr%5D%5Btitle%5D=6&conditions%5Bcfr%5D%5Bpart%5D=226
• [US-C3] As late as May 2026 CISA was still gathering input on the 2024 proposal rather than finalising it. The Federal Register notice published 26 May 2026 (91 FR 30498) states: "This notice announces a revised town hall meeting schedule to allow external stakeholders a limited additional opportunity to provide input on refining the scope and burden of the CIRCIA Notice of Proposed Rulemaking (NPRM) issued in the Federal Register on April 4, 2024." — https://www.govinfo.gov/content/pkg/FR-2026-05-26/html/2026-10417.htm
• [US-C5] CISA states on its own CIRCIA page that reporting is not yet required: "While covered cyber incident and ransomware payment reporting under CIRCIA will not be required until the CIRCIA final rule goes into effect, CISA encourages all entities to voluntarily share with CISA information on cyber incidents prior to the effective date of the final rule." — https://www.cisa.gov/topics/cyber-threats-and-advisories/information-sharing/cyber-incident-reporting-critical-infrastructure-act-2022-circia
• [US-C6] CISA gives no compliance date and attributes the delay to funding. Its CIRCIA page states: "While CISA recognizes the importance of CIRCIA, multiple funding lapses impacted CISA's ability to conduct rulemaking activity for CIRCIA. CISA continues to work on the final rule. CISA will communicate updates on the CIRCIA rulemaking process and timeline through CISA.gov/CIRCIA." — https://www.cisa.gov/topics/cyber-threats-and-advisories/information-sharing/cyber-incident-reporting-critical-infrastructure-act-2022-circia
• [US-D2] Section 524B requires a coordinated vulnerability disclosure and postmarket monitoring plan. 21 U.S.C. 360n-2(b)(1) requires the sponsor to "submit to the Secretary a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures." — https://www.govinfo.gov/content/pkg/USCODE-2024-title21/html/USCODE-2024-title21-chap9-subchapV-partA-sec360n-2.htm
• [US-D3] Section 524B requires patching on a defined cadence. 21 U.S.C. 360n-2(b)(2) requires the sponsor to "design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems to address— (A) on a reasonably justified regular cycle, known unacceptable vulnerabilities; and (B) as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks." — https://www.govinfo.gov/content/pkg/USCODE-2024-title21/html/USCODE-2024-title21-chap9-subchapV-partA-sec360n-2.htm
• [US-D4] Section 524B requires an SBOM. 21 U.S.C. 360n-2(b)(3) requires the sponsor to "provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components." — https://www.govinfo.gov/content/pkg/USCODE-2024-title21/html/USCODE-2024-title21-chap9-subchapV-partA-sec360n-2.htm
• [US-D7] Section 524B attaches to a premarket submission, not to sale generally. 21 U.S.C. 360n-2(a) applies to "A person who submits an application or submission under section 360(k), 360c, 360e(c), 360e(f), or 360j(m) of this title for a device that meets the definition of a cyber device." The obligation is a condition of FDA clearance or approval, so it reaches only regulated medical device sponsors. — https://www.govinfo.gov/content/pkg/USCODE-2024-title21/html/USCODE-2024-title21-chap9-subchapV-partA-sec360n-2.htm
• [US-D8] FD&C 524B is the closest US analogue to the CRA in kind — it is a product-security duty covering SBOM, coordinated vulnerability disclosure and postmarket patching — but it is confined to internet-connected medical devices, whereas the CRA covers products with digital elements generally. Basis: D2, D3, D4, D5, D7. — https://www.govinfo.gov/content/pkg/USCODE-2024-title21/html/USCODE-2024-title21-chap9-subchapV-partA-sec360n-2.htm
• [US-E4] OMB M-22-18 and M-23-16 have been RESCINDED. OMB Memorandum M-26-05, dated 23 January 2026, signed by Director Russell T. Vought and titled "Adopting a Risk-based Approach to Software and Hardware Security," states: "OMB Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (M-22-18), imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments. This policy diverted agencies from developing tailored assurance requirements for software and neglected to account for threats posed by insecure hardware. Accordingly, OMB Memoranda M-22-18 and M-23-16, a companion policy, are hereby rescinded." — https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-Based-Approach-to-Software-and-Hardware-Security.pdf
• [US-E5] Under M-26-05 the attestation form is now optional for agencies, not mandatory. The memo states: "Agencies shall continue to maintain a complete inventory of software and hardware and develop software and hardware assurance policies and processes that match their risk determinations and mission needs. Agencies may choose to use the government-wide secure software development resources developed under M-22-18, such as the Secure Software Development Attestation Form." — https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-Based-Approach-to-Software-and-Hardware-Security.pdf
• [US-E7] CISA's Secure Software Development Attestation Form page has been rewritten to reflect M-26-05 and now describes the form as discretionary: "According to OMB Memorandum M-26-05, Adopting a Risk-Based Approach to Software and Hardware Security, federal agencies must maintain a complete inventory of software and hardware and establish assurance policies and processes aligned with their risk assessments and mission needs. Agencies may choose to use government-wide secure software development resources created under M-22-18, including the Secure Software Development Attestation Form. They may also elect to include contractual requirements for software producers to provide a current Software Bill of Materials (SBOM) upon request." — https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form
• [US-E9] Even at its strongest, the attestation regime was a federal-procurement condition, not a law binding software vendors generally. It applied to producers of software used by federal agencies, and its authority chain ran through 44 U.S.C. 3554 (federal agency information security) and E.O. 14028, not through any general commercial-software statute. Basis: E2, E5, E6. — https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form
• [US-F2] SP 800-218 is explicitly a set of recommendations, not a mandate. Its abstract states it "recommends the Secure Software Development Framework (SSDF) — a core set of high-level secure software development practices that can be integrated into each SDLC implementation," and notes that "software purchasers and consumers can also use it to foster communications with suppliers in acquisition processes and other management activities." NIST publications carry no independent force of law; SP 800-218 became binding only where incorporated by a procurement instrument. — https://csrc.nist.gov/pubs/sp/800/218/final
• [US-G1] No. There is no US federal statute or regulation imposing product-security requirements or vulnerability-reporting duties on commercial software vendors selling to private-sector customers generally. Every US obligation located in this research is qualified by one of three limiting hooks, and none of them is "sells software commercially." Basis: G2. — no source URL (analysis of the sources listed above; no single primary states it)
• [US-G2] The three hooks, each verified above, are: (i) securities-listing status — the SEC rule binds "registrants" and concerns disclosure to investors about the registrant's own information systems, not its products (A5, A10); (ii) critical-infrastructure status — CIRCIA binds "covered entities" in critical infrastructure sectors, and is in any case not yet in force (B4, B5, C8); (iii) sector regulation or federal procurement — FD&C 524B binds only sponsors of FDA premarket submissions for internet-connected medical devices (D7), and the attestation regime bound only producers of software sold to federal agencies, and is now discretionary (E5, E9). — no source URL (analysis of the sources listed above; no single primary states it)
• [US-G4] Negative finding: this is established by exhaustively verifying the scope limits of each candidate US instrument (A5, A10, B4, D7, E9), not by an exhaustive search of the entire US Code, which was not possible without WebSearch. It should be written as "no general federal product-security duty was found, and each federal instrument that does exist is limited to a specific sector, listing status or procurement relationship," rather than as an absolute claim that no such law could exist anywhere in US law. Confidence: high for federal law; the state-level exception at H1 is real and should be stated alongside it. — no source URL (analysis of the sources listed above; no single primary states it)
• [US-H1] At least one US state does impose a product-security duty, and it is a device law rather than a breach-notification law. California Civil Code 1798.91.04(a), within Title 1.81.26 "Security of Connected Devices," provides: "A manufacturer of a connected device shall equip the device with a reasonable security feature or features that are all of the following: (1) Appropriate to the nature and function of the device. (2) Appropriate to the information it may collect, contain, or transmit. (3) Designed to protect the device and any information contained therein from unauthorized access, destruction, use, modification, or disclosure." — https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.91.04
• [US-H3] the California connected-device law is a design requirement with no reporting clock — it requires "reasonable security features" at manufacture and imposes no duty to notify any authority when a vulnerability is found or exploited. It is therefore not an analogue to CRA Article 14, which is a reporting obligation. Basis: H1, H2 — the statutory text contains no notification provision. — https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.91.04
• [US-H4] US state breach-notification laws (all 50 states have one) are triggered by unauthorised acquisition of residents' personal information and require notice to affected individuals and sometimes a state attorney general. They are not triggered by the discovery of a vulnerability in a product the company sells, and they do not require notice to a national cybersecurity authority. Conflating them with CRA Article 14 reporting is a category error: different trigger (personal data compromise vs actively exploited product vulnerability), different recipient (data subjects vs CSIRT/ENISA), different subject matter (data custody vs product security). Confidence: high as a structural characterisation; note that individual state statutes were not fetched in this pass beyond H1. — no source URL (analysis of the sources listed above; no single primary states it)
• [US-H5] California's connected-device law is scoped to "connected device" — a physical internet-connected device — not to software generally. The obligation attaches to "A manufacturer of a connected device." Pure software sold without hardware is outside it. — https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.91.04
• [US-I1] CRA scope is market-based, not establishment-based. The European Commission's official summary of the legislative text states the CRA "is a horizontal regulatory framework of the European Union (EU), which applies to hardware and software products ('products with digital elements') that are made available on the Union market. Such products include both final products and components placed separately on the market." Nothing in that scope statement requires EU establishment. — https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• [US-I2] The CRA expressly contemplates non-EU manufacturers and builds machinery for them. The Commission summary defines an importer as "A natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a natural or legal person established outside the Union," and an authorised representative as "A natural or legal person established within the Union who has received a written mandate from a manufacturer to act on its behalf in relation to specified tasks." The existence of both roles presupposes manufacturers established outside the EU are in scope. — https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• [US-I3] The Commission summary further states: "The importer is a natural or legal person established in the Union who places on the market a product with digital elements manufactured outside the Union. The importer needs to ensure that the product is in compliance with the CRA, by ensuring inter alia that the manufacturer..." — confirming that goods manufactured outside the Union are squarely within the regime. — https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• [US-I4] "Placing on the market" is defined in the Commission summary as "The first making available of a product with digital elements on the Union market," and "making available" as "The supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge." Note that free-of-charge supply is included. — https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• [US-I9] Reporting obligations reach products already on the market. The Commission states the reporting obligations "apply to all products with digital elements that have been made available on the Union market, including those already placed on the market before 11 December 2027." — https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• [US-X2] Folklore, refuted. Claim: "CIRCIA is in force." False as at 4 September 2026. The statute self-suspends its own duties until a final rule sets effective dates (B5); no final rule has been published and every Federal Register document affecting 6 CFR part 226 is a proposed rule (C2); CISA itself says reporting "will not be required until the CIRCIA final rule goes into effect" (C5) and gives no timeline (C6). Do not write that US critical-infrastructure firms face a live 72-hour clock. — https://www.govinfo.gov/content/pkg/USCODE-2024-title6/html/USCODE-2024-title6-chap1-subchapXVIII-partD-sec681b.htm
• [US-X3] Folklore, refuted. Claim: "The SEC rule requires disclosure within four days of discovery." False on two counts. It is four business days, not four days; and the clock starts on the materiality determination, not on discovery. The adopted Form 8-K instruction reads "within four business days after the registrant determines that it has experienced a material cybersecurity incident" (A2, A4). This is the single most-often-garbled fact in this area and is worth stating explicitly in the post. — https://www.sec.gov/files/rules/final/2023/33-11216.pdf
• [US-X4] Folklore, refuted. Claim: "State breach-notification laws are the US equivalent of CRA Article 14." False — category error. Breach-notification laws trigger on compromise of residents' personal information and require notice to affected individuals; CRA Article 14 triggers on an actively exploited vulnerability or severe incident in a product and requires notice to a CSIRT and ENISA (H4, I6). Different trigger, different recipient, different subject matter. — no source URL (analysis of the sources listed above; no single primary states it)
• [US-X6] KILLED (new, and the prior pass's finding is now superseded): "US federal software suppliers must sign the CISA secure-software attestation." No longer accurate as a mandate. OMB M-26-05 of 23 January 2026 rescinded both M-22-18 and M-23-16 (E4), and agencies "may choose to use" the attestation form rather than being required to collect it (E5, E7). The form still exists, still carries OMB Control # 1670-0052 with expiration 03/31/2027 (E1), and the "Archived Content" banner seen in the prior pass is no longer present (E8). Write it as "was mandatory, rescinded January 2026, now agency discretion." — https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-Based-Approach-to-Software-and-Hardware-Security.pdf