The EU Data Act and Connected Cameras: What 2026 Operators Must Disclose

The EU Data Act is not a privacy law. Operators who file it next to the GDPR misread it from the first paragraph, and that misreading will cost them in 2026.

Regulation (EU) 2023/2854, the instrument formally called the Data Act, governs access to and use of data generated by connected products and related services. A camera mounted on a construction perimeter, a sensor pole streaming thermal data into a logistics yard, a security robot patrolling a substation. All of them sit inside its scope. The obligations that arise from this fact are not about lawful processing of personal data. They concern who can ask for the data, in what form it must be released, and which contractual terms the manufacturer may no longer impose on the operator.

The provisions become applicable from 12 September 2025 onward, with further design obligations on products placed on the market from 2026. For operators of connected security technology, this is the first time European law treats their camera feed not only as a surveillance artefact under the GDPR and national CCTV rules, but as an industrial data asset with a portability dimension. The question is no longer just whether the recording is lawful. It is who else may demand a copy.

A regulation written for industrial data, applied to cameras

The Data Act was drafted with the industrial Internet of Things in view. Connected agricultural machinery, networked elevators, smart meters, telematics in vehicle fleets. The recitals speak the language of factories and field equipment, not of guard cabins and perimeter towers. Yet the operative definition of a connected product is wide. Article 2 defines it as an item that obtains, generates or collects data concerning its use or environment, and that is able to communicate that data through an electronic communications service. A modern security camera satisfies every element of that definition without exception. It collects data on its environment. It transmits that data over a network. It often retains derived data, such as detection events, classifications, motion vectors and audit logs.

This is where the operator's intuition fails. The instinct is to treat the camera as a closed system regulated primarily by the GDPR, by national rules on workplace monitoring, and by sector-specific obligations on retention. The Data Act adds a second axis. Even where the data contains no personal element, even where the imagery has been aggregated into purely technical telemetry, the user of the device, that is to say the operator or in many cases the data subject of the underlying service contract, holds a statutory right of access to the data their use of the product has generated. They also hold a right to share that data with third parties of their choosing, subject to defined exceptions.

The implication is structural. A manufacturer of connected cameras can no longer treat the data layer as a proprietary moat. A service provider operating cameras on behalf of a client can no longer retain exclusive technical access to event streams that the client itself produced through normal use. Contracts that lock the operator out of their own telemetry, or that prevent migration to a different analytics provider, fall under Chapter IV of the Regulation on unfair contractual terms. Manufacturers who built their commercial model on data exclusivity are facing a redesign that affects pricing, retention architecture and integration interfaces simultaneously.

What the security carve-outs actually cover

The Regulation contains exceptions, and a careful reading of those exceptions is the single most important exercise an operator can undertake before 2026. The first carve-out concerns essential security functions. Article 4(6) and the corresponding provisions permit a data holder to refuse a user's data-sharing request where disclosure would undermine the security of the connected product, in particular by exposing vulnerabilities that could be exploited. This is a narrow exception. It is not a general licence to withhold operational data because the device happens to perform a security function. The exception protects the integrity of the device, not the confidentiality of the surveillance output.

The second carve-out concerns trade secrets. Articles 4(6) and 5(9) permit the data holder to apply protective measures, including technical and organisational safeguards, where disclosure would risk serious economic damage through the loss of a trade secret. Again, the carve-out is procedural rather than substantive. The data holder must identify the protected element, communicate it to the user, and where required to the competent authority, and apply proportionate measures. It does not entitle the manufacturer to refuse the request outright. The presumption runs in favour of access.

The third area of qualification concerns law enforcement and national security. The Regulation defers to existing instruments. Where data forms part of an investigation or where a national security exception applies under Article 4(2) TEU, the Data Act does not override the relevant frameworks. In practical terms, this means that a camera deployed at critical infrastructure remains subject to the obligations of the NIS2 Directive, to national rules on critical entities, and to any sector-specific security regimes such as those addressed by IEC 62443 in industrial environments. The Data Act sits alongside these regimes, not above them.

What the carve-outs do not cover is the operator's own analytical telemetry. Detection events generated by an AI classifier embedded in the camera, audit logs of when the device was active, performance metrics on bandwidth, false-positive ratios, model version identifiers. These are exactly the data points that the user of the device may now demand, and they are exactly the data points that manufacturers have historically treated as internal product analytics. The carve-outs are not designed to preserve that treatment.

The disclosure architecture that 2026 demands

