The Cyber Resilience Act's Art. 14 clock starts on the day a manufacturer becomes aware of active exploitation, and a scan result exported once can only date the day of the export; here are the four properties the output of a recurring check needs before it can stand as evidence.
The Cyber Resilience Act's Art. 14 clock starts on the day a manufacturer becomes aware of active exploitation, and a scan result exported once can only date the day of the export; here are the four properties the output of a recurring check needs before it can stand as evidence.
The Commission's draft guidance on the Cyber Resilience Act, whose content it approved on 27 July 2026 and which applies only once formally adopted, spends one paragraph on what a manufacturer already knew. Paragraph 217 says a manufacturer "is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026", and two sentences later that a vulnerability it knew of before that date, without knowing of any exploitation, is reportable once exploitation becomes known. That is two dates: the day you knew the vulnerability existed, and the day you knew it was being used. From 11 September 2026, Art. 14 of the Regulation turns the second one into the start of a clock. A scan result exported on one day dates what your checks knew on that day and nothing after. That gap is what this post is about.
Regulation (EU) 2024/2847 staggers its own start. Art. 71(2): "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." Chapter IV concerns conformity assessment bodies, so for a manufacturer the only obligation that switches on in September is Art. 14. Art. 69(3) applies it "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".
Art. 14(1) requires a manufacturer to notify "any actively exploited vulnerability contained in the product with digital elements that it becomes aware of" to the coordinating CSIRT and to ENISA. The deadlines are in Art. 14(2):
(a) 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 […]; >(b) unless the relevant information has already been provided, a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability […]; >(c) unless the relevant information has already been provided, a final report, no later than 14 days after a corrective or mitigating measure is available […]. >Art. 14(2), Regulation (EU) 2024/2847
Two of the three run from "the manufacturer becoming aware"; the third runs from a fix being available, which is a different event.
"Actively exploited" is defined. Art. 3(42): a vulnerability "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". A line in a scanner report is a vulnerability; it becomes an actively exploited one when there is reliable evidence of exploitation. The draft guidance's para 210 adds that, unlike vulnerability handling, reporting continues after a product's support period ends.
The guidance is a draft. The cover Communication, C(2026) 5252 final of 27 July 2026, says the annex "will be formally adopted by the Commission at a later date, when all language versions are available. It is only from that moment that it will apply." No date is given. What follows is the Commission's reading as it stands; para 211 says its purpose is to help manufacturers "determine the moment when the applicable reporting deadlines start".
Para 213 puts that moment after an assessment:
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 […] >Draft guidance, annex para 213, p. 74
Para 212 aligns that reading with recital 31 of Implementing Regulation (EU) 2024/2690 and Section II(A) of Guidelines 9/2022 on personal data breach notification, so the NIS2 and GDPR readings carry over.
Then the split the lede opened with:
By contrast, 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 (either because none had yet occurred or because the manufacturer had not become aware of it). If, 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. >Draft guidance, annex para 217, pp. 75–76
Para 218 adds that a third-party vulnerability that "cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable)" is outside mandatory reporting; the Part II handling duties still apply, on their own timetable. Put the paragraphs together and the question a manufacturer has to be able to answer is when its own checks surfaced what: the assessment that ends in awareness starts with whatever surfaced the suspicious event.
The duties that read as "run your checks" sit in Art. 13 and Annex I Part II, and they apply from 11 December 2027 (Art. 71(2), first sentence). For products placed on the market before that date, Art. 69(2) makes them apply "only if, from that date, those products are subject to a substantial modification". The draft guidance's para 210 states the pre-2027 exclusion without that qualifier; the Official Journal text binds, so I cite Art. 69(2) for the rule. Nothing in this section is in force on 11 September 2026.
Art. 13(7) requires manufacturers to "systematically document, in a manner that is proportionate to the nature and the cybersecurity risks, relevant cybersecurity aspects concerning the products with digital elements, including vulnerabilities of which they become aware". Art. 13(8) requires vulnerabilities to be handled "for the support period" in line with Part II of Annex I, whose point (3) reads in full:
(3) apply effective and regular tests and reviews of the security of the product with digital elements; >Annex I, Part II, point (3), Regulation (EU) 2024/2847
"Regular" is the word a scanner-on-cron team will read as "weekly". The draft guidance reads it differently:
Applying regular tests does not require the mechanical repetition, at fixed intervals, of an unchanged test campaign. It means regularly reviewing whether new input, such as newly identified threats or newly discovered vulnerabilities, requires the existing tests to be updated, and executing tests accordingly. >Draft guidance, annex para 238, p. 80
Para 239 makes frequency and depth proportionate to the product's risk profile and its evolution over time. My reading: "regular" is a duty to review when the input changes, and the artefact that demonstrates it is one that can say when it was produced and how long it was meant to stand. An undated one can say neither.
Suppose a dependency scan ran on a Tuesday, was exported as a PDF and dropped into an evidence folder. It proves that a named check ran on that date, with the scanner version and advisory database of that date, and reported what it reported. That is the whole content, and it is useful: it dates what your own checks had surfaced by that Tuesday.
Three things are outside what it proves. Exploitation: Art. 3(42) needs reliable evidence that a malicious actor exploited the vulnerability, and a finding on its own is not that evidence. Reachability: para 218's test for whether a component's vulnerability is in your product at all. The interval since: whether the check ran again on Wednesday, whether the advisory data changed, whether the next run still found it. The folder holds a file, the file's modification time is the upload, and the run date is somewhere in the body if the tool printed it. The value of a scan artefact is exactly its date and the window it was meant to cover, and one undated PDF answers neither half of para 217's question.
None of this is in the Regulation or the draft guidance; neither says a word about scan outputs. What follows is my derivation.
The first property is a production date: the moment the check ran, recorded on the artefact itself, separate from the moment someone uploaded it.
The second is a freshness window, a date after which the artefact stops counting. Para 238 makes "regular" a review-when-input-changes duty, so the window is a ceiling on how stale a result may get; the run interval underneath it is whatever the risk profile justifies (para 239).
The third is a replacement rule, decided and written down: either the newest result supersedes the previous one, or a history is kept. Both are defensible; the second is the retention question, which this post does not solve.
The fourth is a secret gate that runs before the artefact leaves the build environment. Microsoft Security Research's write-up of the ChainDrop supply-chain compromise across more than 400 npm packages, published 4 August 2026, describes a payload that ran from a preinstall hook. Because "npm runs preinstall scripts before installation completes", it could execute "on developer workstations and build runners before application tests or conventional security checks began". On CI/CD systems, the write-up says, it stays in the running job and "collects credentials from local files, environment variables, command-line tools, and GitHub Actions runner memory". An artefact assembled on a runner carries the runner's environment if the command prints it, and an evidence store is one more place a credential can sit, usually off the list of places anyone rotates from.
| Property | Question it answers | What breaks without it |
|---|---|---|
| Production date | When did our own check surface this? (Art. 14(2); para 217) | The earliest date you can show is the upload date. |
| Freshness window | Is this result still meant to stand? (para 238) | Last year's result and last week's look the same in the folder. |
| Replacement rule | Which file is current, and is a history kept? (Art. 13(7); Art. 13(13) is the other clock) | The folder accumulates and nobody can say which file counts. |
| Secret gate | Did the artefact leave the runner clean? (ChainDrop) | A credential rides inside a report into a store nobody rotates from. |
One way to give a recurring check those four properties is the CLI devguard publishes to npm as @devguardch/cli, which calls itself an evidence courier. devguard evidence push runs when your CI or cron invokes it, makes one pass over the collectors declared in devguard.yml, and exits; it has no schedule of its own. Each collector is a command you already run, or a scanner already installed on the runner (Trivy, osv-scanner, grype or npm audit); the CLI bundles none.
Before any collector runs it checks three things, all or nothing: the key is valid, the key's account is a member of the organisation, and every evidence number in the file resolves. A missing record stops the run; the CLI never creates one.
Each pushed file is stamped with the moment it was produced and the end of its freshness window, 30 days unless the collector sets another duration or never, which means no window and no entry on the Deadlines page. The replacement rule is newest supersedes, per collector, with no history; the July post on retention and currency covers that rule and the two dates on a record. The secret gate runs after the command and before any upload, on a dry run too. It reads text output only (binary artefacts are skipped) and matches against a small, deliberately high-precision pattern set: cloud keys, private-key headers, well-known token formats and high-entropy password-like values. A hit blocks that collector's upload, the other collectors continue, and the run exits non-zero; a per-collector setting or --allow-secrets overrides it.
When a window lapses, the file appears under "Automated Evidence" on Deadlines. The people in the evidence's owner role, if it has any, are notified in-app, and by email where their deadline emails are on. That notification comes from the app's own deadline scan, so the CLI still has no scheduler. A push changes nothing else: control coverage, the evidence's status and its review date are untouched.
[screenshot: evidence detail, a file badged Automated with its collector name]
The key the courier authenticates with is bound to the account that created it. It acts in every organisation that account belongs to, with that account's role in each; there is no read-only key and no key limited to one organisation. A CI secret holding it is therefore a full credential for each of those organisations, which is the class of credential the ChainDrop paragraph is about. Only owners and admins can push. A member's key passes the preflight, which checks membership rather than role. It is refused at the first upload, after the collectors have already run. On your own machine, devguard login keeps the key in a home-directory file only you can read. And the limit from July: a current scan solves document currency and nothing about retention; Art. 13(13)'s ten years belong to the other post.
Put a production date and a freshness window on every artefact a recurring check produces. Decide in writing whether the newest result supersedes or a history is kept, and which of the two clocks that decision serves. Keep secrets out of the artefact before it leaves the runner. Do those three and the output of a recurring check can show, for any day, what your own checks had surfaced by then; whether there was reliable evidence of exploitation was always going to need a person and an assessment.
The records the courier feeds are described on devguard's evidence page.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.