CRA for professional security systems: video, access control and alarms

Networked security systems and the scope of the CRA

IP cameras, network video recorders (NVR), video management software (VMS), access control readers, door controllers and intrusion and fire alarm control panels exchange data with other devices and monitoring centres via Ethernet, fieldbus, radio or mobile networks. This makes them likely to fall within the Cyber Resilience Act (Regulation (EU) 2024/2847) as products with digital elements. Under Article 2(1), the Regulation applies to products "the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network".

On this page we also draw on the draft Commission guidance on the application of the CRA, the content of which the Commission approved on 27 July 2026 (C(2026) 5252, so far in English only; formal adoption is pending), referred to below as the draft guidance. It is not binding (para. 8) and, according to the Commission's accompanying communication, applies only from its formal adoption; the CRA and the Implementing Regulation remain authoritative. In para. 26 the draft focuses on a product's capacity to exchange digital information, and in para. 28 it does not regard signals used solely to trigger or power a function, without conveying digitally encoded information, as a data connection. A detector that sends telegrams via bus or radio exchanges data with a device within the meaning of Article 2(1); whether a detector with a mere switching contact is covered should be checked individually.

Article 2(7) excludes products "developed or modified exclusively for national security or defence purposes" and products "specifically designed to process classified information". A catalogue product also installed in government buildings hardly meets this "exclusively" on the wording; we flag custom builds for review by your legal department.

The core question: does Annex III point 17 also cover professional devices?

Annex III class I point 17 lists "Smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems". The technical description in Annex I point 17 of Implementing Regulation (EU) 2025/2392 is narrower. It covers "Products with digital elements that protect the physical security of consumers in a residential setting and which can be controlled or managed remotely from other systems, as well as hardware and software that centrally control such products". Its examples are "smart door locking devices, baby monitoring systems, alarm systems and home security cameras".

The description therefore requires two features: the persons protected are consumers, and the setting is residential. Under Article 3(18) CRA, a consumer is a natural person who acts for purposes which are outside that person's trade, business, craft or profession. Recital 10 likewise speaks of consumer products. A camera, panel or VMS that, according to its intended purpose, instructions and technical documentation, is meant for industrial sites, warehouses, car parks or office buildings does not meet this description on its wording. If the product falls under no other category either, it is likely a default product.

What remains open is how to classify products intended for use in both settings: for example an intrusion alarm panel that installers fit in businesses and in family homes, or a camera series that specialist distributors also sell to private customers. Neither the CRA nor the Implementing Regulation addresses this expressly; under both, the core functionality determines the classification (Article 7(1), Article 8(1); recital 2 of the Implementing Regulation). The draft guidance does not deal with point 17 specifically either. It only describes in general terms how to determine the core functionality: by the main features and technical capabilities, in light of the specific context and conditions of use and taking into account the instructions for use, promotional or sales materials and the technical documentation (para. 139); what counts are the actual technical characteristics, and a description or marketing that does not reflect them is disregarded (para. 142); the draft cites clear inconsistencies between promotional materials, instructions for use and technical documentation as an example of misrepresenting the core functionality (para. 143), and each product should have only one core functionality (para. 144). This does not answer the question. Where your materials or sales channel include the residential setting, cautiously assume point 17 and flag the case for review by your legal department. For pure home devices, see the page on consumer IoT and smart home.

Access control: Annex III point 1 names readers expressly

For access control technology, the residential setting is irrelevant. Annex III class I point 1 lists "Identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers". The Implementing Regulation describes identity management systems as products that provide mechanisms for authentication or authorisation and states: "These systems include access management systems that control access of natural persons, legal persons, devices or systems to digital resources or physical locations." Its examples include authentication and access control readers and biometric readers.

A card reader, PIN reader or biometric reader at an office door is therefore likely an important product of class I. The same likely applies to access management software and to controllers that check permissions and decide on access. A pure input/output module without its own permission logic may have a core functionality other than that of an identity management system (recital 5 of the Implementing Regulation; draft guidance para. 142); this depends on the architecture.

Credentials are a separate question. Annex IV point 3 lists "Smartcards or similar devices, including secure elements". The Implementing Regulation expressly includes "physical access cards", but describes smartcards as secure elements integrated into a carrier material that are designed to provide protection of at least AVA_VAN.4 (Annex II point 3). A card with such a secure element is likely a critical product for its manufacturer. For the reader that reads such cards, the classification still follows its own core functionality.

Video and alarms: core functionality before individual functions

