Wireless IoT security used to be a nice-to-have, mentioned in product documentation as a reassurance and rarely scrutinised in any depth. That era has ended.

Procurement teams at enterprise customers, government buyers, building system integrators, and increasingly even consumer retailers now ask for specific evidence of security testing before they will buy. Standards such as ETSI EN 303 645 have moved from advisory documents to procurement criteria, and the PSA Certified framework is on the same trajectory. A wireless product without a defensible security testing story is, in a growing number of markets, simply not a viable product.

This article is about what those standards actually require in concrete engineering terms, why automated security testing is the practical way to meet those requirements continuously rather than as a one-off pre-release scramble, and how to build a security test suite that doubles as the audit evidence procurement teams now demand.

cover108

The shift in IoT security expectations

To understand why this topic deserves dedicated attention, it helps to recognise the structural shift that has happened in IoT security expectations over the past few years. For most of the IoT market’s history, security was implicit. Vendors shipped products with whatever security their development teams thought was reasonable. Buyers assumed the security was adequate, because they had no practical way to evaluate it. The market operated on trust, and the trust was occasionally violated by high-profile breaches that everyone agreed were bad without anyone agreeing on what specifically should have been done differently.

That equilibrium has broken down for several reasons at once. Regulators have started taking IoT security seriously, with the EU Cyber Resilience Act being the most prominent recent example but far from the only one. Insurance companies have begun pricing IoT security risk explicitly, which means buyers face direct financial consequences if they buy products with weak security. Procurement processes at large organisations have added security review as a standard gate, which means even routine purchases now require evidence that did not previously need to exist. And consumer awareness has risen to the point where security-related news affects sales in ways it did not five years ago.

The cumulative effect is that the IoT vendor market is bifurcating into products that have specific, demonstrable security properties and products that do not. The former are increasingly the only ones that pass procurement. The latter are increasingly excluded from the segments where margins are healthy. This is not yet a complete shift — there are still markets where security is a tiebreaker rather than a gate — but the trajectory is clear, and the timeline for adapting is shorter than most teams realise.

What ETSI EN 303 645 actually is

The standard most often cited as the baseline is ETSI EN 303 645, formally titled “Cyber Security for Consumer Internet of Things: Baseline Requirements.” Despite the “consumer” framing, the standard is increasingly applied beyond consumer products, and its requirements are widely treated as the floor for any IoT device that wants to be procurement-credible.

The standard is structured around thirteen high-level provisions, each of which contains specific requirements. Some of the provisions are organisational rather than technical — having a vulnerability disclosure policy, providing security updates for a defined period, being clear about which support timelines apply — but several are direct engineering requirements that translate into testable properties of the firmware. Understanding which is which is the first step to translating the standard into a test plan.

The most directly testable provisions concern authentication and credential management, secure communication, secure software updates, integrity protection of the firmware itself, and resilience to common attack patterns. These are not vague aspirations. The standard specifies, for example, that default passwords should be unique per device or require user setup before the device becomes operational. That communications carrying sensitive data should be encrypted with cryptographically secure algorithms. That firmware updates should be verified for authenticity before installation. That the device should be resilient to outages and to specific classes of attack.

Each of these requirements maps onto a specific test case. A device that has unique-per-device default passwords is one whose credentials can be verified to vary across units. A device with secure firmware update is one that can be verified to reject signed-with-wrong-key updates. A device that resists protocol-level attacks is one that has been tested against malformed inputs in the categories the standard cares about. The standard’s structure makes the test plan largely self-writing once you have read it carefully.

The PSA Certified framework operates similarly, with a different organising principle but a substantially overlapping set of technical requirements. A test suite designed against ETSI EN 303 645 typically covers most of what PSA Certified asks for, and vice versa. For most teams, the question is not which standard to align with but how to build a test suite that satisfies both, plus whatever specific customer requirements come up in procurement reviews.

The categories of security tests that matter most

Once you accept that security testing needs to be systematic rather than ad-hoc, the question is what specifically to test. The categories below are not exhaustive, but they cover the requirements that most procurement processes specifically probe and that map most directly onto the standards.

