Work in progress · updated 26 Oct 2026 · notes, not conclusions

Aware since when? Who starts the EU's 24-hour clock

Since 11 September 2026, makers of most software and connected devices sold in the EU face a new deadline. Within 24 hours of becoming aware that attackers are using a flaw in their product, they must warn the authorities. When the report of that flaw may be written by AI, how can a screen help a person decide that moment, and record it?

The basics, in plain words

A vulnerability is a flaw that an attacker could use to do harm. Here I just call it a flaw.

The EU's Cyber Resilience Act (CRA) is a law about the security of software and connected devices sold in the EU, with some exceptions. Since 11 September 2026, one part of it, Article 14, has required the makers of those products to report flaws in them that attackers are using.

The law keeps two ideas apart. A flaw is exploitable if an attacker could use it in practice. It is actively exploited when there is reliable evidence that an attacker has already used it. Only the second starts the clock.

Once a maker is aware that a flaw in its product is actively exploited, it must send an early warning "without undue delay", and within 24 hours at most. A fuller report is due within 72 hours of becoming aware. A final one is due within 14 days after a fix or workaround is available. All go through one website run by ENISA, the EU's cybersecurity agency.

The European Commission, the EU's executive body, has written guidance on applying the law. By its own words, the guidance is non-binding: it doesn't bind the companies the law covers.

If a flaw doesn't affect a product, the maker can publish a "not affected" statement that computers can read. Statements like this, about whether a product is affected, are often called VEX. Customers' scanners, tools that check software for known flaws, can read it and stop warning about that flaw.

What "aware" means, and what ENISA's form asks

The law doesn't define "aware". The Commission's non-binding guidance says a maker is aware when, after a first check, it has "a reasonable degree of certainty" that the flaw is being actively exploited. That is a judgement, so I think a person should make it. ENISA's glossary for its reporting form lists a required field, a box on the early-warning form: "when you become aware". But that field's help text asks when the maker "or another relevant party first detected" the flaw. In the printer example, the flaw was first detected on Friday or earlier, days before any sign of an attack. If the maker doesn't know the exact time, the help text asks it to enter its best estimate and mark it as estimated. The evidence can go only into free-text boxes, such as a summary of the facts or an optional note on what the attacker was seen doing. I found no field for how sure the maker was. Since 21 October, the glossary marks the field mandatory for the early warning, but its help text hasn't changed.

One decision, two records

One quick judgement, sometimes about a report an AI may have written, becomes two records that others read later. The first is the "aware" time, which the authorities may ask about. The second is the "not affected" statement, which customers' scanners may act on with nobody looking. Say "aware" too early, and an unchecked report reaches the authorities. Too late, and the maker has missed a legal deadline. A wrong "not affected" can hide a real risk from every customer whose scanner reads it. And getting its reason right is harder still, at least for AI. One benchmark, a standard test from a paper accepted at a peer-reviewed conference, has 75 cases that security experts labelled. Two of the nine AI models tested scored about 80% on whether the software in each case was affected. (The score is F1, which counts both missed and false answers.) On the reason why, only one of the nine scored above 70%. In the usability research I searched, I found no study of how people make this call. Not finding a study proves less than a measurement would.

Why it matters

The reporting rule already applies, though most of the law only applies from 11 December 2027, more than a year later. It also covers products already on sale.

AI-written reports add to the work of the people who sort flaw reports. A survey of research, accepted at a workshop, describes "hallucinated vulnerabilities": flaws that an AI made up. It says these, and other AI-made material, put a burden on those people. The burden "mirrors a denial-of-service attack": a flood that stops a service working. And the Commission's non-binding guidance says a maker should check a report like this straight away. It may take some time, the guidance adds, to establish whether the product is affected and whether attackers are using the flaw.

Meanwhile, ENISA says parts of the official website are still to come. At its first release, it has "no Application Programming Interface (API)", a way for a maker's own software to send reports to it. So people fill in its forms by hand. For flaws that attackers are using, ENISA's page of frequently asked questions describes one countdown, for the 72-hour report. It sets the due time 48 hours after the early warning is sent, not 72 hours after "aware", so it can show a report as overdue too early. My reading: with no countdown described for the 24 hours, that count is left, for now, to the maker's own tools. A future version of the website will count the 72 hours from the time in the "aware" field, ENISA says, and an API "may be considered in a future phase". Neither has a date.

What I'm trying

