Security software often runs with high privilege and is trusted to inspect, redirect, block or interpret hostile data. CRA implementation should therefore address the security of the security mechanism itself: privileged sensors and drivers, detection engines, signature and rule feeds, policy administration, quarantine, telemetry, cloud analysis, automatic updates, tamper protection and failure behavior. Classification is function-specific, and Class II products such as firewalls and IDS or IPS follow stricter Article 32 conformity routes than ordinary Class I products.
Security Software Is Not One Annex III Category
The term security software covers many products, but the CRA classifies defined core functionalities. Annex III Class I includes anti-malware software, VPN products, network management systems and SIEM systems. Annex III Class II includes firewalls and intrusion detection and prevention systems. A manufacturer should map the product to the technical description that matches what the software is fundamentally designed to do.
Anti-Malware Software Is Class I
Commission Implementing Regulation (EU) 2025/2392 describes the Class I anti-malware category as software that detects or searches for malicious software or code, or removes or quarantines it, to maintain device integrity, confidentiality or availability. The category includes real-time and manual detection and products whose core functionality is searching, removing or quarantining malware. Endpoint products should document whether this is truly their core functionality.
VPN Products Are Class I
The Class I VPN category covers products that establish an encrypted logical tunnel using resources of a physical or virtual network. The implementing regulation includes VPN clients, VPN servers and VPN gateways. The security case should therefore address tunnel authentication, key establishment, cryptographic configuration, routing changes, DNS handling, kill-switch or failure behavior where provided, update integrity and privileged network-interface control.
SIEM and Network Management Systems Are Class I for Different Reasons
Network management systems are described as products that monitor connected network elements and control their network operation and configuration. SIEM systems collect data from multiple sources, analyse and correlate it and present actionable security information. These are distinct core functions. A security platform containing both capabilities should document which function defines the product and whether multiple technical descriptions genuinely apply.
Firewalls and IDS or IPS Products Are Class II
Annex III Class II includes firewalls and intrusion detection and prevention systems. The implementing regulation describes firewalls as products that protect a connected network or system from unauthorized access by monitoring and restricting traffic, and distinguishes intrusion detection from intrusion prevention. Because Class II uses the Article 32(3) conformity routes, classification has direct assessment consequences for these products.
Core Functionality Prevents Classification by Feature Checklist
The implementing regulation explains that the ability to perform a listed function does not by itself place a product in that category when the product's core functionality is different. It gives SOAR software as an example: although SOAR can gather and analyse security data, it is generally not treated as SIEM when its core functionality differs. Security suites should therefore document their architectural and market function rather than classify every included feature independently.
Privileged Sensors and Drivers Need Strong Isolation
Endpoint security products may install kernel drivers, system extensions, browser integrations, packet filters or privileged background services. Those components expand the product's authority over the host and can become high-impact attack surfaces. The risk assessment should identify privileges, trust boundaries, IPC mechanisms, update paths and what happens if a lower-privilege component attempts to control the privileged sensor.
Detection Content Is Part of the Security Supply Chain
Security products often update malware signatures, detection rules, reputation data, machine-learning models, blocklists or threat intelligence much more frequently than the executable software itself. Manufacturers should protect authenticity and integrity of those feeds, define rollback and revocation behavior, and assess the security impact of malformed or compromised detection content. The evidence should distinguish content updates from executable security updates while documenting both paths.
Quarantine and Blocking Functions Need Safe Failure Modes
Anti-malware, firewall and prevention products can delete, quarantine, block or redirect data and traffic. A false positive or corrupted policy can therefore affect availability as well as security. Product-specific testing should examine authorization for release or override actions, recovery from incorrect blocking, auditability and behavior when detection engines or cloud services are unavailable.
Cloud Analysis Changes the Product Trust Boundary
Modern security software may send hashes, telemetry, suspicious files, packet metadata or detection events to manufacturer-controlled cloud systems. The product security architecture should document what is transmitted, how endpoints authenticate the service, how commands or verdicts are authorized, what data is trusted on return and how the product behaves when cloud analysis is unavailable. Where the remote service meets the CRA remote-data-processing conditions, it should be included in the product boundary.
Tamper Protection Must Not Create an Unrecoverable Product
Security software often resists process termination, configuration changes or removal so attackers cannot disable protection. Those controls should distinguish malicious tampering from legitimate administration and recovery. Manufacturers should test authorized maintenance, uninstall and break-glass procedures so that tamper protection does not prevent security updates, incident recovery or removal of a malfunctioning component.
Keep Classification and Detection Evidence Versioned
A security-software technical file should preserve the product's core-functionality classification, privileged architecture, detection and policy components, cloud dependencies, update mechanisms, supported operating systems and test evidence for the release placed on the market. Because security behavior can change through rules, signatures and models without a full software release, the manufacturer should also be able to identify which security-content versions supported material test and incident decisions.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.