ENISA Reporting — Obligation Matrix

The obligation matrix is the source of truth for which fields are required at which stage. It is versioned reference data (current version cra-2026.1): an authoritative copy lives in the crate, is mirrored to the database, and drives validation. Fetch it at runtime from GET /api/v1/enisa/obligations or the obligations GraphQL field.

Codes

Code	Meaning	Enforced?
X	Obligatory — must be present at this stage	Yes — 422 if missing
C	Copied — carried forward from the previous step (or updated)	Satisfied by carry-forward
O	Optional	No
I	Obligatory if such information is available	Advisory (cannot be mechanically enforced)
A	Automated — server-set, not visible to the submitter	Never sent by the client

Only X is a hard requirement, and the set of X fields is stage-specific — fields that were obligatory at 24h become C (carried forward) at later stages, so each stage’s X fields are genuinely new content.

Common fields (both notification types)

#	Field	24h	72h	Final
1	Notification type (vulnerability / incident)	X	C	C
2	Notification level (stage)	X	X	X
3	Reporting time — 24h	A	A	A
4	Reporting time — 72h	A	A	A
5	Reporting time — final	A	A	A
6	Reporter	A	A	A
7	Manufacturer / OSS steward name	X	C	C
8	Product	X	C	C
9	Product type (default / important / critical)	O	C	C
10	Product category (CRA Annex III/IV)	O	C	C
11	Member States where available	I	C	C
12	Title	X	C	C

Vulnerability fields

#	Field	24h	72h	Final
v13	CVE ID	O	C	C
v14	EUVD ID	O	C	C
v16	General nature of the vulnerability	O	X	C
v17	General nature of the exploit	O	X	C
v18	Corrective / mitigating measures taken	O	X	C
v19	Corrective / mitigating measures users can take	O	X	C
v20	Considered sensitivity of information	O	I	C
v21	Date corrective measure became available	O	O	X
v23	Severity of the vulnerability	O	O	X
v24	Impact of the vulnerability	O	O	X
v25	Malicious actor exploiting the vulnerability	O	O	I
v26	Details of the security update / corrective measures	O	O	X

The source table’s section headers (v15 “general information”, v22 “full description”) are represented by their sub-fields above.

Incident fields

#	Field	24h	72h	Final
i13	Incident suspected to be caused by unlawful/malicious acts	X	C	C
i14	General information about the nature of the incident	O	X	C
i15	Date/time the incident was detected	O	X	C
i16	Date/time the incident occurred	O	X	C
i17	Initial assessment of the incident	O	X	C
i18	Corrective / mitigating measures taken	O	X	C
i19	Corrective / mitigating measures users can take	O	X	C
i20	Considered sensitivity of information	O	I	C
i21	Severity of the incident	O	O	X
i23	Impact of the incident	O	O	X
i24	Type of threat / root cause	O	O	X
i25	Applied and ongoing mitigation measures	O	O	X

Field identifiers in the API

The field_id values above (7, v13, i14, …) are exactly what appear in validation violations and in the obligations response, so a client can map a violation straight back to the field it must supply. Discriminator/automated fields (1–6) have no submitter-supplied input.