Quick summary
Testing connected products is fundamentally different from testing software. Hardware variability, firmware lifecycles, network conditions, and regulatory exposure all combine to break the assumptions that traditional QA relies on. McKinsey estimates the IoT could generate $5.5 to $12.6 trillion in global economic value by 2030, but capturing that value depends on a quality approach that the typical software testing playbook cannot deliver.
Most modern QA practices were designed for software that runs on predictable hardware in well-defined environments. A web app behaves consistently across most browsers. A backend service can be containerised and tested in isolation. The variables are bounded, and the test environment is largely under the team's control.
Connected products break that assumption. A single IoT device can run firmware on constrained hardware, talk to a cloud platform over an unstable cellular link, integrate with third-party systems via a mix of protocols, and operate in physical environments the test lab cannot reproduce. This article looks at why traditional QA falls short for connected products, where the real risks sit, and what an IoT-grade quality approach requires.
The IoT market has matured well beyond the smart speaker era. McKinsey estimates that the IoT could generate $5.5 trillion to $12.6 trillion in global economic value by 2030, with B2B applications accounting for roughly 65 percent of that total (McKinsey, 2021). Connected products are now central to manufacturing, energy, healthcare, automotive, and smart-building strategies across Europe.
That growth has changed the consequences of poor quality. A bug in a consumer web app is a frustration; a bug in a grid-connected energy device is a safety, financial, and regulatory event all at once. Connected products are subject to overlapping regulations including the EU Cyber Resilience Act, NIS2, the Radio Equipment Directive, and sector-specific frameworks like ISO 26262 for automotive and EU MDR for medical devices.
In Nordic, DACH, and Benelux markets, where connected energy systems and industrial IoT deployments are particularly dense, the regulatory exposure is even sharper. The combination of safety-critical hardware and tightening EU rules means QA failures translate directly into commercial and legal risk, not just user dissatisfaction.
Takeaway: Connected products operate where software, hardware, networks, and regulation all intersect, raising both the stakes and the standards of QA.
Traditional QA assumes that the system under test is consistent, observable, and reproducible. Connected products break all three assumptions at once.
Common gaps include:
Hardware variability that makes "the same test" produce different results across device units
Firmware behaviour that depends on memory limits, power states, and boot conditions software testers rarely simulate
Network conditions that vary by location, carrier, and signal strength rather than by configuration
Long device lifecycles, often 10 to 15 years, that require backward-compatible testing for firmware updates
Physical environment factors such as temperature, vibration, and electromagnetic interference
Sensor drift and calibration changes that emerge only after months in the field
Industry research highlights how often these gaps cause project failure. Gartner has reported that around 75 percent of IoT projects face significant schedule overruns, with testing complexity cited as a leading cause. The issue is not that traditional QA teams lack skill; it is that the methods they trained on were designed for a different category of product.
Takeaway: Traditional QA assumes consistency and reproducibility that connected products simply do not offer.
Connected products fail in ways that pure software products do not. Understanding the risk surface is the starting point for designing testing that actually catches the failures that matter.
Five categories of risk dominate.
Security. Each connected device is an entry point into a wider network. McKinsey's research on IoT cybersecurity finds that approximately 80 percent of IoT providers now embed security into their products in some form, but that bolt-on approaches consistently underperform compared to security designed into the device from the silicon up (McKinsey, 2023).
Interoperability. Devices from different manufacturers, running different protocols, must coexist on shared networks. McKinsey estimates that interoperability is required for around 40 percent of the total potential value of IoT applications, meaning a device that works perfectly in isolation can still fail to deliver business value in the real world (McKinsey, 2021).
Firmware integrity. Connected products receive updates over the air for years after release. Each update is a potential failure point, and rollback capacity is rarely as robust as in cloud software.
Field conditions. Lab environments rarely replicate the temperature extremes, intermittent connectivity, and physical wear that affect deployed devices.
Compliance traceability. Regulators increasingly demand reproducible evidence that testing occurred, what it covered, and what the results were. Manual testing notes do not satisfy this requirement at scale.
Takeaway: The risks that matter most for connected products live at the intersections of hardware, network, firmware, and regulation.
Effective QA for connected products is layered, not linear. It tests at every level of the stack and continues into the device's operational life rather than ending at release.
A mature IoT QA approach typically includes:
Hardware-in-the-loop testing that exercises real devices, not just simulators
Network simulation that introduces latency, packet loss, and intermittent connectivity
Firmware update and rollback testing across multiple device generations
Security testing aligned to the EU Cyber Resilience Act, including penetration testing and vulnerability disclosure procedures
Interoperability testing against the protocols and platforms the device will encounter in the field
Field telemetry and remote diagnostics that detect issues after deployment
Compliance evidence pipelines that produce audit-ready documentation automatically
The shift is from "did the code work?" to "does the device work, in this environment, against these regulations, across its full lifecycle?" That broader scope is why IoT QA cannot be retrofitted onto a traditional software testing function; it requires a different organisational design from the start.
Takeaway: IoT-grade QA is layered across the stack and continues throughout the device's operational life.
European regulation has moved decisively from voluntary guidance to mandatory requirements for connected products. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, applies to virtually all products with digital elements placed on the EU market, with full obligations applying from 11 December 2027 and earlier reporting obligations from 11 September 2026 (European Commission, 2024).
Manufacturers must demonstrate that security has been engineered into the product from the design stage, document vulnerabilities, and maintain coordinated disclosure throughout the lifecycle. Penalties for non-compliance can reach €15 million or 2.5 percent of worldwide annual turnover (EY, 2025). For most connected-product manufacturers, this level of exposure cannot be addressed through release-time testing alone; it requires continuous, traceable QA across the product's full lifecycle.
NIS2, the Radio Equipment Directive, ISO 27001, ISO 26262, and EU MDR add further requirements depending on the product category. The common thread is that all of them now expect evidence, not assurances. Testing that produces no audit trail is testing that, from a regulatory standpoint, did not happen.
Takeaway: EU regulation now treats traceable, lifecycle-long testing as the baseline expectation for connected products.
There is no single template for IoT QA, but the strongest approaches share a few common principles.
Practical building blocks include:
Aligning testing scope to product risk, not to development methodology
Investing in hardware-in-the-loop infrastructure early, before scale exposes its absence
Treating firmware update mechanisms as first-class test targets, not an afterthought
Building security testing into CI/CD pipelines rather than treating it as a separate phase
Designing compliance evidence as a by-product of testing, not a separate documentation effort
Extending QA responsibility into the deployed fleet, with telemetry feeding back into test design
McKinsey's research on IoT value capture is direct on this point: companies that build IoT systems with security and quality from the ground up consistently outperform those that bolt these capabilities on later (McKinsey, 2021). The implication for QA strategy is that the testing approach must be designed alongside the product, not adapted afterwards.
Takeaway: IoT QA capability is built deliberately, not assembled from the software testing playbook with a few additions.
Connected products are not just software running on devices. They are integrated systems of hardware, firmware, networks, cloud services, and physical environments, all operating under tightening EU regulation and customer expectations of years-long reliability.
The traditional software QA playbook was not designed for that complexity, and stretching it to fit consistently produces gaps in the places where the consequences matter most. The right approach starts from the recognition that connected products demand a different category of quality assurance, designed for the realities of hardware, firmware, networks, and regulation, not adapted from the assumptions of pure software.
For European manufacturers operating under the EU Cyber Resilience Act, NIS2, and sector-specific regulations, that recognition is no longer optional. It is the baseline for staying in the market.
IoT testing covers hardware variability, firmware update mechanisms, network conditions, physical environment factors, and long device lifecycles, none of which apply to pure software testing. It also requires evidence of testing across the product's full lifecycle, not just at release.
Connected devices are entry points to wider networks, and the EU Cyber Resilience Act now requires manufacturers to identify, document, and disclose vulnerabilities across the product lifecycle, with penalties of up to €15 million or 2.5 percent of global turnover for non-compliance.
Not without adaptation. IoT QA requires new infrastructure (hardware-in-the-loop labs), new skills (firmware, security, network simulation), and new processes (lifecycle-long testing and audit-ready evidence pipelines) that traditional software QA teams typically do not have in place.
The CRA requires manufacturers of products with digital elements to perform security risk assessments, implement security testing throughout the product lifecycle, document and disclose vulnerabilities, and maintain compliance evidence for audit. Full obligations apply from 11 December 2027.
Connected products typically have lifecycles of 10 to 15 years, and EU regulation now expects testing and vulnerability handling to continue across the full support period, not just up to launch.