TL;DR
- EN 303 645 is a useful baseline for consumer IoT security, but it is not a replacement for threat modelling, engineering assurance, or practical testing.
- Our EN 303 645-aligned assessments most frequently find shortcomings in secure storage, secure communications, default credentials, input validation, software updates, and exposed attack surfaces.
- Some of these are quick fixes. Others are platform-level design decisions that become very painful to change late in the product lifecycle.
- The standard helps. But it works best when manufacturers treat it as the floor, not the ceiling.
Why EN 303 645 matters
ETSI EN 303 645 has given consumer IoT security a much-needed baseline. It gives manufacturers, assessors, and product teams a shared view of reasonable IoT security and something concrete to work against. But after years of assessing products against it, one thing is clear: passing the standard is not the same as building a secure product.
It is possible to build something secure that does not neatly comply with EN 303 645. It is also possible to build something that complies, but still leaves important risks unresolved. That is where practical testing and threat modelling come in.
What EN 303 645 is trying to do
EN 303 645 focuses on 13 main cybersecurity provisions for consumer IoT products. In plain English, the standard says IoT systems must:
- Use no universal default passwords
- Have a way to receive and manage vulnerability reports
- Do secure and manageable software updates
- Store sensitive security parameters in a secure way
- Secure communications
- Minimise attack surfaces
- Ensure software integrity
- Protect personal data
- Be resilient to network/power outages
- Monitor telemetry data for security events
- Enable easy deletion of user data
- Be easy to install and maintain
- Validate input and output data
If I had to write a dozen IoT security controls from scratch, I’m not sure I’d do a much better job!
The challenge is that IoT is too varied for any standard to fit perfectly. Most of the provisions in the standard use terms such as “best practice”, “timely”, “appropriate to the technology”, or “where possible”. A connected thermostat, a router, a BLE sensor, and a battery-powered LoRa device do not all have the same constraints or risk levels. What will be appropriate to meet the standard for each?
The answer is typically consultantish: it depends.
This terminology means you still have to think independently about security. Typical decisions you’ll need to make could include:
- What counts as good practice for local HTTPS management interfaces?
- What is an acceptable level of security for a temporary Bluetooth provisioning interface?
- What support period is reasonable for a long-life battery-powered sensor?
- What data should count as sensitive in the context of a connected coffee machine?
Thinking about and agreeing on these is hard for a business to do.
Where products most often struggle
We often test products late in development, where manufacturers are trying to finish security work before launch. That gives us a useful view of the problems showing up at crunch time.
Across recent EN 303 645 and EN 303 645-aligned assessments, the weakest areas were:
- Secure storage.
- Secure communications.
- Default universal passwords.
- Input validation.
- Software updates.
- Attack surface reduction.
The areas with relatively few findings were:
- Resilience
- Data deletion
- Installation or configuration guidance
That does not mean those areas are always easy. In some ecosystems, data deletion is a genuinely challenging problem. But the most common technical findings were elsewhere.
Secure storage: “We encrypt it… mostly”
Most products had made an attempt to protect stored data, but we still see sensitive data stored in unencrypted secondary flash chips. This surprised us when the standard was coming in, but we believe this is a knock-on effect of other provisions which require firmware and secrets to be separate. There’s therefore a drive to keep data like configuration settings and Wi-Fi credentials somewhere outside the main firmware flash.
This data has typically been landing on external flash, which some manufacturers have then been struggling to secure. Even for complex BGA packages and eMMC chips, we can still remove and read them directly to get at these secrets.
We’ve also seen sensitive data staged in flash during updates but not being deleted after use. For systems with a full operating system weak permissions on credential files can put secrets at risk.
The final area we have been breaking secure storage is debug interfaces. This has mostly been a result of open debug (usually JTAG or SWD) access allowing flash access but has also included leakage of secrets via management applications or secondary modules such as modems, which may store secrets such as Wi-Fi passwords.
So, secret handling is not one feature. It’s a product architecture problem.
For smaller systems with a single app or RTOS, hardware-backed storage and secure boot underpins an effective approach. This will lay a foundation to protect external flash and other components using the main MCU as a root of trust for encryption etc.
If you are dealing with a full operating system, the problem does not disappear. Permissions, services, local management interfaces, and update mechanisms all become part of the same security story.
Consider where data goes (including to other MCUs/modules) and what protection it benefits from in each place. A product can have “some storage protection” and still fail badly in practice.
Secure communications: death by a thousand TLS cuts
Most devices now try to secure communications. That is progress, but it is still easy to get wrong.
Almost all communications we care about will be secured with TLS. We see two main classes of failures in this area:
- TLS configuration weaknesses, which are typically very hard to exploit (I.e. low risk) but are a compliance risk.
- Total TLS failures, usually because embedded TLS clients are failing to validate server certificates
We also see related issues such as HTTP left available without redirecting to HTTPS.
Grey areas in this provision include wireless encryption, in particular LoRa and Bluetooth. These can both be protected with Pre-Shared Keys (PSKs) which enable machine to machine encryption. These keys can sometimes be leaked or guessed.
There’s also a common approach manufacturers take, which involves encrypting data at the application layer to reduce the risk of e.g. unpaired and unencrypted Bluetooth. That creates a compliance problem if the underlying channel is still unencrypted or unauthenticated. Likely having to make a case that your own cryptographic implementation is good enough.
Another risk management approach often used is to make the case that unpaired Bluetooth is only used during a point-in-time provisioning flow. That may be true, but it needs to be documented and justified.
This is where EN 303 645 forces a useful conversation. It does not always give a perfect answer, but it does make teams think about what they are doing and why.
Default passwords: not just a password policy issue
Many manufacturers now understand that universal default passwords are a problem.
But we still see failures around maintenance backdoors (usually common across devices), third-party packages that introduce their own credentials, and devices using shared credentials ‘underneath’ channels which use shared device authentication.
That last one is often decoupled authentication. A common example is a shared VPN key protecting access to an API that then uses per-device authentication. This is still risky because of the potential for weird use cases such as using a VPN key to enable device to device communication.
This class of threat can also apply to message queues/brokers, cloud based application gateways, cellular networks, or it can just exist at the application layer where an application level key is used to forward user requests with a separate authentication secret.
An honourable mention also to the default web UI credentials we saw exposed in client-side JavaScript!
Machine-to-machine authentication is still a difficult area in many ecosystems, especially where legacy APIs or constrained technologies are involved.
The wider point is that secret handling failures are broader than password policy failures. Most of these failures happen because the full authentication scope was not clear. The main product flow may follow good practice, while maintenance channels or supporting services fall outside it.
Input validation: often left too late
Input validation is one of those areas that is easier to test than it is to design and implement.
We find a lot of input validation issues and a lot of them are in web based interfaces. Sometimes this leads to injection on management interfaces. SQL injection and command injection still happen in 2026, but they are not the only failure mode. If we can cause an error condition by sending malicious inputs, that’s going to class as an input validation error. That gives attackers a very low bar to clear.
We see that data flowing from web apps or mobile apps to devices is commonly trusted and vice versa. Similarly radio frames, USB, and Bluetooth are treated as “not really user input”, but local attackers can supply input to them, so they’ll need protecting too.
We have had one system where NFC card contents was reflected back into an unrelated function in firmware because it was bounced back to the device via the API. This is why input validation kind of needs to be everywhere to be effective in complex systems.
We often see devices trust data from web or mobile apps, and those apps trust the device in return. A web UI might be locked down, while the underlying API accepts unexpected input. A USB interface might be present for legitimate service reasons, but still expose a complex stack that can be crashed by fuzzing it.
Input validation should be tested early and often. Fuzzing late in the process tends to find things when they are more expensive to fix. Developers looking for a practical starting point may find The Fuzzing Book useful.
Software updates: not always secure
Most devices we assessed had some form of update mechanism, it’s unusual to see systems that go for exemption in this area.
That does not mean the update mechanism was secure. Common issues included no automatic update capability, rollback being possible, manual update mechanisms being weaker than online update flows, weak signing algorithms, signatures being ignored or improperly checked, and time-of-check to time-of-use issues.
This is one of the areas where design decisions matter early. If secure boot is not supported, update security becomes harder. If rollback protection was not considered, fixing it later may be painful. If manual update paths were built separately, they may not receive the same protection as online updates.
Update security also depends on process and infrastructure. In particular you’ll need the tools to deploy, manage, revoke and rotate cryptographic secrets at scale. You’ll need plans for when certificates, keys or similar can no longer be trusted.
If that is not built in from the start, teams may need to bootstrap stronger controls into a weaker product. That bootstrap process also needs protecting.
That is a lot to retrofit, we can’t recommend enough getting this in place early.
Attack surface reduction: the usual suspects
Attack surface reduction has been a product security topic for years, and it is still not solved because it *has* to be risk based.
We still see exposed SSH on customer networks, open debug interfaces, open Bluetooth interfaces, default or known pairing PINs, and provisioning modes that remain available after they should have closed.
Debug interfaces are particularly important. An open JTAG or SWD interface on the main MCU is usually a direct problem. Debug interfaces on a secondary MCU or module can be variable, communications could be higher risk, but an MCU used for direct control of IO is less likely to be impactful. Either way, leaving the component with an open attack surface will be a compliance risk.
The safest approach is to decide early to build systems up rather than attempt to minimise already ‘large’ systems. For example it’s ‘easier’ to minimise a Yocto Linux build than an Ubuntu one. You also need to adopt the principle that available security features will be used wherever possible.
Turn off what is not needed, authenticate what must remain, restrict less used states (such as provisioning) to the time period they’re actually needed. Avoid unnecessary software. Use least privilege where the platform allows it. Enable memory protection features where available.
These things are much easier to design in than to bolt on later.
What tends to get fixed
When we retest, we often see high-risk, small-scale bugs get fixed.
Several types of issues tend to be fixed with fairly minor firmware releases, these include:
- Input validation issues
- Small scale access control problems (as in affecting a small scope, as opposed to a total absence of access control)
- Small scale information disclosure issues
- Certificate validation and TLS issues that can be fixed with TLS client/server configuration updates
There is another class of issue that may not be fixed intentionally, but get an ‘accidental’ fix when secure boot is deployed. That includes many credential and secret disclosure issues, unencrypted primary flash problems, firmware validation weaknesses, and some attack surface reduction problems.
Secure boot is not fairy dust. It does not solve everything. But in IoT, it often underpins several other controls.
What does not tend to get fixed
The difficult issues are usually platform issues. For example:
- The server platform we chose does not natively support certificates
- The MCU we chose does not support secure boot
There are also issues that arise because of design decisions, these issues are more likely to stay open and may include:
- The principle of least privilege being applied incrementally, but never quite being ‘complete’.
- Firmware downgrade protection remaining unsupported.
- Bluetooth provisioning services remaining unpaired and/or permanently open.
This is the danger zone. By the time these issues appear in a late-stage security assessment, the product may already be too far through development for clean fixes. Teams then end up choosing between redesign, compensating controls, risk acceptance, or awkward exceptions.
Testing cannot prove everything
Testing is necessary, but it has limits.
A tester can review firmware, interfaces, storage, update mechanisms, and communications. They can find exposed passwords, insecure protocols, weak validation, and dangerous debug access.
But testing cannot fully prove that something is absent from source code. It also cannot prove, on its own, how telemetry is reviewed or how vulnerability reports are handled across organisational boundaries. It cannot give 100% coverage of every encoding scheme, process, or input a device has.
In other words, EN 303 645 testing is often trying to prove a negative. Just like functional testing. That needs support from wider engineering assurance, we can ask the questions and get as many answers as possible, but owner/operators still need to play their part before, during and after the assessment to be successful.
That part includes ensuring that the right work is done and documentation created. This spans design documentation, secure development processes, software bills of materials, vulnerability management processes, update policies, and evidence that decisions were made deliberately.
What to do about it?
The standard tells you a lot, but it can’t tell you everything that matters for your product, your users, your use case. So… use the 13 provisions as baseline controls. Then do some product-specific security thinking. The industry’s posh name for this is ‘threat modelling’.
Threat modelling does not need to be perfect to be useful. A one-hour session with the right engineers can reveal design assumptions that would otherwise remain buried until testing. To do this we ask ourselves four questions:
- What are we building?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
Simple, but powerful. EN 303 645 can tell you what baseline controls should exist. Threat modelling helps you understand whether those controls are enough for the product you are building.
If the standard controls don’t satisfy you that the risk is managed, you can add more.
That is the difference between compliance as a paperwork exercise and security as an engineering discipline.
Final thoughts
EN 303 645 has helped move consumer IoT security in the right direction. We are seeing more products take their first pass against the standard and manufacturers engage with security earlier.
But the findings we keep seeing are a reminder that the hard problems are still hard.
Treat EN 303 645 as your baseline controls, start with threat modelling. Fill any control gaps you find early. Test and fuzz early. Make platform security decisions early. Document your decisions.
Then… do it all again. But don’t worry the first time round is by far the hardest.
