Session CRT-20260719 — 19 July 2026

Let’s put the panel directly into the tabletop.

Assume it is 12 September 2026. Our flagship connected product has a confirmed actively exploited vulnerability. The CRA reporting clock is live. We have 24 hours for the early warning and 72 hours for the fuller notification. The question is not whether we can produce a polished disclosure pack — it is whether the draft pack actually satisfies the regulation field by field when facts are incomplete, pressure is high, and exploitation is real.

I want us to resolve three things.

First, Sofia: what does the regulation require in the 24-hour and 72-hour submissions, and where is there no room for interpretation?

Second, Alex and James: which facts can the security team realistically know inside those windows, and which fields are likely to be guesswork unless we redesign the pack now?

Third, Lena, Pierre, and Elena: what does “actively exploited” change — in evidence threshold, business exposure, customer confidence, and external sensitivity?

We are not doing general CRA readiness today. We are deciding whether the current disclosure pack can stand as written, or whether it must be rebuilt before the deadline regime goes live.

What changed here is that the room has moved from “we need a disclosure pack” to “we need an SRP-mapped operating process before the clock starts.” Sofia, Alex, and James all converged on the same hard point: for a confirmed actively exploited vulnerability on 12 September 2026, the CRA/SRP regime is already live, and the timing runs from manufacturer awareness, not from legal comfort, forensic completeness, or executive readiness.

Sofia’s regulatory read is the sharpest constraint: the current generic pack is not enough as written. It needs to be rebuilt field by field around the 24-hour early warning and 72-hour notification expectations, including trigger type, affected product identification, manufacturer or reporter contact, awareness timing, routing basis, and applicable Member State availability where known. Alex added the security reality check: within 24 hours we may know the product, some exploitation evidence, and a cautious vulnerability description, but exact affected versions, impact scope, and root cause may still be provisional. James then translated that into operations: a Word template is the wrong control. We need named owners, evidence gates, approval paths, update tracking, and clear boundaries to avoid both under-reporting and premature over-disclosure.

There are still caveats. We have not fully validated every mandatory SRP field from the final operational portal, and some details appear to be operational expectations rather than independently verified legal text. Also, “confirmed exploitation” is doing a lot of work here. If confirmation is weak, the timing and content decisions become harder; if it is strong, the organization cannot wait for perfect blast-radius analysis.

That is why the next step turns to definition and defensibility. We need Lena to pin down what evidence threshold makes “confirmed actively exploited vulnerability” usable enough to start the 24-hour clock. We need Pierre to test whether leadership’s preferred shortcut — a CRA cover page on the old generic pack — can survive scrutiny. And we need Elena to frame external sensitivity without over-claiming state involvement just because the product is flagship and deployed across Member States.

The practical threshold is now much clearer: the room is not treating “confirmed actively exploited vulnerability” as a demand for perfect attribution or complete incident reconstruction. Lena’s useful line is that the 24-hour clock should start when PSIRT has reliable evidence, at least moderate confidence, that a malicious actor exploited the vulnerable code path in a real system without authorization. That could come from customer forensics, internal telemetry, CERT/CSIRT notice, incident-response artifacts, exploit-chain logs, or malware tied to the product. The important discipline is recording provenance: who saw what, when it was first observed, when PSIRT became aware, affected product and version, confidence level, and whether the evidence shows successful exploitation or only attempted exploitation.

Pierre sharpened the business implication. A generic disclosure pack with a CRA cover sheet is only defensible if the underlying machinery already supports CRA-grade reporting: risk assessment, vulnerability handling, escalation, evidence trail, and customer communications that can feed the 24-hour and 72-hour obligations without improvisation. If the cover page is just cosmetic, it fails both compliance and board-risk logic. For a flagship connected product, the failure mode is not merely “we filed late”; it is regulatory exposure, customer trust damage, delayed shipments, contractual friction, and executive-level scrutiny. His penalty framing also matters: the CRA fine ceiling can become material very quickly for large global manufacturers.

Elena added the necessary restraint. External sensitivity should be anticipated, but not inflated. The pack should be ready to capture government or public-sector exposure, EU Member State availability, signs of coordinated cross-border exploitation, and sanctions or export-control touchpoints around remediation or telemetry sharing. But the first disclosure should not convert “active exploitation” into “state campaign” unless the evidence supports that. Actor naming, campaign clustering, MITRE mapping, victim-count certainty, and geopolitical interpretation should not hold up the initial report.

The open issue is now format and governance: how do we turn these judgments into fields that legal, PSIRT, product, and executives can actually use under time pressure? That is why we go next to Sofia for a field-by-field CRA decision matrix, starting with whether Lena’s moderate-confidence exploitation rule is the right trigger for the clock.

Sofia has now turned the trigger question into something the team can actually operationalize: Lena’s “reliable evidence with at least moderate confidence” standard is not too low, provided it is anchored in actual exploitation of this vulnerability in a real deployed product. That distinction matters. The room is not counting internet scanning, a lab proof of concept, or vague unverified telemetry as enough by itself. But once PSIRT has reliable evidence that the product’s vulnerable code path has been abused in the wild, the CRA 24-hour clock should not wait for full root cause, actor attribution, or complete incident reconstruction.

