Connected product security testing combines technical probing with structured assessment against recognised frameworks. Laboratory evaluation tests firmware, communication channels, authentication mechanisms and data handling under deliberate attack, then maps results to standards such as ETSI EN 303 645 and IEC 62443.
Scope and targets
Scope definition comes before any test activity. It determines everything downstream. The target set covers networked devices and their supporting components. These include firmware images, mobile or cloud companion applications, communication interfaces, and the hardware platform itself.
Boundary setting must state which interfaces are in scope. These may be Wi-Fi, Bluetooth, Ethernet, cellular, or debug ports such as UART and JTAG. It must also state which backend services fall within the engagement. Some products ship with physical infrastructure. One example is structured cabling covered under Cabling Products Testing. In that case, the logical security of data passing over the infrastructure stays in scope, even though the cable qualification itself does not.
Each target receives an identifier, a firmware version record, and a configuration snapshot. This lets results be traced to an exact build state. Out-of-scope elements are documented explicitly. This prevents ambiguous conclusions at the reporting stage.
Test items and sample preparation
Sample preparation for connected products differs from physical compliance work. The laboratory needs functioning units, firmware binaries, companion applications in installable form, user documentation, and where available, developer debug access.
Typical test items include:
- Firmware analysis — static extraction and reverse engineering of binary images
- Interface and port scanning
- Authentication and session management testing
- Cryptographic implementation review
- Update mechanism verification
- Data storage inspection
Preparation steps include recording factory default credentials and capturing baseline network traffic in a controlled environment. A sandboxed test network is established and isolated from corporate systems. Devices are reset to a known state before each test cycle. All credentials, certificates, and configuration files are inventoried.
Some devices are camera or doorbell types. For these, the procedures described under Cybersecurity Risks Presented by Smart Security Devices Testing show how these same items apply to a specific risk class.
Test methods and execution procedure
Execution proceeds in phases.
Reconnaissance. Port scanning and service fingerprinting enumerate the exposed attack surface.
Firmware assessment. Binwalk-style extraction, disassembly, and string analysis locate hardcoded keys, default passwords, and outdated library versions.
Dynamic testing. Manual and tool-assisted techniques are applied. Traffic interception through a proxy inspects transport encryption. Commands are replayed and modified. Brute-force and dictionary attempts are run against login functions. The over-the-air update path is tested for signature verification.
Hardware testing. Debug interfaces are probed for unauthenticated memory readout using common programmer tools.
Companion applications. Static analysis covers packaged binaries. Dynamic inspection covers local data storage.
Each finding is reproduced at least twice. It is evidenced with packet captures, screenshots, or extracted artefacts. Deviations from the planned method — for instance an unreachable service — are logged rather than silently skipped. The final report therefore reflects what was actually exercised.
Vulnerability
assessment metrics and acceptance criteria
Findings are graded on two axes: severity and exploitability. Severity reflects impact on the confidentiality, integrity, or availability of data or device function. Exploitability reflects the skill, access, and tooling an attacker would need.
A common grading scale runs from critical (remote unauthenticated code execution or full control) through high, medium, and low to informational observations.
Acceptance criteria should be agreed befOre testing begins. Typically, no critical or high findings may remain open at shipment. Medium findings require a documented remediation plan. Low or informational items may be tracked for future releases.
Vulnerability age also matters. A weakness with a published public exploit is treated more strictly than an equivalent theoretical flaw.
Retesting after vendor patches closes the loop. The laboratory repeats only the affected test cases plus regression checks on adjacent functions. It then confirms whether each finding is resolved, partially resolved, or unresolved.
Applicable standards and frameworks
Several frameworks anchor connected-product security evaluation.
ETSI EN 303 645 defines baseline requirements for consumer IoT. It covers default passwords, update policy, data protection, and secure communication. The UK PSTI regime and comparable national legislation reference such baselines for market access.
IEC 62443 applies to industrial automation contexts. It grades security capabilities by zone and conduit.
NIST frameworks and the OWASP IoT and Mobile Application Security Testing Guides supply method-level guidance for individual test techniques.
Common Criteria evaluation addresses supplier supply-chain integrity for more formal assurance programmes. This is examined in depth in An Anatomy of an O-TTPS Third-Party Assessment Testing.
The right combination depends on product category, target markets, and the engagement purpose. That purpose may be development hardening, regulatory compliance, or third-party attestation. A well-scoped project states the framework mapping of every test case. Each result then lands against a specific requirement.
Application scenarios and reporting
Application scenarios span pre-development gap assessment, pre-release verification, regulatory market-entry submissions, and post-incident verification.
In each scenario, the deliverable is a structured report. It contains scope and targets, methodology, test environment description, findings with severity grades and reproduction steps, standards mapping, and remediation recommendations ranked by priority. Evidence appendices carry the raw artefacts.
For manufacturers of connected consumer goods, the cybersecurity report increasingly sits alongside physical safety documentation. Both are commonly managed within one Consumer Products Testing Safety and Compliance programme — the same product, two complementary risk domains.
This concludes Part 1. Subsequent instalments examine specific device categories and deeper technical techniques.
Frequently Asked Questions
What
samples are required for Cybersecurity for Connected Products: Part 1 testing?
Submit representative production units with all firmware pre-installed, plus documentation such as architecture descriptions, credentials, and interface details. Samples must reflect the final hardware and software configuration, as defined under the test items and sample preparation scope.
How do I choose the right test methods in Cybersecurity for Connected Products: Part 1?
Method selection depends on the product type, connectivity features, and applicable frameworks. The execution procedure covers the defined test scope and targets, so confirm which interfaces and functions fall within scope before testing to ensure the chosen methods match your product's characteristics.
What
criteria determine whether a product passes Cybersecurity for Connected Products: Part 1 testing?
Pass or fail is based on the vulnerability assessment metrics and acceptance criteria, referenced against applicable standards and frameworks. Findings are evaluated for severity and exploitability, and the final report states compliance status without fabricating fixed thresholds or limit values.