Authentication and credential security is the first and most universally tested category. The test suite should verify that devices reject authentication attempts with incorrect credentials, that authentication failures are logged and rate-limited, that credentials cannot be extracted from the device through any exposed interface, and that the credential management mechanisms work correctly under all the conditions the device can encounter. Bugs in authentication are among the most damaging classes of security defects, and they are also among the easiest to test for once you have a controllable test peer.

Secure communication is the second category. For wireless products, this means verifying that the wireless protocol’s security mechanisms — pairing, encryption, key exchange, key refresh — function correctly. Tests should cover normal operation, edge cases such as concurrent procedures, and adversarial conditions such as attempts to downgrade the security level or to substitute keys. The protocol-specific security tests are often the most complex part of the suite because they require deep familiarity with the protocol’s security architecture, but they are also among the most important because they protect the data that flows during normal operation.

Replay attack protection is the third category, and it deserves its own attention because replay attacks are one of the most common and damaging attack patterns against wireless devices. The test suite should verify that messages cannot be replayed effectively — that captured traffic, when replayed later, is correctly rejected by the device. This typically involves a test peer that captures legitimate traffic during one phase of the test and replays it during a later phase, with the device’s response observed and verified. Replay protection bugs have shown up in shipped products often enough that any rigorous security review will probe for them specifically.

Firmware integrity and secure boot is the fourth category. Tests in this category attempt to deploy modified firmware images and verify that the device rejects them at the appropriate verification stage. Variants include images with corrupted signatures, images signed by the wrong key, images with valid signatures but unauthorised content modifications, and images that exploit specific weaknesses in the bootloader’s verification logic. The goal is to confirm that the chain of trust from secure boot through firmware update is unbroken, with no bypass paths that an attacker could exploit.

Resilience under hostile conditions is the fifth category. This covers the device’s behaviour when it encounters protocol-level attack patterns: malformed packets at high rates, deliberately constructed inputs designed to exploit parser bugs, resource-exhaustion attempts, and other denial-of-service-style attacks. The device should remain operational, or fail gracefully and recover automatically, under all these conditions. Bugs in resilience handling tend to manifest as crashes, hangs, or undefined-state issues that are operationally damaging even when they are not directly exploitable.

Information disclosure is the sixth category, and it is more subtle than the others. The test suite should verify that the device does not leak sensitive information through side channels: timing differences that reveal the validity of credentials, error messages that distinguish between different failure modes in security-relevant ways, debug interfaces that expose internal state, or accessible diagnostic features that reveal information attackers could use. These bugs are hard to find by inspection but can be probed systematically with the right test infrastructure.

These six categories cover most of what the standards require and most of what procurement security reviews probe. A team building security test coverage should work through them systematically, ensuring that each category has tests against each protocol procedure and each interface the device exposes.

background image for partnerships

How automation makes this practical

The argument for automating security testing is essentially the argument for automating any kind of testing, but with some specific reinforcement that comes from the nature of security work.

The first reinforcement is that security tests need to run continuously to catch regressions. A security property that is verified once before release is a property that nobody knows about during development. A change to firmware months after the verification can silently break the property, and the next verification — if it happens at all — will find the regression long after the original change. Automated security tests in CI catch these regressions on the day they are introduced, which is when fixing them is cheapest and easiest.

The second reinforcement is that security tests are often non-trivial to construct. The test that verifies replay protection requires a peer that can capture, store, and replay protocol traffic at controlled moments. The test that verifies signature rejection requires a way to construct deliberately-invalid signatures. The test that probes timing-based information disclosure requires precise measurement of response times across many trials. Building these tests well takes engineering effort, and that effort is wasted if the tests only run occasionally. Automating them ensures that the engineering investment compounds across every run.

The third reinforcement is that security testing produces evidence that auditors and procurement teams care about. A test suite that runs automatically, logs results, and produces reproducible artifacts is exactly the kind of evidence security reviewers ask for. The same suite that protects the firmware from regressions also satisfies the audit requirements of customers who need to verify the security claims. The compliance dimension and the engineering dimension of automated security testing are not separate activities — they are the same activity, viewed from different angles.

