[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:en:when-does-the-cra-24-hour-clock-start-becoming-aware":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"en","when-does-the-cra-24-hour-clock-start-becoming-aware","When does the CRA's 24-hour clock start? 'Becoming aware', from the Commission's guidance","The 24 and 72 hours run from the moment the manufacturer 'becomes aware', and the Regulation never says what that means. The Commission's guidance of 27 July 2026 does, in paragraphs 211 to 218: a reasonable degree of certainty, after an initial assessment, borrowed word for word from the NIS2 implementing regulation and the GDPR breach guidelines. What that makes of a customer email, a scanner alert, a listed CVE in a component, a bug-bounty zero-day, and a vulnerability you knew about before 11 September.","2026-09-11","\nArticle 14(2)(a) of the Cyber Resilience Act, Regulation (EU) 2024\u002F2847, gives a manufacturer 24 hours \"of the manufacturer becoming aware of the actively exploited vulnerability\" to file an early warning, and Article 14(4)(a) says the same for a severe incident. The 72-hour notification runs from the same moment. Everything a manufacturer will be judged on in the first three days of an incident hangs on when that moment was, and the Regulation does not define it. It defines the thing you have to be aware of: Article 3(42) says an actively exploited vulnerability is one \"for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner\". It does not say when reliable evidence becomes awareness.\n\nThe Commission's guidance on the application of the Regulation, C(2026) 5252 of 27 July 2026, does, in section 9.1, paragraphs 211 to 218. This article is those eight paragraphs, with the two older texts they are copied from, applied to the five ways a manufacturer actually finds out.\n\n## The test: a reasonable degree of certainty, after an initial assessment\n\nParagraph 213 is the operative sentence. A manufacturer that detects a suspicious event, or has one brought to its attention by \"an individual, a customer, an entity, an authority, a media organisation or other source\", \"should assess the suspicious event immediately to determine whether it constitutes an actively exploited vulnerability or a severe incident\", and:\n\n> The manufacturer is therefore to be regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty that: (i) a vulnerability contained in its product with digital elements is being actively exploited; or (ii) a severe incident has occurred and has led to the security of its product with digital elements being compromised.\n\nThree things follow, and paragraph 214 spells out two of them. The moment is not the first signal: \"the point in time at which a manufacturer can be considered to be aware will depend on the circumstances\", and \"in others, it may take some time to establish whether a product with digital elements is affected by a vulnerability and whether that vulnerability is being exploited by a malicious actor\". The assessment is not optional and not slow: \"the emphasis should be on prompt action to carry out the initial assessment to determine whether such conditions are indeed met, particularly where the vulnerability may pose a significant risk\". And, from paragraph 215, you are not expected to know everything at hour 24: the three-stage structure \"requires manufacturers to update their notifications progressively, as their internal investigations advance\".\n\nSo the clock starts neither when the email arrives nor when forensics finishes. It starts when a prompt initial assessment reaches reasonable certainty that your product is being exploited, or that a severe incident has compromised its security. The word doing the work is \"prompt\", and it is why the assessment has to be a procedure with a start time and an owner rather than a meeting somebody will call.\n\n## Where the words come from\n\nParagraph 212 says the guidance \"is aligned with recital 31 of Commission Implementing Regulation (EU) 2024\u002F2690 and Section II(A) of the Guidelines 9\u002F2022 on personal data breach notification under the GDPR\". That alignment is not loose. Recital 31 of the NIS2 implementing regulation reads: when an entity \"has detected a suspicious event, or after a potential incident has been brought to its attention by a third party, such as an individual, a customer, an entity, an authority, a media organisation, or another source, the relevant entity should assess in a timely manner the suspicious event\", and \"is therefore to be regarded as having become 'aware' of the significant incident when, after such initial assessment, that entity has a reasonable degree of certainty that a significant incident has occurred\". The EDPB's breach guidelines, paragraph 31, say a controller \"should be regarded as having become 'aware' when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised\", and paragraph 34 allows \"a short period of investigation\" during which the controller \"may not be regarded as being 'aware'\", provided the investigation \"should begin as soon as possible\".\n\nThe practical consequence is large for a company that already has a GDPR breach procedure, which is every company with customers. The CRA trigger is the same trigger, applied to product security instead of personal data. The procedure, the assessment, the two timestamps and the person who decides can be the same ones, and a company reporting under NIS2 as well has three obligations running on one definition.\n\n## Five ways you find out, and what each one starts\n\nThe Commission's FAQ on the implementation, version 1.4 of 4 September 2026, section 5.1, lists how a manufacturer may become aware without requiring it to monitor any of them: a customer or partner reporting unusual activity, threat intelligence, a government agency's notification, an ethical hacker's report, the manufacturer's own telemetry, scanning or honeypots. Read with the guidance, each signal is a \"suspicious event\" that starts the assessment, not the clock.\n\n**A customer's email.** The assessment begins when the email is read, and it must be immediate. If the customer's evidence is what the definition calls reliable, the assessment may take an hour, and the clock starts then. A team that leaves the email until Monday does not move the clock to Monday: paragraph 214's \"prompt action\" is the standard a market surveillance authority will hold the timeline against, and the only defence is a record showing when the assessment began, who did it, and what it concluded.\n\n**A scanner alert that a component's CVE is on an exploited-vulnerabilities list.** This is the case most software companies will meet first, and paragraph 218 answers it. A manufacturer reports an actively exploited vulnerability \"contained in their product\". If it knows a third-party component contains a vulnerability that \"either (i) cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable) or (ii) has not been exploited in its product with digital elements, 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\". So a listing is a suspicious event. The assessment asks two questions: is the vulnerable code reachable in our product, and is there reliable evidence it is being exploited in our product, not only in somebody else's. Reasonable certainty on both starts the clock; reasonable certainty against either ends the matter as a mandatory report, leaving the voluntary route of Article 15 and the duty under Article 13(6) to report the vulnerability upstream to the component's maintainer. The FAQ's section 5.4 adds that the component's own manufacturer, if the component was placed on the market separately, reports it as well.\n\n**A zero-day from a bug bounty or a test lab.** Not an actively exploited vulnerability, and not a mandatory report. FAQ 5.2: a zero-day \"discovered by ethical hackers, for which there is no evidence of previous malicious exploitation, and which is disclosed to the product's manufacturer as part of its bug-bounty programme\" is not subject to mandatory reporting, and neither is one found by \"a cybersecurity assessment laboratory performing tests on behalf of the manufacturer\". Recital 68 says the same of good-faith research. The vulnerability handling duties of Annex I Part II still apply in full; the notification does not.\n\n**A vulnerability you knew about before 11 September 2026.** Paragraph 217 draws the line at exploitation, not at the vulnerability. A manufacturer \"is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026\". But \"the obligation does apply where the manufacturer was aware of a vulnerability before 11 September 2026 but was not, at that time, aware of any active exploitation of it\". If exploitation occurs, or you learn of it, after that date, the clock starts on the day you learn. An old vulnerability is no defence; old knowledge of its exploitation is.\n\n**A severe incident.** The second limb of paragraph 213: reasonable certainty that \"a severe incident has occurred and has led to the security of its product with digital elements being compromised\". Whether an incident is severe is Article 14(5): it affects or is capable of affecting the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or it has led or is capable of leading to malicious code being introduced or executed in the product or in a user's systems. An outage that touches none of those is an incident but not a notification. The assessment therefore has a third question for incidents: which of the two Article 14(5) limbs is met, and the answer belongs in the 72-hour notification's initial assessment field.\n\n## The scope of the duty is wider than the rest of the Regulation\n\nParagraph 210 makes two points that surprise people. Article 14 applies from 11 September 2026 to every product with digital elements in scope, \"including products with digital elements placed on the market before 11 December 2027\". And the reporting duty outlives the support period: \"unlike the vulnerability handling obligations, which continue only for the length of a product's support period, the reporting obligations continue to apply after a product with digital elements is no longer supported\". For a product placed on the market before December 2027 or past its support period, the manufacturer must still notify but \"is not required to comply with the vulnerability handling obligations set out in Part II of Annex I\". The FAQ, 5.3, recognises that for old products the manufacturer \"may not be able to investigate such vulnerabilities\" because build environments and staff are gone, and says the notification is still owed.\n\n## After the notification: users, and what not to publish\n\nParagraphs 219 to 221 concern Article 14(8), the duty to inform impacted users \"and, where appropriate, all users\". The guidance reads it as risk-based: informing users \"does not imply that such information must be made public or disclosed indiscriminately\", and manufacturers \"may limit the disclosure of detailed information to the relevant users or customers concerned\", particularly for products \"used in sensitive or essential environments, where public disclosure of technical details could itself increase cybersecurity risks\". Broader disclosure \"may be appropriate\" once the vulnerability is mitigated, and Annex I Part II point 4 requires public disclosure of fixed vulnerabilities once the security update is out. The CSIRT that received the notification may inform users itself if the manufacturer fails to do so in a timely manner.\n\n## What to write down before you need it\n\nThe guidance turns \"became aware\" from a fact into a finding, and findings need a procedure. One page is enough.\n\n1. **What counts as a suspicious event.** The FAQ's list, plus your own channels: the security contact address Annex I requires, the scanner, the customer support queue, the news.\n2. **Who does the initial assessment, and by when.** A named person and a deputy, and a cap on the assessment measured in hours. \"Immediately\" and \"prompt\" are the Commission's words; a cap you set and keep is how you show you met them.\n3. **The two questions, in the Commission's wording.** For a vulnerability: is it in our product and reachable, and is there reliable evidence of exploitation in our product. For an incident: has it occurred, has it compromised the product's security, and which Article 14(5) limb applies.\n4. **Two timestamps, both in UTC.** When the suspicious event was detected or received, and when the assessment reached reasonable certainty. The second is \"became aware\" and starts the clock; the first, and the gap between them, is what shows the assessment was prompt. The reporting platform asks for the second and, for a vulnerability, will only gain the field in a later release, so your own record is the one that exists on the day.\n5. **Who signs the finding, and where it is filed.** The person who decides reasonable certainty has been reached, and the record that the market surveillance authority will read if the timeline is ever questioned.\n\nThat record is what StandardOS's CRA reporting event is: a scope determination, the named filer and deputy, the coordinator to select, an awareness timestamp with the reasoning beside it, and the three deadlines computed from it in the Regulation's terms rather than the platform's. [The deadlines page](\u002Fcyber-resilience-act\u002Freporting-deadlines) computes them for anyone; [how the platform then takes the notification](\u002Farticles\u002Fhow-to-file-a-cra-notification-on-enisa-s-single-reporting-platform) is the next article, and [which coordinator receives it](\u002Farticles\u002Fwhich-csirt-do-you-report-to-under-cra-article-14) the one before.\n\n## Sources\n\n- Regulation (EU) 2024\u002F2847, Article 3(42), Article 13(6), Article 14(1) to (5) and (8), Article 15, Article 69(3), Recital 68.\n- European Commission, Commission guidance on the application of Regulation (EU) 2024\u002F2847, C(2026) 5252 final of 27 July 2026, Annex, section 9.1 paragraphs 209 to 221 and section 9.2.\n- European Commission, FAQs on the Cyber Resilience Act, version 1.4 of 4 September 2026, sections 5.1 to 5.5.\n- Commission Implementing Regulation (EU) 2024\u002F2690, recital 31.\n- European Data Protection Board, Guidelines 9\u002F2022 on personal data breach notification under GDPR, version 2.0, paragraphs 31 to 34.\n\nThis is not legal advice. The eight paragraphs of the guidance take ten minutes to read, and the article numbers above are there so you can.\n",1789383985709]