A connected product is a device or item that obtains, generates, or collects data about its use, performance, or environment. In practice, this includes internet-connected hardware and similar products whose data can be accessed or shared under the Data Act. The category matters because it determines when user access rights and disclosure duties apply.
What Makes a Connected Product Distinct
A connected product is not defined by brand or form factor, but by its ability to generate, obtain, or share data about use, performance, or environment. That data-bearing property is what brings the product into scope for user access rights and disclosure duties under the Data Act.
For practitioners, the important distinction is that connectivity alone is not the whole story. A device becomes legally and operationally significant because it creates a data relationship that can be governed, shared, or requested, which makes product classification and data scoping part of the design conversation.
Data Access, Sharing, and Scope
The core issue for a connected product is which data is collected, who can access it, and on what basis it may be shared. That scope can include data generated by the product itself, data inferred from its operation, and data needed to support the rights attached to the product’s use.
This is why the category matters: it helps determine whether the product owner must support access, portability, or disclosure workflows. In practice, teams need a clear view of what counts as product data versus adjacent operational data, because the answer affects downstream handling, contracts, and technical interfaces.
Where the product exposes APIs, device portals, telemetry feeds, or export functions, those channels become the practical means by which access and disclosure duties are fulfilled. The legal category and the technical implementation therefore meet at data inventory, interface design, and control boundaries.
Why Classification Matters in Practice
Classification is often the step that decides whether a product is treated as a connected product at all, which then determines whether related obligations apply. Misclassification can lead to either over-disclosure, where data is exposed too broadly, or under-disclosure, where required access is not provided at all.
For teams building or selling connected devices, the classification decision should be made early, before release and before data-sharing workflows are fixed. That avoids retrofitting access logic, documentation, and support processes after the product is already in market.
Technical and Governance Implications
Connected products require more than secure hardware, they need a governed data model. Product teams should be able to explain what data is produced, how long it is retained, how it is exported, and which parties can receive it under defined conditions.
That governance usually touches product design, privacy review, customer support, and external sharing terms. It also benefits from security controls around integrity, access logging, and interface hardening, because any data-sharing right is only useful if the product can expose data reliably without creating unnecessary exposure.
For the connected-device security baseline, broader control catalogues such as EU Cyber Resilience Act help frame secure-product expectations, while NIST Cybersecurity Framework 2.0 remains useful for organizing governance, protection, detection, response, and recovery around the product lifecycle.
Risk and Threat Considerations
Connected products expand the attack and exposure surface because they combine embedded functionality, data collection, and external sharing paths. The risk is not only device compromise, but also unauthorized data disclosure, weak access control, and insecure interfaces that let third parties obtain more product data than intended.
Failure mechanism: Poor classification, weak API security, or incomplete disclosure controls can expose product telemetry, usage history, or environment data through portals, export functions, or partner integrations.
Impact: The result can be privacy harm, commercial leakage, regulatory non-compliance, and loss of trust in the product ecosystem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cyber Resilience requirements | Connected products depend on secure-by-design device and software handling. |
| Recommendation — Apply cyber-resilience requirements to harden the product and its update and interface surfaces. | ||
| NIST CSF 2.0 | GV — Govern | Connected products need governance over data scope, ownership, and sharing duties. |
| PR.AC — Identity Management, Authentication, and Access Control | Connected products expose data through access-controlled portals, APIs, and export paths. | |
| PR.DS — Data Security | Connected products collect and transmit operational data that must be protected in transit and at rest. | |
| Recommendation — Establish governance for product data classification, access rights, and disclosure obligations. Enforce access control on product data interfaces and sharing workflows. Protect product data throughout collection, storage, transmission, and export. | ||
| CIS Controls v8 | 6 — Access Control Management | Connected products need controlled access to product data and connected services. |
| 3 — Data Protection | Connected products create data exposure risk through telemetry and sharing channels. | |
| Recommendation — Restrict and review access to product data interfaces, portals, and APIs. Classify and protect product data according to sensitivity and sharing conditions. | ||
Practitioner Guidance
Governance implication: Treat connected-product status as a lifecycle control decision, not just a product label. Product, legal, security, and data teams should agree on the data set, the sharing boundary, and the conditions under which access rights are fulfilled.
What to watch for: The biggest warning sign is when teams can describe the device features but not the data it produces or who can receive it. If that boundary is vague, the product will be difficult to govern consistently once access requests or disclosure obligations start arriving.
Related resources from NHI Mgmt Group
- What should organisations do first when connected product controls are exposed?
- Who is accountable when a connected product cannot be patched or retired securely?
- Why do connected vehicle ecosystems create more identity risk than traditional product environments?
- Who is accountable when a digitally connected product fails CRA expectations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
