Connected products are now everywhere in British business: smart thermostats in offices, sensors in warehouses, trackers on delivery vans, wearables sold to consumers. For a long time, the security of these devices was left to the manufacturer’s conscience. That has changed. Two pieces of legislation, the UK’s Product Security and Telecommunications Infrastructure (PSTI) regime and the EU’s Cyber Resilience Act (CRA), now turn device security into a legal obligation, and many companies that sell or rebrand connected products have not yet noticed that the rules apply to them.
What the UK already requires
The PSTI product security regime came into force on 29 April 2024. It applies to consumer connectable products made available in the UK, from smart speakers and cameras to connected appliances and fitness trackers. Responsibility does not stop with the manufacturer: importers and distributors have duties too, which matters for retailers and brands that sell white-label devices made elsewhere.
The baseline is short but strict:
- No universal default passwords. Every device must ship with a unique password or require the user to set one. Passwords such as “admin” or “12345” are banned.
- A way to report security problems. The manufacturer must publish how researchers and customers can report vulnerabilities and what happens after a report.
- A stated support period. Buyers must be told, at the point of sale, the minimum period during which the device will receive security updates.
Enforcement sits with the Office for Product Safety and Standards, and the penalties are designed to get attention: fines of up to £10 million or 4% of global turnover, whichever is higher.
What the EU adds from 2026
For UK companies that sell into the EU, the Cyber Resilience Act goes considerably further. It covers almost any product with digital elements, including business devices and the software that runs them, not just consumer gadgets.
The CRA entered into force in December 2024 and applies in stages. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents to EU authorities, with an early warning due within 24 hours of becoming aware. From 11 December 2027, the full set of requirements applies: security by design, vulnerability handling throughout the product’s support period, security updates, and technical documentation that proves all of this. Products that do not comply cannot carry the CE marking and cannot be sold in the EU.
For many businesses, the reporting deadline is the more urgent one, because it applies to products already on the market. A device sold three years ago, still connected and still in use, is within scope if a vulnerability in it is being exploited today.
Why this is a software problem, not a paperwork problem
It is tempting to treat both regimes as a compliance exercise: write a policy, add a line to the product page, move on. In practice, each requirement leads straight into engineering.
A unique password per device has to be generated and written during manufacturing, then delivered to the buyer securely. A promise of five years of security updates requires a working over-the-air update mechanism, signed firmware, and a team that can actually ship patches for hardware that may no longer be in production. Reporting an exploited vulnerability within 24 hours means knowing which firmware versions are in the field, which customers run them, and how quickly a fix can be built and tested.
This is where many connected products fall short. Devices are often built quickly for a launch, with firmware from one supplier, a mobile app from another, and a cloud backend from a third. Nobody owns the full picture, and there is no inventory of what is running where. When a vulnerability appears in a shared component, the company cannot answer the first question regulators will ask: which of your products are affected?
Five questions to ask about your connected products
Whether you manufacture devices, import them, or sell them under your own brand, these questions show quickly where the gaps are:
- Do we know every connected product we sell, and which firmware versions are in the field? Without this inventory, neither reporting nor patching is possible.
- Can we update devices remotely and securely? If an update requires a technician visit or a customer to plug in a cable, a long support promise is hard to keep.
- Who receives vulnerability reports, and what happens next? A published contact address is required; a tested internal process to assess and fix issues is what makes it useful.
- What support period have we committed to, and is it funded? Five years of updates for a device sold today is a cost that should be in the product budget, not discovered later.
- Do our suppliers’ contracts cover security updates? If the firmware or a key component comes from a third party, their obligations need to match yours.
Treat it as a product decision
The companies that handle this well tend to make security part of the product plan rather than an afterthought. They decide the support period before launch, choose hardware that can be updated, keep a software bill of materials for every device, and design the backend so that a fleet of devices can be updated in stages and rolled back if something goes wrong.
In most IoT projects, the device itself is not the hardest part. The hard part is the system around it: knowing what is deployed, updating it safely, and proving to a regulator that you did. Building that in from the start costs far less than adding it after the first incident.
What this looks like in practice
Two projects by SCAND, a Warsaw-headquartered company with 25 years in IoT software development, from firmware and companion apps to cloud platforms, show how the same engineering choices serve both business goals and compliance.
In a connected car and fleet monitoring app, SCAND’s team built a device layer that talks to vehicle hardware over Bluetooth Low Energy and Wi-Fi Direct and keeps a clear record of which hardware and firmware each vehicle runs. Because new equipment plugs into a common layer instead of a custom integration, connecting a new device type became more than 50% faster. The same inventory is exactly what a company needs when it has to say, within a day, which products a vulnerability affects.
In a soil sampling platform for agricultural field teams, operators work where mobile coverage is weak. The app stores data on the device, syncs it securely once a connection returns, and talks to sampling hardware over BLE. Field operations became up to 25% faster through better routing and zoning, and no data is lost when the signal drops. Secure, resumable sync is also what makes reliable remote updates possible later in the product’s life.
In both cases, the client asked for features: a faster app, new hardware support, reliable field data. The update mechanism, device inventory and secure sync were designed alongside those features, so the product was ready for rules like PSTI and the CRA without a separate compliance project.
Where to start
For UK businesses, the timing is worth noting. PSTI is already enforced, and the CRA’s reporting duties apply now to anyone selling connected products in the EU. A practical first step is a short technical review of each product line: what firmware is in the field, how updates are delivered, who handles vulnerability reports, and what support period has been promised. That review takes days. Fixing a device fleet after a regulator’s letter can take much longer, and the work is the same either way.
Leave a Comment