IoT device security testing

Why manufacturers commission IoT device security testing before launch

IoT device security testing is an independent check of a connected product and the ecosystem around it, from its hardware interfaces and radio links to the companion app and cloud API it depends on. For a manufacturer, it gives evidence of which weaknesses exist before customers, a launch date or a regulator finds them. Most commissions start from one of four situations: a product launch, a customer security questionnaire, an insurer or due diligence request, or preparation for obligations under the EU Cyber Resilience Act. The test is planned so that its findings can be read against the same baseline the buyer's customers and assessors will use.

The risks it targets are concrete and recur across product lines. Default credentials shipped with a device or shared across a model range let an attacker take control of many units at once. Weak update integrity, such as firmware accepted without verifying its signature, lets a modified image reach the device. Exposed services left open on the local network or the internet widen the attack surface, and cloud APIs that trust the client without proper authorization can expose data from every account on the platform. Each of these maps to provisions in ETSI EN 303 645 V3.1.3, which is the baseline many buyers ask about. Confirm with your own security team which of these areas your product already documents, because the test scope depends on it.

The CRA timeline shapes when testing is most useful. Under Article 14 of Regulation (EU) 2024/2847, manufacturer reporting obligations apply from 11 September 2026, and the regulation generally applies from 11 December 2027. A product still in development in the coming year therefore needs vulnerability handling and evidence in place before its first reporting duty applies. DeployOpen runs the tests, documents findings and prepares the evidence an assessor would examine. Independent auditors and certification bodies issue assessments and certifications, so the report should be agreed with your compliance lead and your assessor before work starts.

What IoT device security testing covers: hardware, radio, app and cloud

An IoT test rarely stops at the device. The hardware, radio, companion app, backend API and firmware each carry different risks, and each needs its own scope decision before work starts. The OWASP ISTG organizes its test cases by component of the IoT device model, so the scope can be written and agreed per component.

Hardware interfaces

This component covers the physical device: debug ports, storage chips, exposed boards, enclosure access and any service interface left enabled after manufacture. Testers check whether debug access is locked, whether stored credentials or keys can be read from flash or memory, and whether a device can be reset or altered without authorization. Scope the test units explicitly: the client should supply the number of devices, whether they are production or pre-production hardware, and whether destructive inspection is permitted. Confirm in writing who may open the enclosure.

Radio interfaces

Radio testing examines every wireless protocol the device exposes, such as Bluetooth, Wi-Fi, cellular and any proprietary sub-GHz links. Testers look at pairing and bonding logic, how traffic is encrypted and authenticated, whether broadcast data leaks identifiers, and how the device behaves when it receives malformed or replayed frames. Confirm the radio environment in advance: testers need to know whether a lab shielded enclosure, a dedicated test network or an over-the-air test in a permitted area is used, and who approves transmissions.

Companion mobile app

Many devices depend on a phone app for setup, control and account linking. Testing covers how the app stores tokens, how it pairs with the device, whether local network traffic is protected, and how it handles account recovery and permission scope. The app is usually a separate test target with its own methodology, so decide whether it is tested within this engagement or referenced to a mobile assessment. Clarify the client's role: test accounts, test devices, and the app builds to be tested should be provided and documented.

Cloud and backend API

The backend typically handles device registration, telemetry, firmware distribution and user access, and it often controls many devices at once. Testers review authentication between device and cloud, authorization between tenants and users, API object-level access, and how device identifiers are issued. Third-party cloud services usually need written authorization from the provider or a confirmed exemption under their testing rules. Ask the client to list every hosted service in scope and to confirm which hosting accounts the tester may access.

Firmware across all components

Firmware runs on the hardware, sets the radio behavior, stores app-facing credentials and defines how updates are verified, so it cuts across every other component. Testing follows the OWASP FSTM stages, from obtaining firmware through filesystem extraction, emulation and dynamic analysis. Scope should state whether firmware images are provided by the client, whether the update mechanism is tested with signed test builds, and whether emulated testing is acceptable in place of physical device runs.

How an IoT device engagement runs, from scoping to retest

The engagement moves from a written scope to component-level testing, then to severity-rated findings and a retest of fixes, so the client ends with verified results mapped to the provisions it asked us to check. Phase timing is set in the written scope and should be confirmed there before work starts.