The field-level implication is also sharper now. For a 24-hour early warning pack to be ready, Sofia is saying several things cannot be missing: the classification that this is an “actively exploited vulnerability,” the affected product or product line and versions if known, the awareness timestamp and basis for awareness, and an evidence summary showing real-world exploitation. Some details can be provisional, especially versions and confidence notes, but the existence of those fields is mandatory. If the team cannot say when it became aware, what product is implicated, why it believes exploitation is real, and who owns that judgment, then the pack is not ready.

There is still an important caveat: this is an operational legal interpretation, not a claim that every future edge case will be obvious. “Moderate confidence” will need disciplined documentation, because the same phrase can be used well or badly. The difference is provenance: what evidence was seen, who assessed it, what was excluded, and why the manufacturer concluded this crossed from suspicion into awareness.

That naturally hands the discussion to James. Sofia has defined the decision matrix; now we need the readiness machinery around it. By 11 September 2026, teams will need named field owners, evidence sources, approval gates, and fallback wording for unknown or provisional details so the organization can file quickly without either overclaiming certainty or freezing while facts are still developing.

James has moved the room from “what should we disclose?” to “can we actually execute the CRA clock under pressure?” That is an important shift. His core point is that readiness for 11 September 2026 is not just a matter of adding CRA language to an existing vulnerability disclosure template. The organization needs an operational workflow that can capture the awareness timestamp, classify the trigger, assign field ownership, preserve evidence, route approvals, and still file something defensible within the 24-hour early warning and 72-hour main notification windows.

The caveat is equally important: James is not claiming we already know every future SRP form field. He explicitly flags that the final official ENISA Single Reporting Platform schema is not in the evidence available here. So the practical recommendation is to map the pack now to the legal milestones and decision points, then update it when SRP testing or final form details become available. In other words, do not wait passively for the final portal fields, but also do not pretend the field schema is already settled.

The readiness checklist James began sketching gives us the operating pattern: each required element needs a field owner, evidence source, approval gate, and fallback wording for unknown or provisional values. That fallback wording matters because the early warning may have to be filed before the team has full root cause, complete exploit confirmation, or final product impact. The tabletop test, then, is not whether the disclosure prose sounds polished; it is whether the organization can make a timely, traceable, legally reviewable submission while clearly marking what is provisional.

That sets up the next challenge very naturally. If CRA readiness depends on field ownership, evidence provenance, approval timing, and provisional-value handling, then the room now has to test whether a generic disclosure pack with a CRA cover page can really carry that load—or whether the pack must be rebuilt field by field before the reporting obligations begin.

Sofia has narrowed the disagreement in a useful way: the problem is not “generic pack versus CRA-branded pack.” The problem is whether the existing evidence actually maps to the CRA reporting duties that start applying through ENISA’s Single Reporting Platform from 11 September 2026. That distinction matters, because it prevents us from overstating the compliance burden. A mature evidence backbone may still be usable if it already shows the product cybersecurity risk assessment, technical documentation, vulnerability-handling process, escalation route, customer communication record, and audit trail.

But Sofia also confirms the harder operational point: a cover page is not enough. For the 12 September 2026 scenario, once the manufacturer becomes aware of active exploitation, the CRA reporting clock is running. The organization then needs a submission layer that is built field-by-field around the 24-hour early warning, 72-hour notification, and final-report expectations. In other words, the reusable evidence pack can remain the backbone, but it must be connected to a live control matrix: required field, source of evidence, owner, timestamp, uncertainty status, approval route, and what can be stated provisionally versus what must wait for validation.

The caveat we should preserve is that Sofia is not saying every future SRP implementation detail is already known or that every generic pack fails. She is saying that defensibility depends on traceability. If the pack cannot rapidly answer the CRA/SRP questions in the format and sequence required, then the organization has not solved the reporting problem; it has only stored documents.

That tees up James’s next task well. We now need to test this revised standard against an actual readiness posture: if the evidence backbone is already strong, but the SRP/CRA submission matrix, owners, timestamps, and provisional-unknown handling are missing, is the organization ready for the September 2026 reporting trigger—or only partially prepared?

James has now put a hard gate around the question: under Sofia’s revised standard, this does not pass as written. The key shift is that a strong internal evidence backbone is no longer being treated as sufficient by itself. The tabletop pass/fail point is the submission layer: can the organization convert incident awareness into an SRP-ready CRA Article 14 early warning within 24 hours, then a fuller 72-hour notification, with each field owned, evidence-linked, timestamped, and approved?

What the room should take from that is the distinction between “we probably have the information somewhere” and “we can safely submit the right information on time.” James is saying the current pack fails if any required or provisional field is just “TBD” without an accountable owner and next-update time; if legal or PSIRT approval is not timestamped; if affected product and version claims are not tied back to SBOM, CMDB, or release records; or if the team cannot show how it decides what is safe to disclose versus what should be withheld to avoid enabling exploitation or over-disclosure.

There is still an important caveat here: we have not validated the actual pack line by line against ENISA’s final operational SRP implementation, nor have we tested a live organization’s workflow under clock pressure. But for tabletop purposes, James gives us a defensible binary standard: mature evidence may reduce rebuild effort, but it does not make the pack CRA-ready unless the reporting workflow, ownership model, timestamps, provisional handling, and approval gates are already explicit.

With no further action queued, we can now move toward synthesis around the practical conclusion: the gap is not primarily documentation volume. It is operational traceability from incident awareness to regulated submission.