Hardware penetration testing: published prices and scope compared

By The PenTest Index · Offers checked October 10, 2026

Hardware penetration testing is a hands-on attack on a physical device — its ports, chips, firmware and radios — to show what someone holding it could break. Three providers we checked publish starting prices: Invadel from $5,200 for a small device, Software Secured from $12,400 and Schellman no less than $25,000. Those figures buy different scopes, so compare what each includes below.

Which route fits you:

• You make the device, and a customer, investor or regulator wants it tested. This is your page. Start with the comparison.
• You only want the devices on your own network checked (cameras, badge readers, kiosks). That is a network test, not this one. See which type of penetration testing service fits.
• You need a certification mark or label. That follows the scheme's assessment route, which may require an accredited lab evaluation. Jump to what the rules say.

Hardware penetration testing prices and terms, compared

Of seven providers we checked on October 10, 2026, three publish a starting price for hardware testing. The highest floor is nearly five times the lowest start ($25,000 ÷ $5,200 = 4.8, taking each figure as printed). That gap exists because the three prices describe different jobs.

Everything in this table is provider-published. We read each provider's own public pages. We did not buy, commission or run any of these tests, and a listed capability is not a promise that your quote includes it. Providers appear A to Z. This is not a ranking.

These are starting prices, not quotes. "Not stated" means we did not find it on the pages we read; it does not mean the provider won't do it. An unknown charge is not zero.

Two plain-English notes on the terms in that table. Firmware is the software that lives on the device. A debug port is a service interface on the circuit board, such as UART, JTAG or SWD, that engineers use during development.

Which hardware testing offer deserves a closer look?

For one simple device, start with the two providers that publish a starting price under most first budgets, send both the same brief, and let three answers decide: how many radios the price covers, whether your app and cloud are in, and the report date. Go to the quote-only specialists when the device is complex or the threat calls for lab work.

Who should rule an offer out: if your ceiling is under $25,000 and is in the same currency as Schellman's floor, its published floor excludes it unless the budget moves. If you cannot share any units for teardown, tell every provider first, because that changes what all of them can test.

If one of these fits, take the brief further down this page to the provider and confirm the open terms in writing.

This site may contain affiliate or referral links. If you buy through one, we may be compensated. How we make money

View Bishop Fox hardware penetration testing

View Invadel hardware and IoT pricing

View IOActive full stack security assessments

View NCC Group hardware and embedded services

View NetSPI hardware and embedded pentesting

View Schellman hardware and IoT testing

View Software Secured hardware pentesting

A worked example: one sensor, three published offers

This is how we check an offer against a buyer's needs. We call it the PenTest Index Purchase Check. Each row tests one requirement against one offer's published terms. The buyer is made up.

Say you make a battery-powered sensor with Bluetooth and Wi-Fi, a phone app and a cloud API. A customer wants a third-party test report on the device before a pilot in 10 weeks. You can spare three units. Your fixes will take about six months. Your ceiling is $15,000.

What this buyer should do: request written quotes from Invadel and Software Secured with the same brief, and leave Schellman out if its floor is in US dollars. If Invadel confirms both radios and a retest deadline past six months, it is the lower published start as printed. If the report date is what matters most, the provider that commits to it in writing wins. Nothing here says either one fits until those answers come back. "Supported" means that one condition has published evidence behind it. It is not a verdict on the provider.

No provider has quoted for this example. These are our calculations from published terms.

What should a hardware penetration test cover?

It should name the device, what the attacker is assumed to have, the firmware, and every port and radio. The app and the cloud need to be listed on their own, because the word "hardware" does not settle whether they are in.

This table is our own buying analysis. Use the right-hand column word for word in your quote request.

Three more terms, in plain words. Chip-off means removing a memory chip to read it directly. Fault injection means deliberately disturbing the device, for example its power or timing, to see whether a security check can be skipped. Side-channel analysis means learning secrets from unintended signals such as power use.

A firmware review alone does not answer a physical question. Reviewing an image you hand over can find software flaws. It does not show what a stranger can pull out of a shipping unit. If your customer asked about the device in someone's hands, the test has to include the device.

If you already pay someone to test your app or API, you may not need to buy that layer twice. Ask your current provider which targets their agreement covers, and scope the device work around it.

Looking for tools, courses or jobs in hardware hacking? This page is for buyers. And if you meant testing whether someone can break into a building, that is physical penetration testing, a separate service.

