The legal person that markets the product under its own name or trademark—not a reseller, hosting provider or component supplier unless that party is the legal manufacturer. The SRP normally fills this from registration.

List the EU countries where the affected product has been made available on the market, based on current sales or distribution information. This is not limited to countries with a confirmed affected customer. The SRP uses the list to identify concerned CSIRTs.

Use the official commercial or technical name used in product documentation.

Include releases, builds, models or firmware revisions. State an exact range where possible.

This is the product's CRA regulatory classification, not the severity of this incident. Default means its core functionality is not listed in Annex III or IV; Important means it matches Annex III; Critical means it matches Annex IV. Select Not determined if classification work is unfinished.

Only Important products use Class I or Class II. Choose the class assigned by the applicable Annex III category; Class II has stricter conformity-assessment treatment. Do not derive the class from CVSS, incident severity or your own risk rating. Select Not applicable for Default or Critical products.

Enter the exact Annex III or IV category that matches the product's core functionality, using the official technical descriptions. A marketing label alone is not enough. Leave blank if classification has not been completed.

Choose Yes only when the manufacturer's declared support period for this product has ended. This is not asking whether one old version is unsupported or whether a patch is currently unavailable; it supports notifying users through the product's interface or another direct interaction method.

Optional. Name the software or hardware component and version, when known.

A short name that identifies the affected product and issue. Avoid unnecessary confidential detail.

Confirmed facts, affected product or version, known impact and current mitigation status.

0/4000

How exploitation or compromise reaches the product—for example an internet-facing API, local account, malicious file, update channel or required user action. State the known path without unsupported assumptions.

This timestamp starts the reporting clock. Record when the manufacturer first had supported information indicating active exploitation—not when root-cause analysis or attribution was completed. Use the best supported estimate and mark uncertainty in the description.

Optional. Enter the official identifier only if one has been assigned.

Optional. Enter the official ENISA European Vulnerability Database identifier, if assigned.

Describe the affected function, required access and observed exploitation behaviour. Do not add unverified attribution.

0/4000

Required in the final report if known. State when attribution is unknown or unconfirmed.

Choose Yes only when the remediation plan supports that expectation.

Optional. Give concrete steps users can take now and state operational limitations.

0/4000

Identify the particular submitted detail that needs restricted handling and the harm that premature or wider disclosure could cause. This is not a general 'confidential' label and is separate from a Particular Exceptional Circumstances request.

0/255

Actions already completed: containment, configuration changes, withdrawal, credential rotation or monitoring.

0/2000

Prioritise the effective fix, then temporary workarounds and their limitations.

0/4000

Record when an effective fix, workaround or user guidance was actually available, not when it was merely planned or entered internal testing. The AEV final-report deadline is calculated from this point.

Optional context that would help the national Computer Security Incident Response Team designated to coordinate this notification.

0/2000