An NVR may contain a PoE switch and an operating system; a VMS configures cameras and distributes firmware. Under the second sentence of Article 7(1), integrating a product with an Annex III core functionality does not in itself make the host product subject to the procedures for important products. Under recital 5 of the Implementing Regulation, a product that can perform the functions of a category but whose core functionality differs does not correspond to its technical description; the draft guidance says the same in para. 141.

Annex III point 6 lists "Network management systems". The Implementing Regulation describes them as products "that manage connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by monitoring them and controlling their network operations and configuration". A VMS whose main features are recording, displaying and analysing video has a different core functionality. A tool that mainly controls the network operation and configuration of many devices is closer to point 6. If you also sell an access module of your VMS separately, the draft guidance (para. 145) treats it as a product in its own right, classified according to its own core functionality.

The Implementing Regulation describes Annex IV point 1 ("Hardware Devices with Security Boxes") as devices that securely store, process or manage sensitive data or perform cryptographic operations, consist of multiple discrete components and have a physical envelope providing tamper evidence, resistance or response. A tamper contact in the housing of an alarm panel is not enough for this on the wording; what counts is the core functionality (Article 8(1); recital 2 of the Implementing Regulation). For panels with key storage and tamper protection, you should document this delineation.

Typical products and their likely classification

The table is an initial technical assessment and not a binding classification. What counts is the core functionality of the specific product (Article 7(1), Article 8(1)).

For class I, the internal procedure based on module A is only available if harmonised standards, common specifications or a European scheme at assurance level at least "substantial" are applied in full; otherwise module B and C or module H applies (Article 32(2)). On 1 November 2026, no harmonised standard for the CRA had been published in the Official Journal. For critical products, Article 32(4) applies. More under product classes and conformity assessment.

Deadlines and obligations for security system manufacturers

Since 11 September 2026, the reporting obligation under Article 14 has applied (Article 71(2)). You report actively exploited vulnerabilities and severe incidents via the single reporting platform under Article 16, with an early warning within 24 hours and a notification within 72 hours (details under reporting obligation since September 2026). Under Article 69(3), this also applies to products placed on the market before 11 December 2027. The obligation therefore also covers devices you shipped in earlier years.

The other obligations apply from 11 December 2027 (Article 71(2)). Products placed on the market before then are subject to them only if they undergo a substantial modification from that date (Article 69(2)). Annex I Part I point (2)(c) requires automatic security updates only "where applicable". Recital 56 explains that the requirements on automatic updates do not apply to products where users would not normally expect them, for example products intended for use in professional ICT networks; as a recital it serves to interpret this "where applicable" and is not itself an exemption.

Two further points matter particularly for your industry. First, remote data processing: under Article 3(1) and (2), data processing at a distance is part of the product if its software is designed and developed by the manufacturer or under its responsibility and the product could not perform one of its functions without it; recital 12 gives cloud functionalities for controlling smart home devices at a distance as an example. Your own cloud service for remote access, remote configuration or update distribution can meet this. The draft guidance does not regard the operator of the service as decisive (para. 196) and treats third-party SaaS services like components (paras. 200 to 202). Second, long life cycles: if your devices must work with existing interfaces and legacy installations, the constraints belong in the risk assessment under Article 13(2); the draft guidance recommends documenting them together with compensating measures (paras. 30 to 32). On replacement devices for legacy installations, see the questions below.

A constructed example

The example is invented and does not describe any particular company. A medium-sized manufacturer offers access control readers, door controllers, locally installed access management software and an IP camera series for commercial premises, plus its own cloud service for remote access. It records one core functionality per product in its product register, assigns readers, controllers and software to class I as likely and plans for a notified body early. One camera series also reaches private customers via online retailers; it flags this case for review by the legal department. It describes the cloud service as remote data processing in the technical documentation, and an older reader interface for legacy installations as a constraint with compensating measures.

Next steps and how Blackfort Technology supports you

• Product register and classification: we assess scope and category technically and flag open cases such as point 17 for review by your legal department (gap analysis).
• Reporting process: setting up the reporting process and CVD under Article 14 (reporting and PSIRT).
• SBOM: software bills of materials from your build chain for firmware and software (SBOM consulting).
• Technical documentation: documents under Annex VII and, where needed, preparation for a notified body (technical documentation).

Related topics: building automation and BMS, network and security hardware and, for radio readers and radio detectors, radio equipment and RED DA. The scope check gives a first overview. This page is an initial technical assessment and not legal advice.