EU Cyber Resilience Act Guide for Cybersecurity Product Vendors

Cybersecurity products — including hardware and software firewalls, IDS/IPS systems, endpoint detection and response (EDR) platforms, VPN gateways, security information and event management (SIEM) systems, privileged access management tools, and vulnerability management platforms — are explicitly categorised in Annex III as Important Class I or Critical Class II depending on their function and deployment context.

Products designed to protect critical infrastructure are likely to be assessed as Critical Class II, particularly if they manage security for multiple organisations (e.g., managed security service provider tooling) or are deployed to protect essential services. Vendors must assess each product line independently and document the classification rationale. A standalone endpoint antivirus product for consumers may be Class I; a SIEM platform deployed in national critical infrastructure may be Class II. The distinction has significant conformity assessment implications.

The CRA's requirement that cybersecurity products themselves be secure is the most pointed form of regulatory accountability this sector faces. Annex I Part I obligations applied to security products include:

• No unnecessary attack surface: A firewall or EDR agent must not introduce new vulnerabilities through its own management interfaces, update channels, or agent communications.
• Authenticated update mechanisms: Security product updates — including threat intelligence feed updates and signature databases — must be cryptographically authenticated.
• Secure management interfaces: All remote management APIs must require strong authentication and use current TLS configurations.
• Least privilege: Security agents running with elevated privileges (kernel-level EDR agents, network capture components) must be designed with least privilege and documented process isolation.
• SBOM maintenance: Given that security products often embed extensive open-source libraries and third-party components, SBOM maintenance is both a CRA obligation and a practical necessity for managing exposure to upstream vulnerabilities like those affecting log4j or OpenSSL.

Security product vendors who have experienced significant incidents from their own product vulnerabilities (e.g., exploitation of management interfaces) face reputational and legal risk that makes CRA compliance an existential priority.

Security product vendors are expected to operate CVD programmes that are exemplary by industry standards. Article 13 formalises this expectation into a legal obligation, but the reputational stakes for security vendors make non-compliance particularly damaging.

• Be publicly accessible and cover all products with digital elements
• Not require NDAs for initial vulnerability reports (a practice some vendors have used historically)
• Define clear, reasonable acknowledgement timelines and embargo periods
• Include a commitment to CVE assignment and public advisory publication

Security vendors should go beyond the Article 13 minimum and publish advisories in CSAF 2.0 format with VEX (Vulnerability Exploitability eXchange) statements, enabling automated downstream assessment by their customers' vulnerability management tools. Customers who deploy security products in regulated environments will increasingly require CSAF/VEX data as a condition of procurement. CVD Portal generates CSAF 2.0 records and VEX statements for each resolved vulnerability.

Actively exploited vulnerabilities in security products are among the most consequential cybersecurity events, as they directly compromise the protection of the vendors' customers. ENISA and national CSIRTs will treat Article 14 reports from security product vendors with the highest urgency.

• 24-hour initial ENISA notification: Triggered immediately upon confirmation of active exploitation, including any available information about the exploit methodology.
• Simultaneous customer communication: The 24-hour ENISA notification should be accompanied by direct customer notification, particularly where customer systems are at immediate risk.
• 72-hour technical report: Full vulnerability details, affected versions, available mitigations, and patch timeline.
• 30-day final report: Confirmation of patch availability, evidence of deployment, and post-incident analysis.

Security vendors should also consider coordinating with national CSIRTs and ENISA's CERT-EU to support incident response for affected customers in parallel with the formal reporting process.

Class I security products require third-party assessment; Class II products require assessment by a notified body using one of the more rigorous procedures under Annex VIII. For vendors with Class II products, the assessment process is more intensive and must verify that the product meets the higher security baseline required for critical infrastructure protection.

Cybersecurity vendors should leverage existing security certifications — Common Criteria (ISO/IEC 15408) evaluations, FIPS 140-3 certifications, and cloud security certifications like CSA STAR — as supporting evidence in CRA assessments. Common Criteria Protection Profiles that align with CRA Annex I requirements may eventually be recognised as providing presumption of conformity, though the harmonised standards process is not yet complete.

Vendors should budget 12–18 months for Class II assessment processes and begin notified body engagement immediately if they have not already done so. Class II assessment capacity across European notified bodies is extremely limited.