Manufacturers are primarily accountable, but importers and distributors also have compliance obligations when bringing consumer connectable products into the UK market. Accountability should include product security governance, self-declaration accuracy, and evidence that mandatory controls are in place. If obligations are not met, organisations may face significant financial penalties and enforcement action.
Why This Matters for Security Teams
Statutory product security is not just a legal label, it is a governance control that defines who must prove security, who must preserve evidence, and who carries enforcement exposure when a consumer connected product is weak by design. For teams shipping into regulated markets, accountability extends beyond engineering into supplier assurance, release sign-off, and post-market monitoring. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because it maps control ownership to auditable outcomes, not just good intentions.
What practitioners often get wrong is assuming product security can be “owned” by a single technical function. In reality, accountability is shared across product, security, legal, compliance, and supply chain management. Manufacturers are usually the primary accountable party because they design the product and make security claims. Importers and distributors can also inherit obligations when they place products on the UK market, especially if they alter the product, fail to verify compliance evidence, or rely on inaccurate declarations. In practice, many security teams encounter this only after a regulator, customer, or incident response process has already exposed the gap, rather than through intentional compliance design.
How It Works in Practice
Operational accountability starts with knowing which entity is the “economic operator” for the market in question and then assigning specific proof obligations to that entity. For consumer connected products, this usually means the manufacturer must demonstrate that baseline controls are implemented, documented, and maintained across the product lifecycle. Importers and distributors should not treat themselves as passive logistics partners if they rebrand, modify, or materially influence the product’s route to market.
A workable accountability model usually includes:
- Named control owners for secure development, vulnerability handling, and update support.
- Evidence retention for self-declarations, technical files, and conformity decisions.
- Supplier and component traceability for firmware, libraries, and cloud dependencies.
- Release gates that block shipment when mandatory security claims cannot be substantiated.
- Post-market monitoring for vulnerabilities, exploitability, and patch deployment.
Security leaders should align these obligations with broader control frameworks rather than treating them as a one-off compliance task. The CISA Known Exploited Vulnerabilities Catalog is a practical reminder that vulnerability prioritisation must be grounded in active exploitation risk, while the CISA Secure by Design approach reinforces that product security should be built into design decisions, not bolted on after release. For organisations using software bills of materials, the governance question is not only whether a BOM exists, but whether someone is accountable for acting on it. These controls tend to break down when products are shipped through multi-party channels with weak change control, because no single operator can confidently prove what was sold, modified, or declared.
Common Variations and Edge Cases
Tighter accountability often increases legal review, evidentiary overhead, and release friction, requiring organisations to balance time-to-market against provable compliance. Best practice is evolving where resellers, marketplace sellers, and white-label arrangements blur ownership boundaries, so organisations should avoid assuming that commercial branding alone decides responsibility.
Edge cases usually appear when a product is imported unchanged, when a distributor rebrands a device, or when an overseas manufacturer has no clear UK compliance representative. In those situations, the party placing the product on the market may need to prove due diligence even if it did not write the firmware. Another common gap is the difference between “security supported” in marketing language and a specific statutory commitment about update duration, vulnerability disclosure, or minimum protections.
Where consumer connected products rely on cloud services or companion apps, accountability can also extend beyond the hardware box. That is where identity and access governance starts to matter, especially for admin portals, device registration workflows, and service accounts used in operations. If those identities are not controlled, the product may be secure on paper but fail in deployment. For risk mapping, it is reasonable to pair product obligations with the NIST Privacy Framework and security control baselines, but there is no universal standard for liability allocation across every channel model yet.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS address the attack surface, NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance oversight fits statutory accountability and evidence ownership. |
| NIST AI RMF | Risk management supports accountable decisions when product claims affect security outcomes. | |
| MITRE ATLAS | Adversarial thinking helps assess abuse of connected products and supporting services. | |
| NIST SP 800-63 | Device and service onboarding often depends on identity assurance and account proofing. | |
| EU AI Act | If connected products embed AI, accountability extends to AI governance and documented controls. |
Record AI-related safety and security responsibilities when connected products include model-driven features.
Related resources from NHI Mgmt Group
- Who is accountable when identity security controls fail across team boundaries?
- Who is accountable when a communication platform does not meet sovereignty requirements?
- Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?
- Who is accountable when a cloud-hosted identity governance service cannot meet sovereignty requirements?