Why are hardware penetration test quotes so far apart?

Because "hardware" covers several depths of work, and the time, units and equipment depend on the methods and access. It is like asking for "a car inspection" without saying whether the mechanic should look under the hood or strip the engine.

Possible types of work, depending on access and scope:

1. Closed box. Test what an owner can reach without opening the case: ports, radios, the app.
2. Open the case. Find and use debug ports on the board.
3. Firmware. Pull the software off the device and take it apart.
4. Chip-off. Remove memory chips and read them directly.
5. Fault injection and side-channel. Lab attacks on the chip itself.

Invadel's own tiers show the split. Its $5,200 Small tier covers firmware, one or two debug ports and a radio. It puts chip-off, fault injection and side-channel work in a Large tier that is quoted after a scoping review, and it describes that work as "specialized bench work that only some threat models justify." (Invadel pricing page, read October 10, 2026.)

The second driver is the app and cloud. A device-only price and a device-plus-app-plus-API price are not the same job, even when both are called a hardware test.

So a low price is not automatically a bargain, and a high one is not automatically thorough. Line up what each one includes. For the wider budget picture, see published penetration test prices.

Copy this hardware scope brief before you request quotes

Send every provider the same facts, and ask each one to send back the same table. Then the answers line up and you can compare them. The two facts that move the price most are how deep testers may go and whether the app and cloud are in.

This brief does not authorize testing. Obtain written authorization covering the actual device, connected targets and permitted activities before work begins.

Do not put passwords, keys, firmware files or vulnerability details in the brief. Agree a secure way to share those with the provider you hire.

The hardware brief

1. Why and for whom. Why you need the test. Who will read the report and what they asked for. The date you need the report.
2. Device and versions. Product and model. Board revision. Firmware build. Any differences between test units and production units. Variants in the family.
3. What the attacker has. Remote only, nearby radio range, hands on the outside of the case, or case open. An ordinary user account, an admin account, or none.
4. Ports and radios. Each debug port, storage type and update method. Each radio. Write "unknown" where you don't know.
5. App, API and cloud. Each one, named. In or out of scope. Who owns it. Test environment or production.
6. Depth allowed. Closed box, teardown, chip-off, fault injection, side-channel. Mark each as allowed, not allowed, or ask us first.
7. Units. How many you can ship. How many may be destroyed. Whether they are production units or engineering samples.
8. What you will share. Firmware image, source code, schematics, debug builds, documentation. Agree which are required for the scope.
9. Logistics. Where the lab is. Shipping and customs. Return, disposal and data wiping. How prototypes are kept confidential.
10. Report. Versions tested. Scope, access and exclusions. Evidence and impact for each finding. Fix guidance. A technical report and an executive summary. Ask for a redacted sample.
11. Price and dates. Currency. Fixed total or billing basis. Optional phases. Shipping, travel and replacement costs. Start date and final report date.
12. Fix checks. Number of retest rounds. The deadline to request them and what starts the clock. Whether new firmware or a new board revision counts. Any fees.

Ask each provider to return this table

A blank cell is an open question. Do not read it as "included" or as "no charge."

The brief filled in for a made-up device

• Why and for whom: Customer security review before a pilot. Their security team reads the report. Needed in 10 weeks.
• Device and versions: Sensor S-1, board revision B, firmware 1.4. Test units match production.
• What the attacker has: Owns a unit and can open the case. Ordinary user account.
• Ports and radios: One serial debug header, USB-C for charging, internal flash storage, over-the-air updates. Bluetooth and Wi-Fi.
• App, API and cloud: iOS and Android app, in scope. Staging API, in scope. Production tenant, out of scope.
• Depth allowed: Closed box and teardown allowed. Chip-off, ask us first. Fault injection and side-channel, not requested.
• Units: Three available. One may be destroyed.
• What you will share: Firmware image and schematics. No source code.
• Logistics: Provider to state lab location, shipping needs and return plan.
• Report: Technical report and executive summary, tied to board B and firmware 1.4.
• Price and dates: Fixed total in US dollars. Report date in writing.
• Fix checks: One request about six months after the report, on patched firmware.

Reading the replies is then simple. A proposal that only reviews the firmware file fails the "owns a unit and can open the case" line. One that covers the device and radios but leaves the API cell blank stays open until that cell is filled. One that fills every must-have row and commits to the dates is a candidate to buy. An optional lab phase stays optional unless someone actually needs it.

