Finding got cheap. The rest of the lifecycle did not. A vulnerability management lifecycle has broadly the same stages whatever framework you draw it from: identify candidates, assess which are real and how serious, decide what to do about each, remediate, verify the fix, report to whoever is owed a report, and retain the record.
In our reading the expensive stage used to be the first. Today a scanner, a fuzzer, a review platform or an assistant produces candidates faster than any team can assess them. The lifecycle breaks at the stages that follow, where a fluent candidate has to become a decision someone will later be asked to justify.
This note walks the stages, says what the EU Cyber Resilience Act, Regulation (EU) 2024/2847, asks at each, and says where an independent adversarial review sits. Its weight is in the stages after the first.
Identify: where we do not sell
Candidates come from everywhere: SAST, dependency and SBOM tooling, fuzzers, review platforms, assistants, your own engineers, and outside reporters. An adversarial review produces candidates too (ours have included defects later fixed upstream) but finding is what an engagement yields on the way, not what it is priced on. A practice positioned here would be competing with your scanner on volume.
What the CRA asks here. The manufacturer must identify and document the vulnerabilities and components in the product, including a software bill of materials (Annex I Part II(1)), and must provide a contact address for reporting and facilitate the sharing of information about potential vulnerabilities (Annex I Part II(6)). Those are the manufacturer’s duties; an outside reviewer’s findings feed them and do not discharge them.
Assess (adjudication): from a fluent opinion to an evidence rung
This is the first stage where the lifecycle breaks, because every tool above emits opinions about code with the same fluency whether or not the path is reachable. Assessment is where those opinions are either settled or graded.
Our rule is oracle first. A decidable claim (does this path execute, does the specification permit this value) goes to the thing that can answer it, an execution, a compiler or the specification, before anyone is asked for an opinion on it.
What survives is graded by the evidence rung it actually reached (source trace, compile-proof, test, live reproduction, and for any probabilistic claim a rate with an interval and the per-trial logs) or is marked plausible-only. Severity then follows proof, not a model’s confidence. A finding is not a verdict is the longer treatment.
What the CRA asks here. Effective and regular tests and reviews of the security of the product (Annex I Part II(3)), and, in the technical documentation, reports of the tests carried out to verify conformity of the product and of the vulnerability-handling processes (Annex VII(6)). A report of tests carried out is a report of what was examined, how, and what was established, which is what an evidence-graded record is and a severity-ranked list is not. And for some time yet those reports will be written before a harmonised standard covering “effective and regular” tests and reviews is citable, so they have to stand on their own merits: The standards may slip. The reporting date does not.
Decide (closure): when the tool and the team disagree
The second break. A tool flags a critical; engineering says it is mitigated by the framework; the security team has neither the time to prove it nor the standing to overrule a deadline, and the ticket closes by exhaustion.
Our rules of closure are the ones on the adversarial code review page. A tally never establishes anything. Where reviewers disagree about what the code does, the source decides. Where a rejection rests on “uncertain”, the claim goes to a retained queue with an owner, an expiry and a re-open criterion, and is put to a model family that has not yet reviewed it. The queue exists so that uncertain cannot be quietly converted into accepted risk. What settles a finding is the treatment of the first of those rules, including the case where the thing under review was our own tool.
What the CRA asks here. The manufacturer must, in relation to the risks posed to the product, address and remediate vulnerabilities without delay, including by providing security updates (Annex I Part II(2)), and must put in place and enforce a coordinated vulnerability disclosure policy (Annex I Part II(5)). In our reading, a decision not to fix is a decision the technical documentation will have to explain; a retained-queue entry with an owner and a re-open criterion is that explanation, written at the time.
Remediate and verify
Ours to support, not to own: we can stay through the patches and verify each fix against the finding it targets, at the revision that closed it, recorded as its own result. A fix verified by re-reading is not a fix verified by re-running; the record names the rung the verification itself reached.
What the CRA asks here. Secure distribution of updates, and security updates disseminated without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge, with advisory information (Annex I Part II(7), (8)); public disclosure of fixed vulnerabilities once a security update is available, which the manufacturer may delay, in duly justified cases where it considers the security risks of publication to outweigh the security benefits, until users have had the possibility to apply the patch (Annex I Part II(4)).
Report: where the third party earns its fee
The third break, and the one buyers usually come for. An internal run (however many models, however isolated) produces your own word about your own code. In our experience three of the four parties who will read your record do not accept that: an acquirer’s counsel in diligence, a cyber-insurer’s underwriter, an enterprise customer’s security team.
What they are buying is organisational independence: a record adjudicated and signed by a named person outside your organisation who can be cited, and who withdraws in writing any finding that does not survive. That is the property no team can supply about its own work, and it is the whole of what we sell.
The fourth party, the regulator, is the exception that cuts the other way: it will often take your self-assessment, and then hold you to every record behind it.
What the CRA asks here. Two reporting tracks, both through the single reporting platform and both applicable since 11 September 2026 (Articles 14 and 71(2)).
For an actively exploited vulnerability:
- an early warning within 24 hours of becoming aware;
- a notification within 72 hours;
- a final report no later than 14 days after a corrective or mitigating measure is available.
For a severe incident:
- the same deadlines: an early warning within 24 hours and a notification within 72 hours;
- a final report within one month of the notification.
An external review is not a notification and does not stand in for one; what it can do is make the “what we knew, when, and how we established it” behind a notification a record rather than a reconstruction. Separately, products classed as important (Annex III) or critical (Annex IV) face conformity-assessment procedures under Article 32 that can involve a notified body, which we are not, and which nothing on this page substitutes for.
Retain
Technical documentation and the EU declaration of conformity are kept for at least ten years after the product is placed on the market, or the support period, whichever is longer (Article 13(13)). A record retained for a decade will be read by someone who was not in the room, with more time and less goodwill than anyone who wrote it. Every claim in ours names the evidence rung it reached, every surface examined without a finding names the method and the positive control that showed the method could find what it looked for, every withdrawal is written, because that is the reader it is built for.
One sentence
Tools generate candidates. What we generate is the signed, evidence-graded record that tells your acquirer, your insurer and your regulator what was established about your code, at what rung, what remains uncertain and who is accountable for saying so. Not what is true (no reviewer can promise that) but what was shown, and how.
Corrections
Correction, 7 October 2026. This note said a harmonised standard defines the words “effective and regular”; under Article 27(1) a harmonised standard, once cited in the Official Journal, gives a presumption of conformity with the requirements it covers, so the note now says “covering”. It said the Article 14 reporting tracks were “in force” since 11 September 2026; that is the date Article 14 applies from (Article 71(2)), not when it entered into force, and the note now says “applicable”. It presented the severe-incident early warning as “the same” as for an exploited vulnerability; only the deadlines are the same, and it now says so. Its paraphrases of Annex I Part II(2), (4) and (8) were broader than the provisions: remediation is “in relation to the risks posed”; disclosure follows a security update, not any update, and may be delayed only in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits, and only until users have had the possibility to apply the patch; “free of charge” has an exception for tailor-made products; and point (8) speaks of “security updates”, not patches. They now say so. It stated as a duty our inference that the “technical file” must explain a decision not to fix; that is now marked as our reading and uses the Regulation’s term, technical documentation. It linked a related note under an old title saying the standards “slipped”, which that note does not claim; and it said every framework gives “the same stages”, now “broadly the same”. The summary’s stage list omitted verify, which the body has always listed; it now includes it. There are smaller wording fixes too. Found while translating this note into Dutch and checking it against the Regulation and the sources.
Limits that belong here: we have not shown that a panel finds more real defects than one good reviewer and do not claim it; the independence of our AI reviewers is bounded by procedure and not measured; our review team is two people; we are part of a group that builds payment and custody infrastructure and disclose that in writing before any engagement; we are not a notified body and nothing here is legal advice. Regulation references are to Regulation (EU) 2024/2847, checked against the published text before this note went live; the lifecycle reading and the claim about which stage used to be expensive are ours. If a reference is wrong we correct it here, in writing.