The UK’s Product Security and Telecommunications Infrastructure (PSTI) regime is now part of the construction landscape, even if it reads like a consumer tech story. Many of the connected devices used on sites and handed over to clients — cameras, smart locks, leak sensors, lighting controls, meters, gateways and 4G routers — overlap with what’s sold into the consumer market. PSTI sets a baseline for how those products are secured when sold in the UK. For project teams, the effect is practical: ask for proof of compliance at procurement, configure kit to modern security expectations on site, and hand over devices, credentials and update plans in a way that won’t leave the building exposed after PC.
TL;DR
/>
– Treat PSTI as a baseline for all connectable kit on site and in the final building, regardless of whether it is strictly in scope.
– Bake security into procurement: evidence of unique credentials, update support and a way to report vulnerabilities.
– Operate safely on site: segmented networks, no port forwarding on 4G routers, strong credential management and planned updates.
– Hand over properly: asset register, credentials, ownership of cloud accounts, and clear update responsibility for FM.
– Expect insurers and public-sector clients to increasingly ask for cyber hygiene evidence around smart building systems.
PSTI in plain English for site IoT and smart building kit
/> PSTI is about baseline cyber hygiene for “relevant connectable products” sold in the UK. In practice, it pushes out three simple expectations: no universal default passwords, a published way to report vulnerabilities, and clear information on how long security updates are provided. Manufacturers and importers carry most obligations, but buyers should be asking for proof and configuring devices in line with modern security practice.
Construction complicates things because projects mix “consumer-like” devices with professional controls. Some items will clearly fall under PSTI, others may not. The cleanest approach is to treat PSTI as the floor for everything you specify and install: if a sensor, lock, camera or gateway can be reached over a network, insist on unique credentials, a supportable update story and a clear end-of-life path.
How it actually plays out on UK projects
/> On a live programme, PSTI touches three phases. At specification and procurement, write requirements for proof of compliance (or equivalent baseline security), update support information, and a vulnerability reporting route. During installation and commissioning, configure devices with unique credentials, switch on multifactor logins where available, and place them on segmented networks. At handover, pass over an asset register, credentials and cloud accounts in a controlled way so FM isn’t starting from scratch.
A short UK scenario: A residential-led mixed-use scheme in Manchester is racing toward fit-out. The principal contractor’s M&E coordinator needs environmental monitors for dust and temperature, leak sensors for risers, and upgraded turnstile access at the loading bay. The security subcontractor brings in a 4G router and cameras, while the fit-out subcontractor installs smart thermostats for pre-commissioning. Under programme pressure, the subbie is tempted to enable port forwarding on the router for remote viewing and to leave default admin credentials in place “until Friday”. The site manager stops this, asking for PSTI-style evidence from suppliers and mandating unique logins and a private APN SIM with no inbound ports. Credentials are stored in a project password manager with role-based access. At PC, the cloud accounts for cameras and sensors are transferred to the client’s FM team along with an update support summary and a device inventory tied to rooms and serial numbers.
From gates to leak sensors: device risks and practical fixes
/> Turnstiles and access control. These often come with cloud portals and mobile apps. Use unique installer and admin accounts, force multifactor where supported, and disable anonymous “guest” modes. Place controllers on a VLAN, keep firmware current during commissioning windows, and specify export of credentials and event logs for handover.
CCTV and NVRs. Avoid internet-exposed NVRs. Do not use port forwarding on site routers; instead, use a managed VPN or a private APN with outbound-only connections. Change all camera and NVR credentials, disable peer-to-peer auto-traversal where not needed, and document the update mechanism so FM can keep patching post-PC.
Environmental, leak and structural sensors. Many low-power sensors talk to a gateway (LoRaWAN, Zigbee, NB-IoT). Secure the gateway: change credentials, update firmware, and restrict inbound traffic. Record device IDs (MAC/IMEI/DevEUI) and their physical location; it saves hours at handover and helps with eventual decommissioning.
Smart lighting, meters and BMS edge devices. These sit closer to operational technology (OT) and touch energy and life-safety adjacencies. Ask vendors to align with the PSTI baseline, but also reference good OT practice such as network segmentation, least-privilege accounts and change control. Keep commissioning tools and seed passwords out of site folders and personal emails.
Plant trackers and site routers. Asset trackers and telematics units can leak data if SIMs are unmanaged. Use named corporate accounts for SIMs, avoid shared logins, and lock down router admin interfaces. A router with a private APN and no open inbound ports is vastly safer than a quick DIY setup.
# Common mistakes
/>
– Assuming “it’s only temporary works” so defaults are fine. Temporary devices often become permanent by inertia and get forgotten — set them up properly from day one.
– Letting subcontractors own the cloud accounts. At handover you’ll be locked out or paying for transfers; create project-owned accounts early.
– Mixing site welfare Wi‑Fi with security devices. Keep security devices on a dedicated, segmented network to limit lateral movement.
– Patching at random. Unplanned updates can knock systems offline at the worst time; define maintenance windows and back-out plans.
On-site checklist for PSTI-aligned deployments
/>
– Require suppliers to confirm unique credentials, update support and a vulnerability reporting route for every connectable device.
– Issue project-owned cloud accounts and email aliases for device registration; avoid personal emails for admin logins.
– Segment networks: separate VLANs or SSIDs for security and building devices, with firewall rules denying inbound internet by default.
– Configure 4G/5G routers with a private APN or managed VPN; disable port forwarding and change the router’s admin credentials.
– Establish a password policy and use a shared password manager with role-based access; enable multifactor on all portals.
– Maintain a live asset register capturing device type, location, serial/MAC/IMEI, firmware version, SIM/account owner and update support period.
– Define an update and change-control routine: maintenance windows, approval steps, rollback plans and who signs off.
Pitfalls and fixes during commissioning and handover
/> Programme pressure is the enemy of security. Agree early which packages own which devices, who will configure them, and who signs off that PSTI-style basics are in place. Put the device inventory, credentials and update information into the O&M pack and ensure the client’s FM team can access vendor portals before PC. For retrofit and phased occupation, plan for dual-running: maintain safe defaults across both old and new systems without exposing either to the open internet.
What to watch next? Expect more project specs to reference cyber hygiene for OT, and for insurers to ask for evidence that smart building devices are supported and not internet-exposed. Bottom line: treat PSTI as the floor, design your networks and handovers around it, and you’ll cut both cyber risk and commissioning drama.
FAQ
# Which site devices are most likely to be affected by PSTI expectations?
/> Anything that connects to the internet or a local network and is commonly sold into the consumer or prosumer market will attract PSTI-style expectations. That includes cameras, smart locks, thermostats, leak sensors, smart plugs and many gateways and routers. More industrial controllers may sit outside the consumer scope, but applying the same baseline is still worthwhile.
# How should cloud accounts and data ownership be handled on a project?
/> Create project-owned accounts tied to role-based email aliases so you can hand them over cleanly. Define in contracts who owns the data and subscriptions from day one, including any transfer steps at PC. Avoid personal emails for admin rights and document how access will be revoked when firms demobilise.
# Can we still use off-the-shelf consumer devices temporarily on site?
/> Yes, but apply the same hygiene: unique credentials, multifactor if available, and no inbound internet exposure. Put them on segmented networks and plan for removal or transfer at PC. If the device will stay in the building, confirm update support and how the FM team will maintain it.
# How do we manage firmware and app updates without disrupting the programme?
/> Schedule maintenance windows and agree who can authorise changes. Test updates on a non-critical device first where possible, and keep a rollback plan if an update causes issues. Record firmware versions in the asset register so everyone knows what is live.
# What evidence should we file at handover to show good practice?
/> Include a device inventory with serials, locations and firmware versions, plus copies or links to supplier security information and update support details. Provide credentials and cloud account ownership transfer steps, stored securely rather than in the O&M text. Note the contact route for reporting security issues and the routine for ongoing updates.
