Annex I Part II — the vulnerability handling process

The eight duties

Annex I Part II is short and unforgiving. For the entire support period, the manufacturer must:

1. Identify and document vulnerabilities and components, including an SBOM.
2. Address and remediate vulnerabilities without delay, including by providing free security updates.
3. Apply effective and regular tests and reviews of the security of the product.
4. Once a security update is available, publicly disclose information about fixed vulnerabilities: description, impact, severity, and clear guidance for users.
5. Put in place and enforce a coordinated vulnerability disclosure policy.
6. Take measures to facilitate the sharing of information about potential vulnerabilities, including a contact address for reporting.
7. Provide mechanisms to securely distribute updates in a timely manner.
8. Ensure security patches are disseminated without delay and free of charge, with advisory messages to users.

Turning that into an operating process

Intake. A single monitored channel: security@yourdomain, published in the product documentation and on a /security page, ideally with security.txt. Acknowledge receipt fast — a 72-hour target is a reasonable internal SLA.

Triage. Reproduce, score with CVSS, and decide reachability against your actual firmware configuration. Record the decision even when the answer is "not affected"; that record is your VEX source and your evidence.

Remediation. Fix, build, sign, and release through the security channel. Track time-to-fix as a metric — "without delay" is judged against your own demonstrated capability.

Disclosure. Publish an advisory when the fix is available. Include affected versions, CVE where assigned, severity, workaround, and the fixed version. Request a CVE ID: as a manufacturer you can become a CNA, or go through a root CNA.

Reporting. Separately from disclosure, if the vulnerability is actively exploited, the ENISA reporting clock starts — see the reporting lesson.

Coordinated disclosure policy

Your published policy should state: scope (which products and versions), how to report, what you commit to (acknowledgement time, status updates, target fix window), your safe-harbour statement for good-faith research, whether you credit finders, and your embargo expectations. Keep it short and honest — a policy promising 24-hour fixes you cannot deliver is worse than one promising 90 days you always meet.

Testing and review

Requirement 3 asks for regular testing, not a single pre-launch pentest. A defensible embedded programme layers:

• SAST and compiler hardening in CI on every commit.
• Dependency and SBOM scanning on every build.
• Protocol fuzzing of every externally reachable parser — this is where embedded CVEs actually live.
• Hardware-level review: debug port state, flash readout protection, glitch resistance proportionate to risk.
• Periodic third-party penetration testing, and always after a substantial change.

Keep the reports. Evidence of regular testing is part of the technical documentation.