Published: 11 September 2026

Today is a meaningful date for the connected-security market. From 11 September 2026, manufacturers of products with digital elements made available on the EU market must report actively exploited vulnerabilities and severe security incidents under the EU Cyber Resilience Act (CRA). On the same day, ENISA’s CRA Single Reporting Platform became operational.

This is not a Europe-Connection product announcement, nor does it mean that every requirement of the CRA is already fully enforceable. The wider Act becomes fully applicable on 11 December 2027. But the reporting phase now live changes the operating environment for manufacturers of networked cameras, recorders, access-control readers and controllers, alarm panels, intercoms, gateways, mobile-connected devices and the software that connects them.

For buyers, installers, facilities teams and security managers, the practical message is straightforward: a connected security device is no longer only a physical-security tool. It is also a cyber-physical asset with a support lifecycle, an update path, a supplier escalation route and potential exposure beyond the perimeter it was intended to protect.

The September milestone: reporting starts before full CRA application

The CRA entered into force on 10 December 2024, establishing a horizontal European framework for hardware and software products with digital elements. Its broad ambition is to make security a lifecycle issue: products should be designed, delivered and maintained with cybersecurity risks in mind.

There is an important distinction to retain this September. The reporting obligations are now applying to manufacturers, while the main date for full CRA applicability remains 11 December 2027. In other words, this is not a last-minute instruction for every organisation using connected equipment to redesign its estate overnight. It is a regulatory signal that vulnerability handling and incident communication are moving from a desirable vendor practice towards a formalised market responsibility.

The European Commission says manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of covered products. The reporting sequence includes an early warning within 24 hours of becoming aware, a notification within 72 hours, then a final report on a timetable determined by whether the case involves an actively exploited vulnerability or a severe incident.

Notifications are submitted via ENISA’s Single Reporting Platform, which is intended to support a “report once” approach to communication with the relevant authorities. Reporting through this route should not be confused with automatic public disclosure. The CRA process involves ENISA and relevant CSIRTs, and wider dissemination may be handled differently where exceptional cybersecurity grounds apply.

Why physical-security technology belongs in this conversation

The word “cybersecurity” can still sound detached from a camera on a loading bay, a badge reader at a staff entrance or an alarm panel in a plant room. In practice, connectivity has erased much of that separation. A modern video surveillance deployment may involve camera firmware, network video recorders, management software, mobile applications, cloud relay services, user accounts, storage, APIs and remote support channels. Access control and intrusion systems follow a similarly layered model.

Each layer can be relevant during an incident. An unpatched device may offer an attacker a foothold; weak account management can undermine a well-sited camera; a poorly planned update can interrupt recording, alarm monitoring or access operations. The operational question is therefore not merely whether a device is online. It is whether the organisation knows how that device is supported, how it is administered and what happens when a serious vulnerability emerges.

This concern is grounded in the current threat picture. CERT-EU’s 2025 Threat Landscape Report, published in April 2026, identifies exploitation of internet-facing software as the highest-impact initial access vector for the second consecutive year. Edge devices—including firewalls, VPN appliances and network-management solutions—remain primary targets. Security infrastructure is not identical to those product categories, but the lesson travels well: devices at the edge, especially those exposed for remote administration or remote viewing, deserve disciplined attention.

NIST’s September 2026 draft update to SP 800-82 also places building automation, physical access control and physical-environment monitoring systems within the wider operational-technology security discussion. That is useful context. The traditional division between “IT owns cyber” and “security owns doors and cameras” is increasingly impractical when both rely on shared networks, identities and suppliers.

Procurement is becoming a frontline cybersecurity control

The most consequential effect of the CRA reporting phase may happen long before an incident: at procurement. When organisations select connected devices only on image quality, detection range, connectivity or headline price, they leave out questions that determine whether the product can be managed safely over time.

For connected cameras, alarm systems, access-control platforms and related components, a credible procurement conversation should now include:

• What is the declared support period for this product and its software?
• How are security updates delivered, authenticated and documented?
• Where does the supplier publish security advisories and vulnerability-disclosure information?
• What secure-by-default settings are supplied, and which settings must be changed during commissioning?
• What is the process for notifying customers or integrators of a material vulnerability or security incident?
• Which cloud services, mobile applications, firmware versions and separately sourced components form part of the working system?

These are not simply compliance questions to add to a tender template. They are continuity questions. A camera may still produce excellent footage, or an intrusion alarm may still detect an event, but neither capability is sufficient if the organisation has no dependable way to assess a vendor advisory, identify affected units or schedule a safe remediation.