Article 3 of the Regulation sets out the design obligation. Connected products placed on the market must be designed and manufactured, and related services must be designed and provided, in such a manner that data generated by their use is, by default, easily, securely and where relevant and appropriate, directly accessible to the user. This is a default-on requirement. The factory configuration of the product must permit access. Configuration changes that disable access must be the exception, justified and documented, not the rule.

For a camera operator, the practical disclosure architecture has four layers. The first layer is pre-contractual information. Article 3(2) requires that, before concluding a contract for the purchase, rent or lease of a connected product, the seller, renter or lessor provide the prospective user with information on the type, format and estimated volume of data the product will generate, on whether the data can be accessed in real time, on the identity of the data holder, and on the means by which the user can request access. This is a transparency duty enforceable through national consumer-protection and market-surveillance authorities. It applies to business-to-business sales as well as to consumer transactions.

The second layer is the in-life access mechanism. The Regulation does not prescribe a specific interface, but it does require that the access be free of charge for the user, that it be provided without undue delay, that the data be of the same quality as that available to the data holder, and that it be continuous and real time where the nature of the data permits. For a security camera, this typically means an API or export function that the operator can invoke without dependence on the manufacturer's discretionary cooperation. Manufacturers who route every export request through a manual ticketing process will find themselves out of compliance.

The third layer is the third-party sharing right. Article 5 permits the user to instruct the data holder to make the data available to a third party. The data holder cannot refuse this instruction except on the narrow grounds discussed earlier. The third party, often a competitor of the manufacturer in the analytics or services layer, becomes a recipient of the data with its own set of obligations. For operators, this means that the choice of analytics provider, of central monitoring station, of integration partner, is no longer locked to the device vendor. The lock-in that has defined large parts of the surveillance industry for two decades is dismantled at the legal level.

The fourth layer is documentation. The operator who cannot demonstrate which data is held, in which format, with which retention period, and under which access regime, will struggle to respond to a user request or to a regulatory enquiry. The documentation discipline that ISO 27001 has long required for information security management is now a baseline expectation for data governance more broadly. The reference to NIST CSF 2.0, which integrates Govern as a function alongside Identify, Protect, Detect, Respond and Recover, captures the same shift in framing. Governance of data flows is no longer a back-office exercise. It is the operational substrate on which compliance rests.

Where the Data Act meets the GDPR, NIS2 and the AI Act

The temptation to treat the Data Act as a stand-alone instrument should be resisted. Connected cameras produce personal data within the meaning of the GDPR, they often qualify as essential or important entities under NIS2, and where they incorporate biometric identification or behavioural analytics, they fall within the high-risk classification of the AI Act. The four instruments interact, and a compliant disclosure architecture must function in all four registers simultaneously.

The GDPR governs the personal data dimension. A user-initiated data export under the Data Act does not override the controller's obligations under Articles 5, 6 and 32 GDPR. Where a third-party recipient is designated under Article 5 of the Data Act, the transfer of personal data to that recipient must rest on a lawful basis under the GDPR, must respect the principles of purpose limitation and data minimisation, and must be accompanied by appropriate security measures. The European Data Protection Board has indicated that the interplay is to be managed through layered legal bases and through technical separation of personal and non-personal data streams where this is feasible.

NIS2 governs the security dimension. Operators of cameras deployed at critical infrastructure, in healthcare facilities, at logistics nodes designated as essential, are subject to the security and incident-reporting obligations of the Directive. A disclosure mechanism designed to satisfy the Data Act must not create attack surface that contravenes NIS2. The CISA cross-sector guidance on operational technology, together with the German BSI's IT-Grundschutz catalogues and the IEC 62443 family of standards, provides the practical reference frame for that balancing exercise.

The AI Act governs the algorithmic dimension. Cameras that incorporate biometric categorisation, emotion recognition or real-time identification fall within categories that are either prohibited or subject to high-risk obligations. The data generated by these systems, including their detection logs and confidence scores, may be requested by the user under the Data Act. Where the requested data reveals the operation of the model in ways that engage the AI Act's transparency and documentation requirements, the two regimes must be harmonised at the level of the export schema. The book BOSWAU + KNAUER. From Building to Security Technology describes the platform architecture that anticipates this convergence, with open interfaces and documented data formats designed precisely to avoid the lock-in that the Data Act now prohibits as a matter of European law.

What operators must do before September 2025 and into 2026

The compliance work splits into three phases, each with a defined deliverable and a defined window. The first phase is inventory. The operator must know, at the level of the individual device, which data is generated, which is retained on-device, which is transmitted to the manufacturer, which is held by an analytics provider, and which is accessible to the operator itself. This sounds elementary, and it is exactly the exercise that most operators have never completed. ASIS International's guidance on enterprise security risk management treats the data inventory as a prerequisite for risk assessment, and the Data Act now turns that recommendation into a statutory expectation.

