In this article, we examine the draft of the vertical standard CRA EN 304 636, its scope, requirements and how to use this standard to achieve compliance.
ETSI EN 304 636 is a vertical cybersecurity standard currently under development to support compliance with the Cyber Resilience Act (CRA) for firewalls, intrusion detection systems (IDS), and intrusion prevention systems (IPS). The standard defines cybersecurity requirements and assessment criteria specifically tailored to products whose primary purpose is to inspect, monitor, detect, prevent, or control network traffic for security purposes. It translates the broad essential cybersecurity requirements of the CRA into technical controls that can be implemented, assessed, and demonstrated by manufacturers.
Like other CRA vertical standards, ETSI EN 304 636 follows the European standardization model:
Once harmonized, compliance with ETSI EN 304 636 is expected to provide a presumption of conformity with the applicable CRA essential requirements for firewalls, IDS, and IPS products.
Firewalls
Products that protect networks or systems by controlling and restricting data communications.
Intrusion Detection Systems (IDS)
Products that monitor traffic and identify malicious or suspicious activity.
Intrusion Prevention Systems (IPS)
Products that actively respond to detected threats by blocking or mitigating malicious activity.
The standard applies regardless of whether the product is delivered as:
While ETSI EN 304 636 applies to products whose primary purpose is to inspect, monitor, detect, prevent, or control network traffic for cybersecurity purposes, several categories of products fall outside its scope.
In addition, ETSI EN 304 636 does not assess detection accuracy, threat detection rates, signature coverage, false-positive and false-negative performance, the quality of threat intelligence feeds, security policy effectiveness, or operational effectiveness in a particular customer environment.
Therefore, a firewall, IDS, or IPS may fully comply with ETSI EN 304 636 while still requiring proper deployment, rule tuning, operational monitoring, and security management to achieve effective protection in practice.
Product Context
This section defines:
Manufacturers must first define their product architecture before determining which requirements apply.
Technical Requirements
The standard establishes cybersecurity requirements covering:
Compliance Assessment
Clause 6 specifies how compliance is evaluated through:
| Reference | Description |
|---|---|
| No Known Exploitable Vulnerabilities | Manufacturers must maintain a machine-readable Software Bill of Materials (SBOM) and ensure that products do not contain known exploitable vulnerabilities when placed on the market. Third-party components and dependencies should be continuously assessed against vulnerability databases and security advisories. |
| Secure by Default Configuration | Products must be delivered in a secure state, with only necessary interfaces, services, and protocols enabled. Security controls should be activated by default, and diagnostic or maintenance interfaces should remain disabled unless explicitly enabled and adequately protected. |
| Secure Updates | Products must support authenticated and integrity-protected update mechanisms. Manufacturers should provide secure update delivery, audit logging of update activities, validation of update authenticity, and mechanisms to recover safely from failed update attempts. |
| Authentication and Access Control | The standard requires strong authentication and authorization mechanisms, including user authentication, unique credentials, password protection policies, session management, role-based authorization, privilege separation, and secure administration protocols. |
| Data Protection | Manufacturers are expected to protect credentials, cryptographic material, configuration data, logs, and management communications. Protection applies both to data at rest and data in transit, ensuring confidentiality, integrity, and controlled access. |
| System Integrity | Products must implement mechanisms to ensure the integrity of firmware, software, and operational components. Key expectations include secure boot, trusted boot chains, integrity verification, protection of recovery functions, and generation of integrity-related audit events. |
| Availability and Fail-Secure Behaviour | Products must remain secure during abnormal conditions and attack scenarios. Controls include rate limiting, connection throttling, Denial-of-Service (DoS) resilience, automatic recovery capabilities, and fail-secure handling of traffic when inspection cannot be completed. |
| Monitoring and Logging | Security-relevant activities must be recorded through comprehensive audit logs. Logged events should include authentication attempts, configuration changes, update operations, system events, security incidents, and unauthorized actions. |
| Signature and Threat Intelligence Management | Products using signature-based detection or threat intelligence feeds must protect signature databases against tampering, rollback attacks, corruption, and unauthorized modifications. Secure validation and update mechanisms must be implemented. |
| Remote Data Processing Solutions (RDPS) | Products using signature-based detection or threat intelligence feeds must protect signature databases against tampering, rollback attacks, corruption, and unauthorized modifications. Secure validation and update mechanisms must be implemented. |
ETSI EN 304 636 places significant emphasis on the ability of firewall, IDS, and IPS products to identify, manage, and remediate vulnerabilities throughout their operational lifecycle. Conformity in this area is not limited to the existence of a vulnerability management process; manufacturers must demonstrate that vulnerabilities are systematically monitored, assessed, addressed, and communicated in a manner consistent with the product's cybersecurity objectives.
Manufacturers should establish and maintain a documented vulnerability handling process covering the receipt, analysis, prioritization, remediation, and disclosure of security vulnerabilities. The process should include clearly defined responsibilities, decision-making criteria, and mechanisms for tracking vulnerabilities from identification through resolution. Evidence should demonstrate that vulnerability management activities are integrated into both product development and post-market maintenance practices.
A compliant product lifecycle should include continuous monitoring of potential sources of security vulnerabilities, including internally developed components, third-party software, open-source dependencies, and supplied security services. Manufacturers should be able to assess the potential impact of identified vulnerabilities on product security functions and determine the appropriate remediation actions according to risk.
Particular attention should be given to components identified within the product's Software Bill of Materials (SBOM), enabling the manufacturer to rapidly determine whether newly disclosed vulnerabilities affect the evaluated product.
Conformity requires the capability to deliver corrective security updates when vulnerabilities are identified. Update mechanisms should ensure the authenticity and integrity of distributed software, firmware, configuration packages, and other security-relevant components. Manufacturers should demonstrate that security patches can be deployed in a controlled manner while minimizing the risk of unauthorized modification, downgrade attacks, or installation failures.
Where vulnerabilities cannot be immediately remediated, manufacturers should be able to provide documented mitigation measures, compensating controls, or operational guidance to reduce associated risks until a permanent fix becomes available.
Manufacturers should maintain procedures for receiving reports from external researchers, customers, and other stakeholders. Publicly available reporting channels, coordinated vulnerability disclosure practices, and transparent security communications contribute to the effectiveness of the overall vulnerability handling framework.
Assessment evidence may include published vulnerability handling policies, security advisories, remediation records, and examples demonstrating how previously identified vulnerabilities were managed and communicated to affected users.
During conformity assessment, evaluators are likely to review documented vulnerability management procedures, vulnerability analysis records, remediation workflows, security update mechanisms, and associated technical evidence. Manufacturers should be prepared to demonstrate traceability between identified vulnerabilities, risk assessments, corrective actions, and released updates.
The evaluation may also consider how the organization maintains awareness of vulnerabilities affecting third-party components, verifies the effectiveness of remediation measures, and ensures that security-relevant updates can be safely distributed throughout the supported lifetime of the product.
Conformity with vulnerability handling requirements demonstrates that the manufacturer has implemented a structured and repeatable approach to managing security weaknesses throughout the product lifecycle. It provides confidence that vulnerabilities can be identified, assessed, communicated, and remediated through controlled processes supported by appropriate technical and organizational measures. However, conformity does not guarantee the absence of vulnerabilities. Rather, it demonstrates the manufacturer's capability to respond effectively when vulnerabilities are discovered and to maintain the security posture of the product over time.
ETSI EN 304 636 follows a risk-based approach, meaning requirements depend on the product's functionality, deployment model, and external dependencies. To achieve compliance, manufacturers should:
Product teams
Responsible for implementing the technical controls required by the standard, including secure-by-design practices, secure updates, SBOM management, secure boot, attack surface reduction, and technical documentation.
Security teams
Lead threat modelling, vulnerability management, cryptographic reviews, security testing, monitoring capabilities, and preparation of assessment evidence.
Legal and compliance teams
Ensure alignment with CRA requirements, maintain traceability between regulatory obligations and technical controls, review compliance documentation, and support conformity assessment activities.
Customers and users
Benefit from products that provide secure default configurations, strong access controls, secure updates, data protection, integrity protection, auditability, and improved long-term cybersecurity maintenance. Compliance increases confidence in product security but does not replace proper deployment and operational security practices.
Applus+ uses first-party and third-party cookies for analytical purposes and to show you personalized advertising based on a profile drawn up based on your browsing habits (eg. visited websites). You can accept all cookies by pressing the "Accept" button or configure or reject their use. Consult our Cookies Policy for more information.
They allow the operation of the website, loading media content and its security. See the cookies we store in our Cookies Policy.
They allow us to know how you interact with the website, the number of visits in the different sections and to create statistics to improve our business practices. See the cookies we store in our Cookies Policy.
Based on your behavior on the website (where you click, how long you browse, etc.) we establish parameters and a profile for you to display ads that correspond to your interests. See the cookies we store in our Cookies Policy.