Scope the device and its ecosystem
The engagement lead and the client agree which device models, firmware versions, companion app builds and cloud APIs are in scope, and which OWASP ISTG components are tested: hardware interfaces, radio, firmware, network services, companion app, cloud and web APIs, and update mechanisms. The client also states which ETSI EN 303 645 provisions it wants checked, such as default passwords, vulnerability disclosure, update handling and secure communication. The step closes with a written scope listing components, provisions, sample size and exclusions. Ask the provider to confirm phase timing in that document.
Agree rules of engagement and test units
Both parties define how testing is carried out: which physical devices or test units are provided, whether testing happens in a lab or on a staging cloud tenant, what may be altered or destroyed, and how a safety or availability issue is escalated. The client confirms who may approve active testing against live services and who receives urgent findings out of hours. The step closes with signed rules of engagement and a named list of test units with their serial numbers and firmware hashes. Anything not covered here stays out of scope until it is agreed in writing.
Obtain and analyze firmware
Where firmware is in scope, the tester follows the OWASP Firmware Security Testing Methodology stages, starting with information gathering and obtaining images through the vendor update channel or the device itself. The image is then analyzed, its filesystem extracted and reviewed for hardcoded credentials, keys, outdated components and weak update integrity checks. Where it is useful, the firmware is emulated so that services can be tested without placing the device on a production network. The step closes with an inventory of components, identified weaknesses and the set of test cases that will run against the device.
Test each component against the ISTG catalog
Testers work through each component in the agreed scope using the OWASP IoT Security Testing Guide test cases. This covers physical and debug interfaces, radio and wireless protocols, network services, the companion mobile app, cloud and API endpoints, and authentication and session handling. Each test is recorded with its ISTG identifier so that results can be compared across assessments and across product versions. Testers keep active tests within the limits agreed in the rules of engagement and stop any test that shows signs of affecting device availability. The step closes with a test log that shows what was tested, how, and the result for each case.
Map results to the agreed provisions
Each finding and each passed test is linked to the ETSI EN 303 645 provision it bears on, so the client can see coverage against the baseline it selected. Provisions that could not be tested within the scope, or that depend on processes outside the device, such as vulnerability handling or support periods, are recorded as not assessed with the reason. This mapping is a technical check against the provisions and is not a conformity or certification statement. The step closes with a provision-by-provision table that the client can share with its own assessor.
Report findings with severity ratings
The tester writes a report that describes each finding, the affected component and firmware version, the evidence captured, the likely impact, and a remediation direction the engineering team can act on. Each finding carries a severity rating, and the report explains the rating method the provider used so the client can challenge or adjust it. Findings that touch safety, availability or regulated data are flagged for immediate notice rather than held for the final document. The step closes with a delivered report, a debrief with the engineering and product teams, and an agreed list of findings to retest.
Retest fixed findings and close out
After the vendor or client ships fixes, the tester verifies each remediated finding against the same firmware or app build that the fix targets, and confirms that the change does not introduce a regression in the tested components. Findings that are accepted as risk stay open with a documented owner and rationale. The retest result is recorded in an updated report or addendum that states which findings are closed, which remain open and which firmware version was tested. The step closes with a final report version that the client can file as evidence for its own compliance or customer reviews.

Which weaknesses IoT device testing looks for and why they matter

IoT device testing follows the baseline provisions of ETSI EN 303 645, which describe the weaknesses that most often put consumer devices and their ecosystems at risk. Each category below names what the check examines on the device, the app and the cloud, and why a gap there becomes a business problem.

Universal and default passwords

Many connected devices ship with credentials shared across a product line, printed on labels or hard-coded in firmware. Testing checks whether each unit has a unique credential at first use, whether the companion app forces a change, and whether default accounts can be disabled. A shared credential turns one compromised unit into a fleet-wide exposure, which is why this provision is the first in the baseline.

Vulnerability reporting and handling gaps

A device maker needs a published route for security researchers to report flaws and a process to act on those reports. Testing reviews whether a disclosure contact exists, whether it is reachable, and whether the vendor has a defined way to triage, fix and communicate. Without that process, a flaw found by a researcher can stay open for months, and the manufacturer has no evidence it responded in good faith.

Software update integrity and currency

Devices need updates that are delivered securely, verified before installation and actually installed over the product's life. Testing examines how update packages are signed and checked, whether rollback to older vulnerable versions is blocked, and whether the update mechanism works without the user's manual steps. A weak update path is one of the most durable exposures on a deployed device, because every unpatched unit stays exposed for years.