• Three questions, kept apart: is the report real, does the flaw work in this product, are attackers using it? Each answer is Yes, No or Not known yet, in a word and a shape, with its evidence, who gave it and when. Only a Yes to the third can lead to the button that starts the clock. (The separate questions and their three answers are my proposal. The line between exploitable and actively exploited is the law's.)
• "Aware" is a button someone presses, not a time someone types in. A named person presses "I'm reasonably certain this is being exploited", which saves the evidence at that moment and starts the 24-hour count. "Report received" and "first detected" keep their own times. Until someone presses, the screen shows how long the question has been open. The press records when a person made the call. It doesn't decide what the authorities will accept. (My proposal. The button's words echo the Commission's non-binding guidance.)
• Polished writing is not evidence. Split an AI-written report into claims that can be checked, such as the software version, the part of the code and the harm. Mark each one Reproduced (the team made it happen), Not reproduced or Not checked. On the screen, show the checked claims more strongly than the polished writing. (My proposal.)
• Before a "not affected" statement goes out, show a preview of what it will silence. It lists the reason, picked from a fixed list, and the evidence. It shows which customers' scanners will go quiet, a date to check it again and who signs it. Taking it back is one step. (Reasons picked from a fixed list are in one common format's rules; the rest is my proposal.)
• Let an AI agent, an AI tool that acts on its own, draft a "not affected" statement, but never sign it. One public open-source agent ruleset, marked experimental by its authors, already forbids its agent from drafting one when it rates its confidence as low (its "Low confidence band"). Open-source means anyone can read and reuse it. The ruleset names the person who approves the statement as its "author of record". (That ruleset is the precedent. Applying it to every "not affected" statement, and showing it on the screen, is my proposal.)

What would show it works

The test: people who sort flaw reports for a living, in two groups, work through six made-up reports. Three are well written but wrong. One doesn't affect the product, one is real but not yet used by attackers, and attackers start using one on day two. One group uses a plain ticket (a record for tracking a piece of work) with one status and a "first detected" time. The other uses the three questions, the button and the preview. It works if three things hold for the second group, compared with the first. More of them start the clock on the attacked report, and on no other. Fewer publish a "not affected" statement that the evidence doesn't support. And they aren't slower. It will be a small, informal test, and this page will say how many people took part. So far, nobody has (n = 0).

Next step

Turn the figure into screens that can be clicked through: the three questions, the button and the preview, on made-up reports only. The test comes after my study of the verdict card, a screen for checking an AI's answer: one study at a time. Until it runs, this is a design proposal, not a finding.

Sources

• Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)the law, Official Journal L 2024/2847, 20 Nov 2024, read 19 Oct 2026 from the EU Publications Office copy: what it covers, and the exceptions (Art. 2, 3(1)); exploitable and actively exploited (Art. 3(41), 3(42)); the three reports, "without undue delay", through one website run by ENISA (Art. 14(1), 14(2), 16(1)); the dates, and products already on sale (Art. 69(3), 71(2))
• Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)Annex to C(2026) 5252, content approved 27 Jul 2026 as a draft Communication; non-binding, by its own para. 8: "aware" as "a reasonable degree of certainty" after a first check, and a report from someone else to be checked straight away (para. 213); it may take time to establish whether a product is affected and the flaw exploited (para. 214)
• Frequently Asked QuestionsENISA, CRA Single Reporting Platform, page updated 15 Oct 2026, read 19 Oct: no API at the first release, and one "may be considered in a future phase" (FAQ 15); the 72-hour counter, no final-report counter yet for flaws attackers are using, and a future release that will count from the "aware" field (FAQ 26). No dates given
• CRA SRP GlossaryENISA, version 1.6, last update 21 Oct 2026, read 26 Oct: field v26, "when you become aware", mandatory for the early warning; its help text, "first detected", and the ask to mark an estimate as estimated; free text for the facts and for what the attacker was seen doing (fields 3 and v27)
• AI Slop and Hallucinations in Vulnerability Assessment: A Survey on Reasoning Failures and Trustworthy MitigationarXiv 2608.25667, Aug 2026; a survey of research, accepted at a workshop (SiMLA 2026): "hallucinated vulnerabilities"; "mirrors a denial-of-service attack"
• VEX-Bench: Benchmarking LLM Agents for Assessing Exploitability of Software Supply Chain VulnerabilitiesarXiv 2609.08040, Sep 2026, accepted at a peer-reviewed conference (EMNLP 2026): 75 cases labelled by security experts; two of nine models at about 80% F1 on affected or not; one of nine above 70% on the reason
• OpenVEX Specification v0.2.0read 19 Oct 2026; one common format for "not affected" statements: tools "can key on the status labels to alter their behavior", with scanners that "stop alerting" as its example; reasons as fixed labels, free text "highly discouraged for automated systems"
• VEX Generation Instructionsone public open-source agent ruleset, under the MIT licence, marked experimental by its authors; read 19 Oct 2026: no "not affected" drafts in the "Low confidence band"; the human approver is the "author of record"

Related work

• The agent is done. The case isn't.how an AI's answer should show its evidence to the person checking it; here the AI-written report comes from outside, and that person's call can start a legal clock
• Letting an agent act alonewhen an AI agent may act without asking first; here, my proposal that it may draft a "not affected" statement but never sign one
• When another AI asks your producta "not affected" statement is also an answer that machines read and act on, with no screen in between