IoT penetration testing: compare offers, prices and scope
By The PenTest Index · Sources checked October 10, 2026
IoT penetration testing is a hands-on attack on a connected device and the connected systems in scope (hardware, firmware, radios, app and cloud) to show what an attacker could do. Buy the test that names each of those parts in writing. Two firms publish starting prices, $5,200 and $10,800, for different scopes. Most only quote.
Below: which kind of test fits you, eight offers side by side, and a brief you can send so every quote answers the same question.
Which test fits your situation?
Start with one question: do you make the device, or do you just run it? Those are different purchases.
| Your situation | Start here | What could change it |
|---|---|---|
| You make a connected device | A device test that covers hardware, firmware, radios, apps, cloud and updates | An earlier test may already cover some parts. Check its scope and versions first |
| You run other companies' devices on your network (cameras, door readers, sensors) | A network test that checks what a device can reach if it is taken over. See which service type fits | You only need hands-on device work if the device itself is the question. Use a spare unit, never one in service |
| Your product is a medical device | Medical device penetration testing | FDA guidance changes what the report should show |
| It is plant-floor equipment such as PLCs or SCADA | An OT (operational technology) test. Providers sell it separately because of safety rules | A single controller on a test bench can be priced like any other device |
| A customer or market wants a label or a conformity result | A lab assessment against that scheme's standard. That is a different job from a penetration test | Ask the person who wants it which one they mean. More below |
| Only the app or cloud changed | An app or API test | Don't pay for hardware work again if the device and firmware are the same |
| You already have a pentest firm | Run them through the report check | Buy only what's missing |
Here to learn how IoT testing is done? The free OWASP IoT Security Testing Guide is the place to start. This page is for buyers.
Already know your scope? Compare the offers.
Which offers deserve a closer look?
Shortlist by what each offer says it covers, then get your real scope in writing. Of the eight offers we read, two publish a starting price and six quote on request.
We read each provider's own pages on October 10, 2026. Everything below is what the provider publishes. We did not buy these services or read a delivered report. Companies are A to Z within each group. This is not a ranking, and no provider paid to be listed.
Offers with a published starting price
| Offer | What the provider says it covers | Published price (US dollars) and conditions | Retest as published | Still open |
|---|---|---|---|---|
| Invadel, hardware and IoT penetration testing | Small tier: "a single device with a few interfaces: firmware, one or two debug ports, and a wireless radio, plus the companion app where one exists." App and back-end APIs "where they are in scope" | $5,200 for the Small tier, "fixed in writing before work begins." Medium and Large are "on request" | "A free retest of remediated findings," with the report updated. No deadline or number of rounds stated | Whether a second radio and your cloud API fit the Small tier. The retest deadline |
| Software Secured, IoT Pentesting | "Scoping: device, firmware, mobile app, cloud." Debug ports, firmware, iOS and Android apps, device-to-cloud traffic, APIs and wireless | Starts at $10,800 USD. Hardware Pentesting is a separate line that starts at $12,400 USD | Four statements with unresolved applicability. See the note below | Which retest terms apply. Whether your device is one purchase or two |
Sources: Invadel pricing, Software Secured pricing, Software Secured IoT service.
These two prices are floors for different scopes. Invadel's is for one small device. Software Secured's is a starting point for a custom scope. Don't average them, and don't treat either as the going rate.
Software Secured's retest terms need one answer in writing. Its IoT service page says "Request retesting within 6 months of report delivery." Its pricing page says "Retesting: 3 rounds over 12 months" on the IoT card. The package table on that same pricing page lists 1, 3 or unlimited rounds depending on the package. And its own article on IoT testing firms says "Retesting is included for critical and high findings." The round counts and severity statement describe different conditions from the deadlines. Ask which.
Offers that quote on request
| Offer | What the provider says it covers | Retest as published | Stated timing | Still open |
|---|---|---|---|---|
| Bishop Fox, hardware penetration testing | "From the circuit level to the cloud." Circuit boards, chips, debug interfaces, firmware, radio, and whether the product "interacts with an application, network, cloud or all three" | Not stated on the page | Not stated | Price, retest, dates |
| NCC Group, hardware and embedded systems security | "Device hacking & penetration testing," firmware code review, circuit and component-level review, design review. Says it is an "Authorized Lab" and can help devices meet several guidelines and specs | Not stated | Not stated | Apps and cloud are not named on this page. Price, retest, dates |
| NetSPI, IoT penetration testing | Firmware analysis, reverse engineering, chip removal, fault injection, side-channel analysis, radio capture, protocol analysis, code review, mobile and thick-client apps | Not stated on this page | Not stated | Cloud and API are not named on this page. Price, retest |
| Praetorian, IoT penetration testing | Hardware, firmware, wireless and network traffic. Its datasheet lists "Optional Backend Attacks" and "Optional Destructive Testing" | Not stated | Not stated | Backend work is optional, so it must be written into your scope. Price, retest |
| Raxis, IoT penetration testing | Hardware, firmware, wireless, cloud and APIs, companion app, network segmentation | "Included retest ... at no extra cost." No deadline stated | One consumer device: "one to two weeks." Several devices: "three to four weeks" | Price. Retest deadline |
| SecureLayer7, IoT penetration testing | Six surfaces: hardware, firmware, radio, mobile app, cloud and update channel, device admin screens | "Re-test included ... at no extra cost." No deadline stated | Not readable on the page we saw | Price. Timing. Retest deadline |
Sources: Bishop Fox, NCC Group, NetSPI, Praetorian and its datasheet, Raxis, SecureLayer7.
"Not stated" means we did not find it on the pages we read. It does not mean the provider won't do it.
Our read, using one example device
Say you make a smart lock. It has one circuit board, Bluetooth and Wi-Fi, an iPhone and an Android app, a cloud API, and over-the-air updates. A retailer wants a test report before it will list the product. Some fixes will need a hardware change, so you expect to ask for the last retest about nine months after the report. This product is made up.
For that buyer, we would ask four firms for written quotes first. Ask Invadel and Software Secured because they publish a number you can plan around. Ask Raxis and SecureLayer7 because both publish coverage of every part of this product and say a retest is included. Then let one answer decide: the retest deadline.
Ask Bishop Fox, NCC Group, NetSPI or Praetorian instead when the worry is a skilled attacker with the device open on a bench. NetSPI names chip removal and fault injection. Bishop Fox and NCC Group describe work down to the circuit and component level. NCC Group also lists design review, which helps if the product isn't finished.
That is a reason to ask for quotes. It is not approval of any firm. Here is how the offers do against this buyer's three must-haves:
| Must-have and offer | Finding | Send this question |
|---|---|---|
| Every part tested: Invadel Small | Unresolved. The tier names "a wireless radio." This lock has two, plus a cloud API | "Does the $5,200 Small tier cover Bluetooth and Wi-Fi, both apps and our cloud API? If not, what is the fixed price?" |
| Every part tested: Software Secured | Unresolved. Its scope line names device, firmware, app and cloud. $10,800 is a floor | "Is our lock one IoT purchase, or IoT plus Hardware?" |
| Every part tested: Raxis and SecureLayer7 | Supported, for shortlisting. Each part is named on the page. Price is unknown | "Please quote this parts list by part and version." |
| Every part tested: Praetorian | Unresolved. Backend attacks are listed as optional | "Please add our cloud API and backend to the statement of work and price it." |
| Every part tested: NCC Group and NetSPI | Unresolved. Cloud and API are not named on the pages we read | "Is our cloud API in this scope, or a separate application test?" |
| Retest at nine months: Software Secured | Unresolved. Nine months after the report is outside "within 6 months of report delivery"; the applicability and start of "3 rounds over 12 months" are not stated | "Which retest deadline and round count apply to our IoT quote? Will a request at nine months be included?" |
| Retest at nine months: Invadel, Raxis, SecureLayer7 | Unresolved. A retest is included. No deadline is given | "Until what date can we request the included retest, and does it cover every fixed finding?" |
| Nothing destructive without sign-off: Praetorian | Unresolved. Destructive testing is listed as optional, but a written-approval condition is not stated | "Please confirm no unit is destroyed without our written approval." |
"Supported" means that one condition is backed by what the provider published. It says nothing about test quality, and a written quote can change any finding.
How the retest answer changes the choice. If a firm confirms a retest at nine months in writing, it stays on the list. If its deadline is six months and it won't extend, it is out for this buyer, however good the price. A buyer whose fixes are all firmware and ready in eight weeks would not care about this at all.
View Invadel's hardware and IoT pricing
View Software Secured's IoT testing
View SecureLayer7's IoT testing
For deeper hardware work:
View Bishop Fox's hardware testing
View NCC Group's hardware and embedded services
Before you contact anyone, spend ten minutes on the next section. It is what makes their answers comparable.
What should IoT penetration testing include?
It should include every way data gets into or out of your product, with each one named in the quote. "One device" on a price sheet does not tell you whether the app or the cloud is covered.
Fill this in first. It turns your product into a list a provider can price.
| Part | What to write down | Question that makes quotes comparable |
|---|---|---|
| Device and debug ports | Model, hardware revision, any service or debug ports you know about | "Which revisions and ports are tested? Does the quote include opening the case?" |
| Firmware (the software that runs on the device) | Build number. Whether you will hand over the file or the testers must pull it off the device | "If you can't extract the firmware, what work still happens and does the price change?" |
| Updates | How updates reach the device and what happens if one fails | "Will you test what the device accepts, or only review an update file?" |
| Radios | Only the ones you use: Bluetooth, Wi-Fi, Zigbee, Z-Wave, LoRa, cellular | "Which radios will you test, and with what limits?" |
| Apps | Each phone or web app, with versions | "Is each app included or priced separately?" |
| Cloud and APIs | Environment, user roles, customer accounts | "Do you test whether one customer or role can reach another's device or data?" |
| Other systems it connects to | Hubs, gateways, partner services | "Which are covered, and who can approve testing them?" |
| Test units | How many, how they differ from what ships, whether one may be destroyed | "Will the report state limits caused by the units we supplied?" |
If you don't know an answer, write "unknown" and ask your firmware lead for the port and radio list. Unknown is a useful answer. A blank is not.
Two rows trip buyers up. Reading a firmware file and testing the update process are different jobs. The first looks for secrets and weak code in the file. The second checks whether the device will accept an update it shouldn't. Ask for the one you need, or both.
And a vulnerability scan is not this purchase. A scan is a tool checking for known flaws over the network or locally. As Raxis puts it, "A scanner cannot open a case." More in penetration testing vs vulnerability scanning.
How close does the attacker get?
Decide this before you ask for prices, because it sets how much bench work you pay for. The OWASP IoT Security Testing Guide describes four levels of physical access. In plain words:
| Level in the OWASP guide | The attacker is | Example for a smart lock |
|---|---|---|
| Remote | Anywhere in the world | Attacking the cloud API from another country |
| Local | Nearby, but can't touch the device | In the hallway, within Bluetooth range |
| Non-invasive | Holding the device, case closed | Using the buttons and any outside port |
| Invasive | Inside the case | Probing the board and reading the memory chip |
Source: OWASP ISTG attacker model, read October 10, 2026. The examples are ours.
A remote-only test tells you nothing about what happens when someone opens the case. If your product sits where strangers can reach it, say so in the brief.
The deepest work costs the most. Chip removal, fault injection (upsetting the chip's power or timing to skip a security check) and side-channel analysis (learning secrets from power use or timing) are specialist add-ons. Invadel's advice is to add them "only where the threat model justifies it." A threat model is a structured assessment of the system and how it might be attacked.
Copy a brief that asks every provider the same question
Send one brief to each firm and their answers line up. Send four different emails and you get four quotes for four different jobs.
Copy this into your own document and fill in the brackets.
IoT penetration testing brief
Why and for whom: We need testing for [launch / customer request / market entry / internal]. The report will go to [name the customer, lab or team]. They have asked for [what they asked for, or unknown].
Product: [Name], hardware revision [ ], firmware build [ ]. Our test units differ from the shipping version in these ways: [ ].
Parts in scope: [device and debug ports], [firmware], [update process], [radios: list them], [apps and versions], [cloud and APIs, with roles], [other connected systems]. Mark each one in, out with a reason, or unknown.
Attacker access: [remote / nearby / holding the device / inside the case]. Signed-in access to test: [none / normal user / admin].
What we can give you: [number of test units], [firmware file or source code], [board diagrams], [test accounts], [test environment]. Tell us what is missing and how it limits the test.
Limits: Units that may be destroyed: [number or none]. Anything destructive needs our written approval first. Systems you must not touch: [ ]. Who can stop the test: [name and contact].
Shipping: Where units go, who pays, and whether they come back or are destroyed.
Report: Tested versions, scope and exclusions, attacker access assumed, methods, findings with evidence and steps to reproduce, and limits. Say whether a letter of attestation is included.
Dates: Earliest start, days of testing, report date, and updated report date after retest.
Retest: Which fixes qualify, how many rounds, the deadline and what starts the clock, whether a new firmware build or hardware revision is covered, and any fee.
Full cost: Itemize the test, shipping or lab fees, any platform fee, the retest and extra reporting. State currency and payment terms.
What we already have: [earlier reports, current vendor, internal testing]. Tell us what can be reused.
Please answer every line with one of: included / excluded / optional with fee / unresolved.
This brief is for buying. It is not permission to test. Testing needs a separate signed agreement covering the exact targets and activities.
Still working out the general questions, like who needs the report and by when? Find My PenTest Match is our free scope checklist. It asks for no email and sends nothing to providers. It compares web app and API offers, so it does not list device testing firms. Use it for the general questions and the brief above for the device details.
How much does an IoT pentest cost?
Two of the eight firms publish a starting price. Invadel lists $5,200 for a small single device, fixed in writing. Software Secured lists IoT testing from $10,800 USD for a custom scope. The other six quote on request. All checked October 10, 2026.
Neither number is a quote for your product. You will meet four kinds of price, so keep them apart:
- A starting price: the least you could pay, with conditions. Invadel's $5,200 assumes one device with a few interfaces and one radio.
- A range: one firm's guide for a type of job. Many vendor blogs publish "typical" IoT ranges. Those are the vendor's own estimates, so we don't repeat them here.
- A quote: a price for your scope. This is the only one you can sign.
- A subscription: a recurring fee for ongoing testing. Ask what the device work inside it costs.
Invadel says five things move its price: the number of interfaces, how deep the physical testing goes, whether the app and cloud are included, the device class and the standard its report has to satisfy, and whether you test one unit or a product line. It also gives one tip worth using with any firm: if several products share firmware and a platform, test one representative unit first.
Before you compare totals, make sure each quote settles the same six lines:
| Line | What must be in writing |
|---|---|
| The test itself | Parts, versions, attacker access, days of work |
| Access and logistics | Test units, firmware or source, shipping, lab or travel fees |
| Extra systems | Any added app, API, radio or connected system |
| Reporting | Full report, walkthrough call, letter of attestation, updated report |
| After the report | Retest terms |
| Commitment | Currency, payment dates, any platform fee or minimum term |
A missing line is not a zero. It is an unknown, and the total isn't finished until it's filled in.
For how pentest pricing works in general, see penetration testing cost. Already holding quotes? Compare them line by line.
Which retest terms need to be in writing?
Five things: which fixes qualify, how many rounds, the deadline, what starts the clock, and whether a new build is covered. "Retest included" on its own tells you none of them.
A retest means the testers check that your fixes worked. Devices add a twist that web apps don't have. A fix may ship as new firmware, or as a changed circuit board months later. Ask whether the retest covers a new build, and whether you have to ship units again.
The Software Secured example above shows why this matters. One page says six months and another says twelve. If your hardware fix lands in month nine, the applicable deadline and what starts its clock decide whether the retest is included.
Send this to every firm:
"Is a retest of every fixed finding, at every severity, included in the fee? How many rounds? Until what date, counted from what event? Is that the date to request it or to finish it? Does it cover a new firmware build or hardware revision?"How long does an IoT penetration test take, and do you ship the device?
Providers state one to four weeks of testing for a consumer device, and for hardware work you usually ship units to their lab.
What four firms publish, checked October 10, 2026:
| Provider | What it states |
|---|---|
| Raxis | "A single consumer device typically takes one to two weeks." A multi-device setup "can run three to four weeks" |
| Invadel | A small device "runs about a week or more," then reporting. Testing "usually starts within a week of scoping, once the device reaches our bench" |
| Software Secured | "Scheduling within 3-6 weeks." "Report within 48-72 hours of pentest completion" |
| Blaze Information Security (a testing firm's guide) | 2 to 10 weeks overall. About 3 to 4 weeks for simple consumer devices |
A stated testing time is not a booked start date. Ask each firm for its earliest confirmed start and its report date, in writing.
Now count back from the day you need the finished report. Here is a made-up plan for the smart lock, with firmware fixes only: 1 week to ship units, 2 weeks of testing, 1 week for the report, 6 weeks for your engineers to fix things, 1 week for the retest and 2 weeks of slack. That is 1 + 2 + 1 + 6 + 1 + 2 = 13 weeks. Add the firm's booking lead time on top. The 2 weeks of testing is Raxis' upper figure for one consumer device. The other numbers are ours, for illustration.
On shipping, Raxis says hardware-level testing "usually needs the physical device on a bench, shipped to our lab or worked on site," while cloud, API and network work "can often be done remotely." Software Secured says it prefers "at least one production-like device." Settle four things before you ship: how many units, whether any may be destroyed, who pays for shipping, and whether units come back. If the product isn't public yet, get a confidentiality agreement signed first.
Is IoT penetration testing required?
For most device makers, the test is asked for by a customer or chosen as proof. In the rule texts we read, we found security outcomes you must meet, not an instruction to buy a penetration test. Who decides what counts as proof is the customer, lab or regulator asking.
Here is what we read on October 10, 2026, and what we did not.
| Rule | What the text we read says | What we can't tell you |
|---|---|---|
| UK product security regime (consumer connectable products) | In effect since April 29, 2024. GOV.UK lists three requirements: no universal default or easily guessable passwords, published information on how to report security issues, and published information on minimum security update periods. A statement of compliance must accompany the product | That page does not mention penetration testing. We did not read the regulations themselves |
| EU radio equipment rules (Delegated Regulation (EU) 2022/30) | Subject to Article 2's exemptions, Article 1 applies cybersecurity requirements to "any radio equipment that can communicate itself over the internet," with further rules for certain equipment that handles personal data or money. An amending regulation set the date: "It shall apply from 1 August 2025" | Which standards or assessment route fit your product. That is a question for your compliance lead or a notified body |
| EU Cyber Resilience Act (Regulation (EU) 2024/2847) | Article 71: "This Regulation shall apply from 11 December 2027." Reporting duties in Article 14 apply from September 11, 2026. Annex I says products must "be made available on the market without known exploitable vulnerabilities" | We read Article 71 and the opening of Annex I, not the whole regulation. We make no claim about what testing it expects |
| Medical devices | See medical device penetration testing for what FDA's guidance says |
A label or conformity result is a different purchase from a penetration test. A conformity assessment checks your product against a list of requirements. The GOV.UK page points to one such method, ETSI TS 103 701, which is the test specification for the consumer IoT baseline ETSI EN 303 645. A penetration test tries to break in by whatever route works. Some firms sell both. NCC Group, for example, says it is an "Authorized Lab" and can help devices meet several guidelines and specs. That is NCC Group's statement, and we have not checked all of it with the scheme owners. If a customer asks for "a pentest" and means a certificate, or the other way round, you will buy the wrong thing. Ask them which.
You will also see vendor pages say that regulations "expect" independent testing. Treat that as the vendor's reading unless they point you to the clause. No report guarantees a pass with any customer, lab or regulator.
What should the report show?
It should say exactly what was tested, how, what was found and what was left out, in enough detail that your engineers can repeat each finding. Check a sample report for these seven things before you sign.
| Look for | Why it matters |
|---|---|
| Hardware revision and firmware build tested | A report on build 1.3 says little about build 1.4 |
| A list of what was in and out of scope, part by part | "IoT test" on the cover doesn't prove the cloud was tested |
| The attacker access assumed | Remote-only and inside-the-case are different tests |
| Methods and tools, by part | Shows whether people did the work or a scanner did |
| Evidence and steps to reproduce each finding | Your engineers need this to fix it |
| Impact and a fix for each finding | A severity label alone is not guidance |
| Retest status for each finding | Shows what is closed and what is still open |
This is our checklist, built from what the providers above say they deliver. Praetorian's datasheet lists an executive summary, a technical findings report and a walkthrough, with a "letter of attestation available upon request." Raxis and Invadel also mention an attestation letter. A letter is a short summary. If your customer asked for the report, a letter may not be enough, so ask them before you book.
This check also answers "can our current pentest firm do it?" Ask them for a sample finding from a device job. If it shows board, firmware or radio work with steps to reproduce, they may be able to. If it reads like a web app finding, you have your answer. For general report quality, see how to assess a penetration test report.
Questions buyers still ask
What is the difference between IoT and OT penetration testing?
IoT testing looks at a connected product: its board, firmware, radios, app and cloud. OT testing looks at industrial control systems such as PLCs and SCADA in a working plant. Raxis describes the two as separate services that "often overlap where connected devices meet the plant floor." The buying difference is safety. A device on a bench can be pushed until it fails. A running plant cannot.
Can testing damage our units?
Yes, some of it can. Praetorian's page says optional destructive testing "may result in device malfunction." Chip removal means taking a chip off the board. That is why the brief asks how many units may be destroyed and requires written approval first. If you only have two prototypes, say so up front.
Do we need a new test for every firmware release?
We found no rule in the texts we read that sets a schedule. A practical trigger is change. Test again when you add a radio, change how updates work, change the board, or rework how the device signs in to the cloud. Small fixes can go through the retest you already paid for, if its terms cover a new build.
How we checked
We compare specific offers against stated buying needs and show our sources. For this page we read each provider's public pages, three rule texts and the OWASP guide on October 10, 2026. We did not buy a test, talk to these providers or read a delivered report. The smart lock is made up. We don't perform, authorize or certify testing. Read how we check offers and how we make money.
Sources, all checked October 10, 2026
- Invadel, hardware and IoT penetration testing cost: Small tier price, scope wording, retest, timing, price drivers
- Software Secured pricing: IoT and Hardware starting prices, retest on the service card, package table
- Software Secured, IoT penetration testing: scope, six-month retest request rule, scheduling and report timing
- Software Secured, best IoT and hardware penetration testing companies: its own retest statement
- Bishop Fox, hardware penetration testing: coverage statements
- NCC Group, hardware and embedded systems security: listed services, Authorized Lab statement
- NetSPI, IoT penetration testing: technique list
- Praetorian, IoT penetration testing and datasheet: optional work, deliverables
- Raxis, IoT penetration testing: scope, retest, timing, shipping, IoT and OT
- SecureLayer7, IoT penetration testing: six surfaces, re-test
- Blaze Information Security, IoT penetration testing guide: duration figures
- OWASP IoT Security Testing Guide, version 1.0.1, and its attacker model
- GOV.UK, consumer connectable product security
- Regulation (EU) 2024/2847: Article 71 and Annex I, Part I
- Delegated Regulation (EU) 2022/30, Articles 1 and 3, and Delegated Regulation (EU) 2023/2444