Insecure storage of security parameters

Keys, certificates, tokens and passwords held on the device or in the companion app must be protected at rest. Testing reviews where these values are stored, whether they are encrypted or held in hardware-backed storage, and whether firmware images or app packages expose them in readable form. Extracted secrets can unlock every device sharing the same key, so the business risk scales with the size of the installed base.

Weak or missing secure communication

Data moving between the device, the app and the cloud should be encrypted, authenticated and checked for integrity. Testing confirms that transport uses current protocols and validates server certificates, that the device does not fall back to unencrypted channels, and that local radio links apply the same protections. Weak transport lets an attacker on the same network read or alter commands and telemetry, which can affect safety in connected physical systems.

Exposed attack surfaces and debug interfaces

Every open network service, unused port, enabled debug header or remotely reachable administrative page widens what an attacker can reach. Testing inventories the services each interface exposes, checks whether debug and maintenance functions are disabled in production builds, and confirms that unneeded features are removed from the image. Reducing this surface is usually the fastest way to lower risk, and it is cheap to verify against the device's own configuration.

What drives IoT device security testing cost and duration

This table compares the scope drivers that change the effort of an IoT device security test, why each one moves the work, and what to request in a quote. Read it against your own product line: the more variants, firmware builds, radio interfaces and cloud endpoints in scope, the more the written scope will need to spell out. DeployOpen does not publish a price list, and a quote follows from the written scope.

Driver	Why it changes effort	What to ask for in a quote
Device variants and hardware revisions	Each board, SoC or enclosure revision can expose different debug headers, flash layouts and components, so each one may need its own hardware review.	Named list of variants and revisions in scope, and which are representative samples versus all units
Firmware versions to analyze	Every image needs extraction, filesystem analysis and comparison, and older versions often carry components that newer builds have removed.	Number of firmware images in scope, whether prior versions are included, and how update packages are obtained
Radio interfaces in scope	Bluetooth, BLE, Wi-Fi, Zigbee, Thread, LoRaWAN, cellular and NFC each have their own pairing, encryption and session behavior to review.	Explicit list of radios tested, with a note on any that are excluded and why
Companion app platforms	iOS, Android and any desktop or web companion each add a client to review, along with local storage and how the app handles device credentials.	Platforms, app versions and whether app source or test builds are provided
Cloud API endpoints and user roles	Endpoint count, authentication flows and role boundaries (owner, guest, installer, support) multiply the authorization checks needed.	Endpoint inventory or API specification, number of roles, and whether tenant isolation is in scope
Test units and emulation	Working units allow hardware and runtime testing, while emulated firmware suits static and some dynamic work but can miss hardware-dependent behavior.	Whether the client supplies units, how many, and whether emulation is planned for each firmware image
Depth of testing per component	A baseline review against ETSI EN 303 645 provisions differs from a full penetration test using the OWASP ISTG test cases for each component.	Test cases per component, the testing standard used, and what evidence each finding needs
Retest scope	A retest after remediation covers only the reopened findings, while a retest after a new firmware release may repeat significant parts of the analysis.	Whether one retest round is included, how regression is defined, and the cost of later retests
One-time versus recurring work	The initial assessment and report are one-time. Retests and re-testing after firmware releases recur, and the Cyber Resilience Act timeline may add more.	Separate line items for the initial assessment, report, each retest round and each recurring firmware cycle

How IoT device testing changes for consumer, industrial and bench-only devices

Consumer connected devices, such as cameras, thermostats, wearables and smart home hubs, are the main case for ETSI EN 303 645. That standard was written for consumer Internet of Things, so its provisions form the primary baseline for the test plan. Testing typically covers the device, its companion app and the cloud services it depends on, and it checks each provision against observed behavior rather than against the vendor's own claims.

Baseline mapping: The test plan maps each relevant provision, such as the absence of universal default passwords, vulnerability disclosure handling, software updates and secure communication, to specific test cases.
Ecosystem scope: The app, account registration, pairing flow and cloud API are usually in scope alongside the hardware, so the client should name every backend the device relies on.
Update path: Testers verify how firmware is delivered, whether updates are authenticated, and whether the device keeps running securely after an update.
Access the client provides: Several production-equivalent units, firmware images for each release, test accounts, app builds and a written list of third-party services.
Report content: Findings are tied to individual provisions and to the OWASP ISTG test categories, so the report can be used as evidence in a conformity discussion without implying a certification.

