Cyber Resilience Act answers now cite the article

On 11 September 2026, the reporting duty in Article 14 of the Cyber Resilience Act started to apply. From that date, a manufacturer of a product with digital elements that becomes aware of an actively exploited vulnerability in that product owes an early warning within 24 hours, a fuller notification within 72 hours, and a final report after that: 14 days for a vulnerability once a corrective measure is available, one month for a severe incident (Regulation (EU) 2024/2847, Articles 14 and 71).

A duty with a 24-hour clock turns a roughly right answer into a liability. The questions that arrive once the clock is live are specific, not thematic. Does the product count as a product with digital elements at all. Which class it falls into, and which conformity route follows from the class. Who the coordinating CSIRT is and where the report goes. A plausible-sounding answer that gets the provision wrong is worse than no answer, because you act on it.

The CRA is also exactly where a general-purpose assistant is at its worst. The regulation entered into force on 10 December 2024, recent enough that model memory of its text is thin, and its application is staggered under Article 71 in a way that catches even people in the field anchoring on the wrong date: the main application date of 11 December 2027, when the essential requirements, conformity assessment, and CE marking start, is the one most roadmaps name, and it sits more than a year after the reporting duty that already binds manufacturers.

Before, and now

Until this shipment, the CRA was not one of the assistant's curated framework packs. A CRA question was answered from the same general path as any other question: model knowledge, no article-level citation to stand on. For GDPR, DORA, UK GDPR, and CCPA/CPRA we had already solved that with packs that cite the paragraph and the point. The CRA was the gap, and the gap sat exactly on the clock that was already running.

What shipped in September 2026 is a curated knowledge pack for Regulation (EU) 2024/2847, verified against the official text, covering all 71 articles at article level, with point-level subdivision where the advice depends on it:

• Article 13, the manufacturer duties: support period and security-update commitments, a single point of contact, a coordinated vulnerability disclosure policy.
• Article 14, the reporting cascade and its clocks, including what counts as a severe incident.
• Articles 15 to 17, voluntary reporting and the ENISA single reporting platform.
• Articles 18 to 26, importers, distributors, substantial modification, and open-source software stewards.
• Articles 27 to 34, the conformity routes and the routing between class I, class II, and critical products.
• Article 64, the penalty bands, which reach EUR 15 million or 2.5 percent of total worldwide annual turnover for the most serious breaches.
• The annex coverage: Annex I essential requirements and vulnerability-handling duties, Annex II user information, the Annex III product classes and Annex IV critical products lists, and the Annex VII technical documentation.

Every row carries the actor it applies to, following the regulation's own taxonomy: manufacturer, importer, distributor, open-source software steward, authorised representative, notified body, market surveillance authority, CSIRT, ENISA. An importer asking whether a duty lands on it gets an answer that names the article and says whose duty it is, rather than a summary written from the manufacturer's point of view.

What "CRA" does not trigger

One detail from the same week shows how the pack behaves in practice. CRA is not a safe acronym: it also means credit rating agency, the US Community Reinvestment Act, and the Canada Revenue Agency. The assistant does not load the EU pack on a bare CRA mention; the question itself has to carry a clear EU-product cue, so a bank asking about its capital ratios or a tax question about the Canada Revenue Agency does not get a European product-safety pack injected into the answer. That collision guard shipped as a fix the same week as the pack itself.

Who this is for

Manufacturers of products with digital elements sold into the EU, importers and distributors carrying those products, and open-source software stewards deciding whether the regulation reaches them. Also the GRC leads and consultants who field their questions, including teams whose ISO 27001 scope never touched product law and who now find a reporting duty on the calendar. The pack sits in the shared framework registry, so the same references come back over the API and in embed, and heyGRC answers CRA questions with them too.

Two boundaries stay in place. This is reference knowledge for guidance, not a legal opinion, and the answers cite the provision they rest on. And this post is not the reference itself: the strategy argument, why the 2026 clock outranks the 2027 date in your sequencing, is in The CRA is a 2026 problem, not a 2027 one. The full obligations and timeline, including the Article 71 clock and the Article 14 reporting table, live in the Cyber Resilience Act obligations and timeline guide, and the question "does this even apply to us" is what the CRA applicability checker answers.