Device security testing
Hardware penetration testing
We test the device itself: the board, the firmware, the boot chain and what an attacker can do with physical access.
WHY TEST THE DEVICE
BEYOND THE NETWORK EDGE
Test the device, not just the network around it. Network and application tests stop at the edge of the device.
Most security programmes assume the attacker is on the network. For ATMs, payment terminals, industrial controllers and other connected equipment that assumption fails: devices stand in shops, depots and cabinets where anyone can reach them, and they pass through service centres and warehouses. We test a device the way an attacker with physical access would, from the board and the firmware to the boot chain and memory, and show what can be extracted or changed.
TWO DIFFERENT ATTACKERS
A firewall does not help when the attacker is holding the device. Most devices need both: the network test covers how a device is reached, the device test covers what happens when it is held.
NETWORK AND APPLICATION TEST
Attacks the device through its network interfaces and its web or API services. Assumes the attacker is remote and the hardware is out of reach. Checks configuration, patching, exposed services and authentication. Leaves the board, the firmware image and the boot chain untested.
DEVICE PENETRATION TEST
Assumes the attacker holds the device, even for a few minutes. Tests debug ports, disk encryption, boot integrity and memory. Examines the firmware for hard-coded credentials and insecure data storage. Shows what physical access lets an attacker extract or change, and how to close it.
ATTACK SURFACE
A device test follows what an attacker with physical access would try, from the case and the ports to the firmware and the data inside. Each step is a point where the device either holds or gives way. The usual path: case and ports → USB and BadUSB → JTAG and UART → boot chain and Secure Boot → disk encryption → memory (cold boot) → firmware image and application package.
WHO THIS IS FOR
Banks and payment providers that operate ATMs and payment terminals. Suppliers and manufacturers in the defence sector. Energy and critical infrastructure operators with equipment outside the controlled perimeter. Manufacturers of industrial equipment and IoT devices preparing a product for market. Organisations that buy devices in volume and want independent assurance before rollout.
What we do
Scoping and threat model
We agree in writing which devices, interfaces and attacker scenarios are in scope (for example, someone who handles the device in transit or at a service centre) and which physical tests are allowed. We need the device, its documentation and, for the white-box phase, root access. Some tests can leave a unit altered or unusable, so we ask for spare units, ideally from the same batch as production, and agree the limits before anything starts.
Black-box physical attacks
Without internal knowledge, we test the vectors seen on devices in the field: disk encryption bypass, Secure Boot and USB boot, JTAG and UART debug interfaces, cold boot memory extraction and BadUSB. Each scenario is recorded on video so your team can repeat it.
White-box review
With root access we audit operating system hardening, the boot chain rooted in the Trusted Platform Module (TPM 2.0) and the integrity of the application package that runs on the device. An AI agent automates routine checks, and a specialist decides what is a real risk.
Report and walkthrough
Findings are documented as attack scenarios with screenshots and evidence, then walked through with your engineers. A retest of the fixes can be agreed in the scope.
Reproducible evidence
Every attack scenario is recorded on video with screenshots, so your engineers can repeat it and see the result themselves.
Risk reports
Attack scenarios with proof, impact and severity for each finding, plus technical data for your engineering team.
Navigator
A project database for working through the results, filtered by severity and affected component, instead of one long PDF.
Executive report
A final report for management in business language, with overall risk and priorities. A sample pentest report is available on request, so you can see the format first.
Tell us where they travel and who can touch them, and we will propose a test scope.
What is hardware penetration testing?
Testing the device itself rather than the network around it. We examine physical interfaces such as UART and JTAG, storage encryption, boot integrity, memory and firmware to see what an attacker with physical access could extract or change. It complements network and application testing and does not replace them.
What is the difference between black-box and white-box device testing?
Black-box testing starts with the device as an attacker would find it, with no internal knowledge, and tries physical attacks such as disk encryption bypass, USB boot or debug port access. White-box testing starts with root access and audits operating system hardening, the boot chain and the integrity of the software that runs on the device.
Do you test IoT devices as well as industrial hardware?
Yes. For Internet of Things (IoT) devices we add firmware analysis and reverse engineering, review of communication protocols and authentication, checks for hard-coded credentials and analysis of how data is stored and transmitted. We also test whether a compromised device could become a way into the rest of your network.
Which standards and regulations does this relate to?
We work from NIST SP 800-193 (firmware resilience), ETSI EN 303 645 (baseline security for consumer IoT), the TPM 2.0 specification, UEFI Secure Boot and the Linux IMA/EVM integrity model. For products sold in the EU, the Cyber Resilience Act requires manufacturers to apply effective and regular tests and reviews of product security, and a device test gives you technical evidence for that.
What do you need from us, and how long does it take?
Spare units of the device, ideally from the same batch as production, and any documentation you have. White-box work also needs root access. Some physical tests can leave a unit altered or unusable, so we agree the tests and their limits in writing. Duration depends on the device and the scope, and we confirm it before work starts.
Our certificates
Team portfolio
Where to start?
You can copy our materials only after making sure that your services are safe.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.