Before commissioning, confirm with the client's compliance lead which provisions the product must satisfy and which ones the vendor will address through documentation.

Which frameworks and regulations expect IoT device testing

This table compares the main frameworks and regulations that shape IoT device testing, what each expects regarding testing, and what to confirm with your assessor or customer. Use it to decide which tests and evidence to scope first, then check each row against your own product line and market.

Framework or regulation	What it expects regarding testing	What to confirm with the assessor or customer
EU Cyber Resilience Act (Regulation (EU) 2024/2847)	Manufacturers of products with digital elements must meet essential cybersecurity requirements. Manufacturer reporting obligations under Article 14 apply from 11 September 2026, and the regulation applies from 11 December 2027. The Commission's FAQ lists fuzz testing, penetration testing, firmware analysis, side-channel analysis, red-team exercises and network traffic analysis as possible additional tests when integrating components.	Which product categories and components are in scope, which additional tests the manufacturer's risk assessment justifies, and how vulnerability reporting will be evidenced from the 2026 date.
ETSI EN 303 645 V3.1.3 (2024-09), baseline requirements	Provides a baseline of 13 provision groups for consumer IoT, including no universal default passwords (5.1), minimizing exposed attack surfaces (5.6), ensuring software integrity (5.7) and validating input data (5.13). Testing maps evidence to each provision.	Which provisions the customer or buyer requires, whether a provision-by-provision test report or a third-party assessment is expected, and whether the target market uses this baseline or a different one.
ISA/IEC 62443 (component requirements, ISA-62443-4-2)	ANSI/ISA-62443-4-2 defines technical security requirements for industrial automation and control system components. Testing checks the device against the component requirements that apply to its role, with system-level requirements in ISA-62443-3-3 covered separately.	Which component type and target security level apply, whether the device will be tested as a stand-alone component or within a system, and whether the buyer requires a certified assessment.
Customer security questionnaires	Buyers in banking, healthcare and public sector often ask for evidence of device hardening, default credential removal, update mechanisms, secure communications and vulnerability handling. Answers should be backed by test results, not statements alone.	Which questions must be answered with test evidence, whether a recent test report or a summary is acceptable, and how long the evidence must remain valid after a firmware change.
Independent assessment and certification schemes	An independent auditor or certification body issues any assessment result or certificate. Testing supplies the technical evidence those bodies review, and the scope of the test should match the scheme's target of evaluation.	Which body will assess the device, which version of the firmware and hardware is covered, and whether the assessor accepts test evidence produced by an outside tester.

Turning ETSI EN 303 645 provisions into an IoT test plan

ETSI EN 303 645 V3.1.3 is organized into 13 provision groups, running from 5.1 No universal default passwords to 5.13 Validate input data, and each group becomes a row in the test plan rather than a single pass or fail question. The practical step is to map every provision to one of three kinds of evidence: a test result from the device, its firmware or its companion app and cloud API; a configuration record showing how the product ships and how it is set up; or a vendor document describing the manufacturer's own process. Provision 5.6 Minimize exposed attack surfaces maps mainly to port scans of the device, a review of open services and debug interfaces, and a check that unused radio or hardware interfaces are disabled. Provision 5.7 Ensure software integrity maps to firmware image signing, the verification the device performs before installing an update, and a tampering test on an update package. Provisions such as 5.2 Implement a means to manage reports of vulnerabilities and 5.3 Keep software updated are different in kind, because they describe how the manufacturer operates, so a tester can only check artifacts such as a published disclosure policy, a support period statement and a release history.

Some provisions therefore need documentary evidence from the manufacturer's processes, and a test alone will not close them. Before testing starts, confirm with your assessor which provisions they expect to see backed by vendor records, such as secure development practice, component end-of-support handling and how security parameters are managed in production. Ask the device vendor, or the team that builds the product, to supply those records in advance, because a tester cannot generate them. Also agree which provisions are out of the tester's reach, such as those depending on cloud operations or manufacturing controls, and record them as open items with an owner. Keep a single matrix that lists each provision, the test or record that supports it, the version of the firmware and app tested, and the date of the evidence. An assessor reviewing the matrix can then trace a claim back to its source without relying on a summary.