On 27 July 2026, the Commission published implementation guidance addressing, among other subjects, product scope, substantial modifications, support periods, reporting obligations and risk assessments. That guidance matters because not every device, component or deployment will be treated identically. Scope depends on the product’s characteristics, how it is made available on the EU market, its direct or indirect data connection, and possible exclusions or sector-specific rules.

What customers and integrators should change now

Build an inventory that is usable under pressure

An asset list that says “12 cameras, one recorder” is not enough in a vulnerability event. A useful record connects each operational asset to its model, serial number or location, firmware and software versions, administration route, network zone, support owner, supplier contact and relevant cloud or cellular service. It should also identify systems that depend on the device, such as a recording server, monitoring station or access-control database.

This does not require turning a security team into a full-time software-audit department. It means being able to answer a time-sensitive question: Are we affected, where is the equipment, and what can we safely do next? The CRA’s coverage of products with digital elements—including, in many circumstances, components placed separately on the market—makes that discipline more relevant, not less.

Plan supplier escalation alongside technical containment

When an actively exploited vulnerability is announced, a manufacturer may have legal reporting duties. That does not remove the customer’s operational responsibilities. The local response may still need to identify exposed assets, preserve relevant logs, reduce external exposure, segregate affected equipment, reset credentials where appropriate, contact the supplier or installer, and apply validated remediation.

That supplier contact route should be established before the emergency. Who can authorise an outage? Who owns the installer relationship? Is there a maintenance agreement? Is support provided directly by the manufacturer, a distributor, a systems integrator or a managed service provider? These questions often determine whether a patch advisory becomes a controlled maintenance task or an avoidable operational scramble.

Patch with discipline, not panic

“Patch immediately” is attractive advice, but it can be incomplete for operational security systems. A rushed firmware change can affect camera availability, evidence continuity, integrations, alarm signalling or access permissions. That is not an argument for leaving known risk in place. It is an argument for a risk-based process: assess exposure and exploit status, test where possible, set a maintenance window, prepare a rollback plan, verify post-update operation and reduce exposure while remediation is being prepared.

For example, a device exposed directly to the public internet generally deserves a more urgent response than an equivalent device isolated behind properly managed network controls. Temporary compensating measures might include removing unnecessary remote access, restricting management interfaces to a trusted network, changing compromised credentials or monitoring relevant logs more closely. The right choice depends on the system, the risk and the consequences of interruption.

A different standard for “connected” equipment

Security technology has often been bought as a finished object: install it, configure it, then expect it to work quietly for years. Connectivity changes that bargain. Products such as a Wi-Fi spy camera, a cellular tracker or a networked alarm system have a lifecycle that can include firmware, credentials, radio and network configuration, applications, storage and third-party infrastructure. They should be selected and operated lawfully, proportionately and with clear attention to privacy as well as security.

The same logic applies on the defensive side. Organisations using counter-surveillance equipment to assess suspicious signals or devices should also consider the integrity of their own connected tools: who maintains them, what data they create, and how updates or vulnerabilities are handled.

None of this suggests that an end user automatically becomes the CRA reporting entity. The obligation primarily falls on manufacturers. Nor does it mean all connected security products fall into scope in exactly the same way. It does mean that customers and integrators increasingly need evidence of vendor readiness rather than broad assurances that a product is “secure”.

The editorial takeaway: reporting makes lifecycle maturity visible

The live reporting obligation is easy to reduce to a regulatory deadline. Its deeper value is that it tests whether manufacturers have a mature vulnerability-response capability: a way to receive reports, investigate them, decide what customers need to know, coordinate with authorities and deliver a credible remedy.

That capability will become a practical differentiator for connected security ecosystems. Buyers cannot outsource their own asset management or incident preparedness to a manufacturer. Yet they can—and should—make lifecycle support, transparency and security response part of what they buy.

As the CRA moves toward full applicability in December 2027, the most prepared organisations will be those that see cyber resilience as part of physical-security resilience. They will know their installed base, retain support contacts, limit unnecessary exposure, plan changes carefully and expect suppliers to communicate clearly when a vulnerability matters.

For a market built around protecting people, premises and assets, that is not an administrative extra. It is increasingly part of the job.

Sources

• European Commission, CRA reporting obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• ENISA, CRA Single Reporting Platform: https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp
• European Commission, Cyber Resilience Act summary: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
• European Commission, implementation guidance announcement, 27 July 2026: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-new-guidance-support-businesses-implementation-cyber-resilience-act
• CERT-EU, Threat Landscape Report 2025: https://cert.europa.eu/blog/threat-landscape-report-2025