Incident reporting
Availability: CRA evidence cases and deadline tracking require the optional Compliance & Evidence module.
Meshanics records the operational timeline for CRA Article 14 cases. It keeps a detection signal separate from the statutory awareness trigger, calculates a deadline only when its trigger exists, and retains each regulator submission as an immutable revision.
The platform manages the clock and the evidence record. It does not decide whether an event is legally reportable and it does not submit to the ENISA single reporting platform. Those decisions and submissions remain the manufacturer's responsibility.
1. Open an assessment case
Open a case when a signal may describe either:
- an actively exploited vulnerability in the product; or
- a severe incident affecting the security of the product.
Record the signal source, detection time, affected scope, and any linked artifact. Detection can come from monitoring, a customer, a supplier, a CSIRT, or another source. Detection alone does not start a reporting clock.
For an existing vulnerability-watch finding, choose Select from vulnerability watch, select the affected artifact, and then select its CVE or vulnerability finding. The console fills the case title, affected artifact, component, version, severity, detection time, source, and upstream summary from the recorded finding. These fields are copied and linked by the server, rather than accepted as editable duplicates.
Creating the case and marking the exact finding as promoted happen in one database transaction. A finding therefore cannot appear promoted without its linked assessment case, and two cases cannot accidentally promote the same finding. Promotion records the signal for assessment. It does not automatically assert active exploitation or statutory awareness.
Use Record another signal only when the source is outside vulnerability watch, such as a customer, CSIRT, supplier, or monitoring system. That path keeps the manual fields needed to record the external facts.
2. Conclude the initial assessment
Every case records when its initial assessment started. The assessment has two possible conclusions:
- reportable confirms Article 14 awareness and starts the applicable clocks;
- not reportable records the decision time and a required rationale, then dismisses the signal without starting a statutory clock.
The assessment start and each conclusion are append-only case evidence. A not-reportable conclusion is not a deletion and remains available in the case download and audit history.
3. Confirm awareness after assessment
Confirm awareness_at only after the initial assessment gives reasonable
certainty that the Article 14 conditions are met. Record the rationale for that
determination. Awareness is a one-time case fact and cannot be silently moved
later.
Confirming awareness starts these clocks:
| Stage | Deadline trigger |
|---|---|
| Early warning | 24 hours after awareness |
| 72-hour notification | 72 hours after awareness |
Before awareness is confirmed, the console shows these stages as awaiting statutory trigger rather than inventing a date from detection.
4. Record progressive regulator submissions
For each reporting stage, record:
- the submission time and destination;
- the regulator or portal reference;
- an acknowledgement reference, when available; and
- the facts included in that revision.
Early information can be incomplete. Later corrections and additional facts are stored as new revisions instead of overwriting the earlier submission. The case view displays the first submission time for deadline performance and the latest references for operational follow-up.
5. Start the correct final-report clock
The final deadline has a different trigger for each case type:
| Case type | Final-report deadline |
|---|---|
| Actively exploited vulnerability | 14 days after a corrective or mitigating measure becomes available |
| Severe incident | One calendar month after the 72-hour notification |
For a vulnerability case, record the measure availability time and a release, advisory, or change reference. For a severe incident, the platform starts the one-calendar-month clock when the first 72-hour submission is recorded.
The final-report stage remains awaiting statutory trigger until the relevant fact exists.
6. Record impacted-user notification
Article 14 also requires a reviewed decision about informing impacted users. Record whether notification is still under review, is planned, is not required, or has been completed. Each revision includes the affected audience and the decision or communication reference. A completed record also requires the notification time.
This is evidence of the manufacturer's decision and delivery process. Meshanics does not send the user communication.
7. Attach supporting case material
You can attach up to ten supporting files to a case, with a 5 MiB limit per file. Record a purpose for each file. Meshanics stores the exact bytes, calculates their SHA-256 digest, and includes the attachment metadata and digest in the downloadable case record.
Attachments are append-only. Downloaded files are always served as attachments with content sniffing disabled. The JSON case record names and verifies the files but does not embed their bytes.
Where managed evidence issuance is configured, Issue case evidence creates a separate sealed package. Before issuance, Meshanics reads every attachment again and verifies both its recorded byte length and SHA-256 digest. The package contains the deterministic case JSON and each verified attachment byte. A missing or changed attachment causes issuance to fail.
8. Close the case
A case can close only after a final-report submission has been recorded. Closing does not delete earlier facts or revisions. Article 14 case records remain available after the product support period ends.
Evidence properties
Case creation, assessment conclusion, awareness, final-deadline triggers, each submission revision, attachments, user-notification revisions, and closure are added to the tenant's hash-chained audit history. Assessment, submission, attachment, and notification revision rows are append-only at the database layer. The direct JSON remains a current preview. Evidence explicitly issued from the case can be sealed, retention locked, and externally witnessed when that deployment capability is configured.
Existing cases created under the older detection-based planning model are labelled legacy dates need review. Confirming awareness moves a legacy case to the current clock model and recalculates only the deadlines whose statutory trigger is known. A case with older completion marks remains labelled for review because the platform cannot invent the missing portal references or stage payloads.