Scope the matrix before the device is in the lab. Decide which product variants, firmware versions and companion app releases are covered, because a provision that passes on one build may fail on another. For provisions that involve data handling, such as secure storage of sensitive security parameters and secure communication, the cloud API and the app are part of the evidence, so the scope must name those components explicitly. Where the assessor expects a provision to be covered by a test that the vendor has not yet run, plan the test as a deliverable with a named owner. Record the outcome of each row as met, not met, or evidence outstanding, and treat "evidence outstanding" as a risk to plan for rather than a pass. Use the ETSI standard directly as the reference for provision wording, and keep your own notes separate from the text of the standard.

What the client receives and whether it satisfies an auditor or customer

An IoT test produces several outputs, and each one serves a different reader: engineering, management, an assessor, or a customer running a security review. The cards below describe what each output contains and what it cannot establish on its own, so you can confirm the package matches the evidence your auditor or customer will ask for.

Written report with executive summary

The report opens with an executive summary for management and a technical section for each component tested: hardware interfaces, radio, firmware, companion app, and cloud API. Each finding records the affected component, the reproduction conditions at a defensive level, and the recommended fix. Ask for the component breakdown to match the device model you agreed in scope. This report does not replace a certification, an audit report or a conformity assessment. The assessor decides whether it is sufficient.

Severity ratings and their basis

Each finding carries a severity rating, and the report should state the method used to assign it, along with the assumptions about attacker access such as physical access to the device or network adjacency. Ask whether ratings follow a published scheme and whether the tester explains any adjustments. A rating reflects the tester's judgment on this device in this scope, so an assessor may weigh it differently. Severity alone does not show whether a provision is met.

Provision-by-provision mapping

A mapping table links each finding and each passed test to the provisions of ETSI EN 303 645 V3.1.3 and to the matching OWASP ISTG test case identifiers. Provisions with no finding and no test coverage should be listed as not assessed, so gaps stay visible. This mapping helps an assessor trace evidence to requirements, but it is a working document prepared by the tester, not a statement of conformity. Confirm that the agreed scope names every provision group being tested.

Retest results for fixed findings

After the vendor ships fixes, a retest confirms whether each finding is closed, partly closed or still open, and records the firmware or app version that was tested. Ask for the retest to be written as a separate addendum that references the original finding IDs, so the history stays intact. A retest confirms specific fixes only. It does not show that new defects are absent, and it does not replace a fresh assessment after a major firmware change.

Evidence package for the CRA technical file

The evidence package collects test scope, tool and firmware version records, dated logs of test activity, screenshots, and the mapping above, arranged so the manufacturer can place it in its technical documentation. The Commission's CRA FAQ lists penetration testing, firmware analysis, fuzz testing and other tests as possible additional tests when integrating components, which is why the package should state which of those were run. Reporting obligations under Article 14 apply from 11 September 2026. The manufacturer owns the technical file, and the notified body or market surveillance authority decides what it needs.

Scope and limitations statement

Every report should open with a statement of what was in scope, what was excluded, which firmware and app versions were tested, and which test environment was used. Ask for explicit notes on any tests limited for device safety, such as those that could disrupt a connected medical or industrial function. This statement tells a customer or assessor what the result covers, and what it does not. Without it, a clean report can be read as broader assurance than it is.

How long, how much and what IoT device testing needs from the client

How much does IoT device security testing cost?

DeployOpen does not publish a price list. A quote follows from the written scope, and the main cost drivers are the number of distinct device models and firmware versions, the hardware interfaces in play, whether radio testing is included, the number of companion app platforms, the size and complexity of the cloud API, and how many test units are supplied. Ask the provider to break the quote into planning, device and firmware work, app and cloud testing, reporting and any retest. Most engagements are fixed-scope, so the scope document should list exactly what is covered and what is excluded before work starts. Separate one-time costs (the initial test and report) from recurring costs (retainers for continuous testing or retesting after updates), so you can budget for both.

How long does an IoT device security test take?

No standard duration applies, because the time depends on the written scope. The main factors are the number of device components to assess (hardware interfaces, radio, firmware, companion app and cloud API), the number of models and firmware builds, how quickly test units, images and accounts are provided, and whether the test includes emulated firmware analysis or only the live device. Ask the provider for a schedule that shows planning, testing, reporting and a review meeting as separate milestones, and confirm how delays caused by missing inputs will be handled. Build in time for the client to review findings and for a retest, since remediation by the manufacturer often sets the pace of the second round.

What must the client provide for an IoT device penetration test?

The client typically supplies the inputs that make the test representative and authorized. These usually include:

Test units in the production configuration, with spares if destructive testing is possible
Firmware images for each version in scope, plus the update packages and signing details that the assessor needs to review
Companion app builds for each platform, and access to test accounts with the roles that real users hold
Cloud and backend access under agreed rules, such as test tenants, a named contact and an approved source range
Written authorization covering third-party services, such as a cloud provider or a hosted vendor platform, because the client may not be able to approve testing of systems it does not own

Confirm each item in the scope document. Missing inputs are one of the most common reasons a test slips.

Can our internal team run an IoT device security test?

An internal team can run useful assessments, but a formal test usually needs skills across hardware interfaces, radio protocols, firmware extraction and analysis, mobile and web application testing, and cloud API testing. The team also needs the time to document results in a way that a third party can reproduce. Where a compliance framework, customer or insurer expects independence, an external assessor is often required, so check the requirement before deciding. A common split is an internal team that handles asset inventory, update processes and vulnerability intake, with an external assessor that tests the device and its ecosystem. Ask the provider to explain how its staff are separated from the team that designed the product.

How is retesting priced and scheduled after IoT findings are fixed?

Retesting is normally scoped separately from the initial test, because it covers only the findings that were fixed, the affected components and any regression risk from the change. Its cost depends on how many findings are being verified, whether the fix changes firmware, the app or the cloud API, and whether new firmware images must be analyzed again. Ask the provider whether retesting is included in the original quote, how long after the report it must be requested, and what the output looks like, such as a status table per finding. For devices that receive ongoing updates, a retainer for periodic or continuous testing can be more practical than one-off rounds. Confirm the retesting terms in the written scope.

Will an IoT penetration test report satisfy the CRA or a customer review?

It depends on the assessor and on the specific requirement. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, sets obligations that manufacturers must meet, and the Commission's CRA FAQ lists penetration testing, firmware analysis and related tests as possible additional security tests when integrating components. A penetration test report is evidence that a test was performed, but it does not by itself constitute a conformity assessment or a certification. Independent auditors and certification bodies issue those outcomes. Ask your compliance lead which evidence the requirement expects, and ask the provider to map findings to the relevant ETSI EN 303 645 provisions so the report can be used in a customer security questionnaire.

What should we ask when choosing an IoT security testing provider?

Ask about methodology first. A credible provider will explain how it applies the OWASP IoT Security Testing Guide and the OWASP Firmware Security Testing Methodology, which stages it covers, and how it checks results against ETSI EN 303 645 where that is relevant. Request a sample report, redacted if necessary, and check that it shows reproducible steps, severity reasoning, affected components and remediation advice. Ask who will perform the work, what hands-on experience they have with hardware, radio and firmware testing, and how the team handles safety-sensitive devices. Finally, ask how scope is written, what is excluded, how data and test units are handled, and how retesting works. DeployOpen can describe these points in a written proposal, and quotes follow from that scope.

How DeployOpen scopes, tests, reports and retests IoT devices

DeployOpen approaches IoT device security testing as a fixed-scope engagement agreed in writing before work starts. The test covers the device, its companion app and cloud API, and the handover is built so your team and your assessors can follow the findings and verify fixes.

How we scope

Agree in writing which devices, firmware versions, interfaces and cloud endpoints are in scope before any testing begins.
Confirm whether testing uses lab units, emulated firmware or production hardware, and record the safety limits that apply.
Map the scope to the OWASP IoT Security Testing Guide components and to the ETSI EN 303 645 provisions your product must meet.

How we build

Work through hardware interfaces, radio, firmware, companion app and cloud API using the OWASP ISTG test case catalog for each component.
Extract and analyze firmware following the OWASP Firmware Security Testing Methodology, checking for hardcoded credentials, keys and outdated components.
Record each test against its scope item so results from different components remain comparable across the engagement.

How we hand over

Deliver findings with reproduction context, affected components, severity reasoning and recommended fixes that your engineers can act on.
Provide a mapping of results to ETSI EN 303 645 provisions so your team can see which baseline requirements are met, partly met or open.
Document limits of the test, including what was not covered, so your auditor or customer reads the report with accurate expectations.

How we support

Retest agreed findings after fixes are applied and issue an updated record showing which items are closed and which remain open.
Offer ongoing support and continuous testing as a retainer when firmware releases or cloud changes need regular review.
Confirm with your team which evidence your Cyber Resilience Act and customer assessments will need before the engagement closes.