The second phase is contractual review. Existing contracts with camera manufacturers, integrators and service providers must be examined for clauses that, after September 2025, will qualify as unfair within the meaning of Chapter IV of the Regulation. These include clauses that prevent the operator from accessing data generated by their use of the product, clauses that prohibit sharing with third parties, clauses that impose disproportionate liability on the user for exercising data-access rights, and clauses that allow the data holder to terminate the contract in response to a lawful access request. Where such clauses exist, they are not automatically void in their entirety, but the unfair element is unenforceable and the contract is to be read without it. Operators should not wait for litigation to confirm this. They should renegotiate.

The third phase is operational design. The disclosure architecture must be embedded in the procurement specification for any new camera, sensor pole or security robot acquired after 2026. Pre-contractual information must be requested and retained. Access mechanisms must be tested at acceptance, not assumed. Third-party sharing capability must be verified through actual export trials. The pilot format, three months in duration, with defined success metrics agreed before installation, is the appropriate instrument for that verification. The manuscript referenced above sets out the structure of such a pilot in detail, and the format is offered to operators who wish to verify the disclosure architecture of a proposed deployment under realistic conditions before scaling.

National authorities will enforce the Regulation through the mechanisms designated by each Member State, and the GDV in Germany has signalled that insurers will increasingly request evidence of Data Act compliance as part of cyber and operational policies. The cost of inaction is therefore not only regulatory. It is commercial. Insurance pricing, procurement scoring in public tenders, and the willingness of integration partners to commit to long-term contracts all become functions of disclosure readiness.

What holds

The EU Data Act reframes the camera from a device that watches into a device that generates a data asset to which its user has statutory rights. The reframing is not negotiable, and the carve-outs that exist are narrower than the marketing material of many manufacturers suggests. Operators who treat the Regulation as a compliance afterthought, layered on top of existing GDPR processes, will find themselves unable to answer the first user request that arrives in late 2025 or 2026.

The technical work is finite. An inventory of data flows, a contractual review for unfair terms, an operational design that embeds disclosure by default. None of it is conceptually difficult. All of it requires a discipline that the industry has not previously imposed on itself, because the commercial incentives ran the other way. The Regulation removes those incentives, and the operators who recognise the shift early will set the terms on which the next generation of contracts is written.

For operators who want to verify their readiness against the Regulation before the enforcement window closes, a sixty-minute confidential conversation under Path I is the appropriate first step. The deeper diagnostic, structured as a three to five day audit under Path II, delivers a written report on the disclosure architecture of existing deployments and an implementation plan that an internal team or an external partner can execute. The choice of path follows from the operator's own position, not from a vendor's preference.

Frequently asked questions

What is the EU Data Act?

Regulation (EU) 2023/2854, known as the Data Act, governs access to and use of data generated by connected products and related services across the European Union. It establishes rights for users to access the data their use of a device generates, to share that data with third parties of their choice, and to do so on terms that the manufacturer cannot unilaterally restrict. The Regulation entered into force in January 2024, with its main operative provisions applying from 12 September 2025 and further design obligations affecting products placed on the market thereafter.

How does it apply to cameras?

A connected camera satisfies the Regulation's definition of a connected product because it collects data on its environment and transmits that data through an electronic communications service. This brings the camera, its embedded analytics, its event logs and its operational telemetry within the scope of the Data Act. The carve-outs for essential security functions and trade secrets are narrow and procedural. They do not exempt the manufacturer or service provider from the core obligation to make user-generated data accessible to the user by default, and to permit sharing with third parties on the user's instruction.

What must be disclosed?

The obligations split into pre-contractual information and in-life access. Before purchase, rent or lease, the prospective user must receive information on the type, format and estimated volume of data the product generates, on real-time access availability, on the identity of the data holder, and on the access mechanism. During operation, the user must be able to access the data free of charge, without undue delay, in the same quality as the data holder, and continuously where the nature of the data permits. Detection events, audit logs and performance metrics are within scope.

When does it apply?

The Regulation entered into force on 11 January 2024. Its main operative provisions, including the access rights and the unfair-terms regime, apply from 12 September 2025. The design obligation in Article 3, which requires connected products to be built so that data is accessible by default, applies to products placed on the market from 12 September 2026 onward. Operators should treat the September 2025 date as the practical deadline for contractual review and disclosure architecture, with 2026 as the date by which procurement specifications for new devices must fully reflect the design requirements.