The fourth reinforcement is that security test infrastructure is genuinely reusable. A controllable test peer that can perform replay attacks against one product can perform them against the next product the team builds. A signature-rejection test framework that works for one bootloader works for the next one with modest adaptation. The investment in security testing infrastructure pays off across multiple products, which makes it a particularly attractive engineering investment for teams shipping more than one wireless product.

The audit and evidence dimension

It is worth dwelling specifically on the audit dimension, because it is what makes security testing different from other categories of testing in an important commercial sense. Procurement security reviews increasingly ask not just whether the device has been tested but how, against what specific requirements, with what specific results. The form of the answer matters as much as the substance.

A test suite that runs in CI, logs structured results to a database, produces reproducible artifacts, and maps tests to specific requirements in the relevant standards is well-positioned to satisfy these reviews. The auditor or procurement reviewer can see exactly which requirements are tested, exactly how they are tested, exactly what the results have been across recent runs. This kind of evidence is far more persuasive than a one-off security report from an external consultant, because it is continuous, current, and reproducible.

The discipline that produces evidence-grade results is mostly about traceability. Each test should reference the specific requirement it verifies. The test results should be retained over time, not overwritten with each run. The test methodology should be documented in enough detail that an auditor can follow it. The set of tests should be reviewed periodically against the standards to ensure new requirements are added as standards evolve.

This discipline pays off twice. First, it satisfies the procurement reviews that gate sales. Second, and just as importantly, it disciplines the team’s own security practice. A team that maintains traceability between tests and requirements has a much clearer view of its own security posture than one that just runs tests and trusts the results. The traceability discipline is a forcing function for thinking carefully about what is actually being verified, which improves the quality of the verification.

decorative image

A capability that compounds with regulation

The trajectory of IoT security regulation is, as far as anyone can tell, unidirectional. The EU Cyber Resilience Act adds requirements. The proposed updates to ETSI EN 303 645 add detail. The PSA Certified framework adds levels. National-level regulations in major markets continue to multiply. A team that treats security testing as a checkbox to be ticked once before each release will spend ever-increasing time and effort on these checkboxes, because the surface keeps expanding and each new requirement creates a new checkbox.

A team that has built automated security testing infrastructure, by contrast, spends a fixed and modest amount of effort per requirement once the infrastructure is in place. Adding a new test for a new requirement is a matter of writing the test, not building the infrastructure to run it. As regulations evolve, the team that has invested in automation absorbs the changes incrementally; the team that has not falls progressively further behind, until the gap is large enough to threaten market access.

This is the strategic dimension of security testing investment. It is not just about meeting today’s requirements. It is about positioning the team to meet whatever requirements come next, with infrastructure that supports continuous adaptation rather than periodic scrambles. For products with multi-year lifecycles in markets where security regulation is intensifying, this positioning is increasingly the difference between products that remain viable and products that quietly become unsellable.

The teams that recognise this trajectory early and invest accordingly gain a sustained advantage in regulated markets. The teams that wait until customers start failing to renew because of compliance gaps face the much harder problem of building the infrastructure under deadline pressure, while simultaneously addressing the immediate compliance issue that triggered the realisation. The earlier the investment, the more it pays back.

For wireless IoT products that intend to compete in markets where security is increasingly non-negotiable, automated security testing is no longer optional. It is the foundation of a defensible security story, and a defensible security story is increasingly the foundation of a viable product.

needCode designs and delivers automated security testing infrastructure for wireless embedded products, mapped against ETSI EN 303 645, PSA Certified, and customer-specific procurement requirements. We have built security test programmes across BLE mesh, LTE-connected IoT, and multi-protocol embedded engagements. If your security testing currently consists of pre-release scrambles and external audits, we are happy to talk about what continuous, automated coverage would look like for your product.

Book a free discovery call or get in touch

Further reading