Finding got cheap. The rest of the lifecycle did not. A vulnerability management lifecycle has 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, and 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 the harmonised standard that defines “effective and regular” is citable, so they have to stand on their own merits: The standards slipped, the deadline did 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 re-exposed to a fresh lineage. 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 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)). A decision not to fix is a decision the technical file 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 patches disseminated without delay and free of charge, with advisory information (Annex I Part II(7), (8)); public disclosure of fixed vulnerabilities once an update is available (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 if a finding 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 in force since 11 September 2026 (Article 14). For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident: the same 24-hour and 72-hour steps, and 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 and found sound names the method and the control, 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.
Limits that belong here: we have not shown that a panel finds more real defects than one good reviewer and do not claim it; our seats’ independence is bounded by procedure and not measured; our reviewing bench 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.