PSTI Compliance Won’t Stop What IoT Penetration Testing Finds

Since April 2024, every connectable product sold in the UK has had to meet legal minimums. The Product Security and Telecommunications Infrastructure Act bans default passwords. It also requires a published vulnerability disclosure route and clear information on how long security updates will run. Many businesses now assume a compliant device is a secure one. IoT penetration testing exists because that assumption is wrong. Government-backed research on real enterprise devices shows exactly why.

Compliance is a floor, not a security guarantee

The PSTI regulations ban default passwords. They require a disclosure policy and demand update transparency. These are sensible baseline duties, and they close off some of the laziest attacks. But none of them force a manufacturer to prove its firmware has no hardcoded root credentials. Nor do they check whether an update mechanism actually verifies signatures. And none require proof that wireless pairing cannot be abused by someone standing in the car park.

A device can tick every PSTI box and still fail badly under IoT penetration testing. The regulation was written to stop the most careless practices. It was never written to certify genuine security engineering.

What the government’s own testing found

An assessment commissioned by the Department for Science, Innovation and Technology tested enterprise devices for real. NCC Group carried out the work, covering IP cameras, VoIP phones, network storage and meeting room panels. Testers checked each device against NCSC principles and the ETSI EN 303 645 standard. The results were not subtle.

The tests turned up remote code execution flaws that let an unauthenticated attacker take full control. They also found bootloaders more than fifteen years old, still shipping in current products. And background services were often running with unnecessary root privileges too.

These are the kind of devices sitting on office networks right now. Nobody thought to test them the way a laptop or a web server gets tested. A firewall rule does nothing for a camera that hands over full control to anyone who finds the right request.

Why a network scan cannot replace IoT penetration testing

A vulnerability scanner looks at what a device exposes over the network. It cannot open the case or extract the firmware. Nor can it sit within Bluetooth range and try to pair with a device the way an attacker would. The OWASP IoT Security Testing Guide exists for exactly this reason. Hardware, firmware, wireless protocols, companion apps and the cloud backend all work together, and a web or network test alone was never built to cover them.

That is the real case for IoT penetration testing. It looks at the layers a scan cannot reach, and the layers PSTI compliance does not check at all.

Where the real risk usually sits

• Shared firmware credentials: the same hardcoded key or password sits in every unit of a model. One compromised device can compromise the whole fleet.
• Weak update signing: an update mechanism accepts anything signed, or nothing signed at all, because verification was done poorly or skipped.
• Wireless pairing gaps: Bluetooth or Zigbee links accept a connection without proper authentication, so a nearby attacker can issue commands.
• Root-privileged services: background processes run with far more access than they need. A small flaw then becomes full device control.

Every one of these came up in real testing of real enterprise products. None of it is a hypothetical worst case.

What the NCSC expects buyers to check

The NCSC’s device security principles for manufacturers set out eleven rules for enterprise-connected devices. They cover secure updates, authentication, data protection, device integrity, logging and the ability to recover to a known good state. Manufacturers are the intended audience, but a business procuring cameras, sensors or other connected kit can use the same list too. It tells you what to actually check before you buy, whether or not the supplier has published a formal statement against it.

So asking a supplier how their device measures up against these principles is a fair procurement question. Still, verifying the answer independently is what IoT penetration testing is for.

Why a single weak device matters more than it looks

A camera or a meeting room panel rarely holds sensitive data itself, which is exactly why it gets overlooked. The real risk is what a compromised device hands an attacker next. So a camera with root-privileged services and a remote code execution flaw stops being just a camera at that point. Instead, it becomes a foothold on the same network segment as your file servers, staff laptops and everything else behind the office firewall.

Government testing keeps surfacing the same pattern. The weak point is rarely the server everyone already watches closely. It is the device nobody thought needed watching at all, quietly running years-old firmware in the corner of the network.

Scoping it properly

The risk spans hardware, firmware and network layers, so scope for IoT penetration testing needs to reflect that. Decide upfront whether physical access to a sample device is included. Also decide whether the companion mobile app and cloud backend are in scope. And confirm whether firmware extraction is expected as part of the work. A test that only probes the network side of a device will miss most of what goes wrong with connected hardware. That defeats the point of commissioning one at all.

This is exactly the conversation a scoped engagement should start with. At Aardwolf Security, working out which layers of your connected devices genuinely need testing comes before any quote goes on the table. If your business runs cameras, sensors or similar equipment, and PSTI compliance is your only assurance so far, get in touch. We can talk it through.

Frequently asked questions about IoT penetration testing

If a device is PSTI compliant, do I still need to test it?

Yes. PSTI sets legal minimums such as banning default passwords and requiring update transparency. It does not test for hardcoded credentials, weak update signing or wireless pairing flaws. Government-backed testing has found exactly these problems on real enterprise devices.

What is the difference between a network scan and an IoT penetration test?

A scan checks what a device exposes over the network, nothing more. An IoT test adds hardware analysis, firmware extraction and wireless protocol testing on top. These are layers a scan simply cannot reach.

Which devices carry the most risk in a typical office?

Cameras, VoIP phones, network storage and meeting room panels are common culprits. They tend to run for years without the patching routine a laptop or server gets by default.

Does the manufacturer or the business own responsibility for security here?

Both, in practice. Manufacturers carry PSTI obligations under the law. But the business deploying the device is the one that suffers the breach if a flaw goes untested. That is why independent testing still matters, regardless of what the supplier claims.

How do I start if I have never tested connected devices before?

Begin with an inventory of what is actually connected to your network. Then prioritise the devices with the highest access, or the most sensitive data sitting behind them, for the first round of testing.

Can a supplier’s PSTI statement replace independent testing?

No. A statement of compliance tells you what the manufacturer claims. It does not tell you what an attacker would actually find. Independent testing is the only way to verify the claim rather than take it on trust.