Your brief now covers the device. The other half is the person who reads the report: what they need to see, and by when. Find My PenTest Match has the questions to ask them and a general scope checklist you can copy or print. It is free and asks for no email. It does not list hardware providers; that comparison is on this page.

Find My PenTest Match

For the general version of this exercise, see a filled-in penetration testing scope.

How long does a hardware penetration test take?

Published testing times run from about a week for a small device to four weeks, and the wait before testing can be longer than the test.

All three are the provider's own statements, read October 10, 2026. Add your own shipping time, and customs if units cross a border. If you have a deadline, ask for the final report date in writing before you sign.

Will testing damage the device, and how many units should you send?

Plan for at least one unit that may not come back working, and ask each provider how many they need and why. There is no universal number.

Schellman's own advice is to "ship a minimum of two of each in-scope devices," because a tester may need to take a circuit board apart, which "is likely to result in the device no longer functioning." (Schellman blog, March 26, 2025.) Software Secured says it asks permission before teardown and that some tests risk bricking a unit. Bishop Fox's methodology says testers may need production hardware plus development or debug versions, in multiple units.

Opening the case is not the same as destroying the device. The heavier methods are where the risk climbs. So write two numbers in your brief: units you can ship, and units that may be destroyed. If prototypes are scarce, say so before anyone quotes.

You do not always have to hand over firmware or source code. Schellman puts the choice this way: if you want to know how hard it is for an attacker to pull firmware off the device, don't supply it; if you want the firmware itself examined closely, do.

What should the report and retest agreement say?

The report should tie every finding to the exact board and firmware version tested. The retest agreement should say which fixes, which versions and which dates are covered.

Ask for these in the report:

• The hardware revision and firmware build tested.
• Scope, attacker access and exclusions, including anything planned but not completed.
• For each finding: evidence, steps to reproduce, impact and a practical fix.
• After a retest, the updated status of each finding.

These are our buying suggestions, not an official report standard. Whoever receives the report decides whether it meets their needs, so ask them before you buy. Our penetration testing report page covers what to look for in a sample.

Will a new board revision count as a retest? Not automatically. A fix that changes firmware is one thing. A fix that changes the board is new hardware. Get the answer in writing: which versions qualify, whether you ship new units, any fee, and the deadline. To turn a published window into a date, start from its stated trigger. Software Secured's runs from report delivery, so a report delivered January 15, 2027 means retests requested by January 15, 2028.

Does a law or standard require a hardware penetration test?

The device rules we read set security requirements for the product. The provisions we read do not name a penetration test. Whoever receives your evidence decides what they accept, so ask them.

All checked October 10, 2026.

What this means for you: the provisions make good test objectives. Put lines like "show whether debug interfaces are disabled or protected" and "look for hard-coded secrets in firmware" in your brief. A pentest report can be useful evidence. It is not a certificate.

Some products need a formal lab evaluation instead of, or in addition to, a penetration test. Payment terminals and cryptographic modules are common examples. Those evaluations follow the scheme's own rules and are done by labs the scheme recognizes. If a customer or regulator has named a scheme, ask them which labs and evidence they accept before you buy anything.

Questions buyers still ask

Is hardware penetration testing the same as IoT penetration testing?

The labels overlap, so read the scope list and not the name. Software Secured, for example, sells them as two offers: Hardware Pentesting from $12,400 USD and IoT Pentesting from $10,800 USD, with the phone app and cloud listed on the IoT card. Another provider may fold all of it into one "hardware" quote.

Does a UART or JTAG port on the board mean the device is vulnerable?

No. A port being there is not a finding. What matters is whether it is disabled or protected, what it exposes, and what an attacker can do through it. That is what the test is for.

Can testing one device cover the whole product family?

Not automatically. Invadel says findings "usually apply across the line" when products share firmware and a platform. That is a provider's view. List what the variants share and where they differ (board, radios, firmware, factory setup), and agree in writing which models the report speaks for.

A provider says its test follows OWASP. Does that certify the product?

No. OWASP's IoT Security Testing Guide is a public testing reference, and OWASP lists it as an Incubator project. Ask which parts the provider used. Following a guide does not certify a product or guarantee anyone will accept the report.

Sources and how we checked

We read each provider's public service, pricing and policy pages on October 10, 2026. We did not buy, commission or run any test, and we have not assessed any provider's testing quality. Prices and terms change, so confirm them with the provider. More on our approach is on the methodology page, and on how we make money.