Hardware Penetration Testing

Hardware Penetration Testing is the authorized security assessment of physical hardware devices — embedded systems, printed circuit boards (PCBs), microcontrollers, debug interfaces, and the firmware running on them. It targets a layer of the attack surface that software-only testing cannot reach: the physical device itself, its buses, its storage chips, and the electrical signals that carry secrets.

Where a network or web application pentest operates through software interfaces, hardware pentesting requires hands-on interaction with the device — probing test points, soldering wires to chip pins, capturing bus traffic with logic analyzers, and extracting firmware from flash memory. The findings often reveal weaknesses that persist across entire product lines because they are baked into the hardware design.

Who commissions this test?

Hardware penetration tests are commissioned by product security teams, R&D departments, hardware manufacturers, automotive OEMs, medical device companies, and consumer electronics makers. The request typically comes from a product security lead or engineering management and is driven by pre-launch security validation, regulatory certification requirements, or competitive benchmarking against industry security standards.

Test objectives

The primary objectives are to assess the physical attack resistance of a device, to determine whether an attacker with physical access can extract sensitive data (firmware, cryptographic keys, credentials), to evaluate the effectiveness of hardware security mechanisms (secure bootSecure BootLaunches only cryptographically trusted boot components and firmware., tamper protectionTamper ResistanceA system's characteristic of making physical or logical tampering difficult., encrypted storage), and to identify design weaknesses that could be exploited at scale. Secondary objectives often include evaluating whether debug interfaces left enabled in production could serve as a backdoor and whether side-channel attacksSide-Channel AttackAttack that exploits indirect information such as timing, power consumption, or electromagnetic emissions. could leak cryptographic material.

What is tested?

Testing covers the full hardware attack surface: exposed debug interfaces (JTAG, SWD, UART, cJTAG) on the PCB, flash memory and EEPROM contents (firmware extraction via chip-off, in-circuit reading, or debug interface), bus communication between components (SPI, I2C, CAN, LIN), secure boot implementation and bypass attempts, cryptographic key storage and extraction resistance, tamper detection and response mechanisms, side-channel leakageSide-Channel AttackAttack that exploits indirect information such as timing, power consumption, or electromagnetic emissions. (power analysis, electromagnetic emissions, timing), firmware integrity and binary analysisBinary AnalysisExamination of compiled programs without necessarily having access to the source code. (hardcoded credentials, debug symbols, unstripped binaries), hardware security modules and secure elements, and physical enclosure security (tamper-evident seals, lock mechanisms).

Common findings

• Exposed JTAG or UART debug interfaces — Test points or headers left on production PCBs that provide full access to the processor, including memory reads, firmware dumps, and real-time debugging
• Unencrypted firmware on external flash — Firmware stored in plaintext on SPI or parallel flash chips, extractable with a chip clip or by desoldering the chip
• Weak or missing secure boot — No cryptographic verification of firmware integrity at boot, allowing an attacker to modify firmware and flash it back
• Hardcoded credentials in firmware — API keys, passwords, symmetric encryption keys, or private certificates embedded in firmware binaries discoverable through static analysis
• Unprotected bus communication — Sensitive data (credentials, configuration, commands) transmitted in cleartext over SPI, I2C, or UART between components on the PCB
• Missing tamper detection — No mechanisms to detect physical case opening, PCB probing, or chip removal, allowing undetected hardware analysis
• Extractable cryptographic keys — Keys stored in general-purpose flash rather than in hardware security modules or one-time-programmable (OTP) fuses
• Side-channel leakage — Power consumption or electromagnetic emission patterns that correlate with cryptographic operations, enabling key recovery through differential power analysis (DPA) or simple power analysis (SPA)
• Unlocked microcontroller readout protection — Flash memory read protection not enabled or set to a bypassable level, allowing direct firmware extraction through the debug port
• Testpad maps matching known development boards — Production hardware using reference designs with all debug access retained

Typical engagement workflow

Initial inquiry — The manufacturer contacts the pentest team, typically ahead of a product launch, certification milestone, or in response to a competitor’s device being publicly compromised. The type of device, its purpose, security-relevant features, and the number of sample units available are discussed.

Scoping conversation — A detailed technical discussion with the product engineering and security team to understand the hardware architecture, processor family, communication protocols, security features implemented (secure boot, encryption, tamper protection), and what level of attacker the assessment should simulate (opportunistic attacker with consumer tools vs. resourced adversary with lab equipment). Destructive testing boundaries are defined — whether the tester may desolder components, decap chips, or perform invasive analysis.

Proposal and approval — A proposal specifies the testing methodology (non-invasive, semi-invasive, invasive), equipment to be used, expected duration, number of device samples required, and deliverables. Engineering management and legal review the proposal. Costs for specialized equipment or analysis (e.g., chip decapsulation, FIB work) are outlined.

Scope definition — The specific device model, firmware version, and hardware revision are documented. Areas of focus are prioritized — for example, debug interface lockdown vs. side-channel resistance vs. firmware extraction. The number of device samples provided accounts for potential destructive testing.

Letter of engagement — Signed authorization covering legal protection, intellectual property handling (the tester will see proprietary firmware and hardware designs), NDA terms, and the process for handling critical vulnerabilities found during testing.

Additional authorizations — If the device connects to cloud backends or mobile apps that will be tested alongside the hardware, separate scoping and authorization for those components is arranged.

Information exchange — Depending on the approach, the manufacturer provides device samples, schematics, bill of materials, firmware source or binaries, debug credentials, and documentation of security features. For Black-Box assessments, only the device itself and publicly available documentation are provided. The tester receives enough samples to allow for destructive analysis where agreed.

Kick-off call — Alignment with product engineering, security, and project management on the testing schedule, communication cadence, and points of contact for technical questions about the hardware design.

Execution — Testing follows a progressive approach: visual PCB inspection and component identification, non-invasive probing (identifying active JTAG/UART/SWD interfaces, bus sniffing), firmware extraction attempts (via debug interfaces, flash chip reading, bootloader exploits), firmware analysisFirmware SecurityProtects low-level software, boot processes, and hardware functions from tampering. (binary reverse engineering, string analysis, cryptographic material hunting), secure boot bypass attempts, and — where authorized — invasive analysis (chip-off, decapsulation, side-channel measurements). The tester documents every step with photographs, oscilloscope captures, and logic analyzer traces. Critical findings are communicated immediately.

Vulnerability assessment and rating — Findings are documented with physical evidence (photographs of exposed test points, logic analyzer captures, firmware dumps), rated by severity, and assessed for scalability — whether the attack works against a single device or every device of that model.

Final report — The report provides each finding with photographic and technical evidence, a clear description of the attack, equipment required, skill level needed, and remediation recommendations that are feasible within the hardware design lifecycle (PCB respin, firmware update, configuration change).

Presentation — Results are presented to product engineering, security leadership, and executive management. The presentation demonstrates the most critical attacks and maps findings to product risk.

Project closure — Remediation priorities are agreed, considering hardware revision timelines (PCB changes require longer lead times than firmware fixes). Recommendations for security improvements in the next hardware revision are documented.

Who should commission this test — and when?

Hardware manufacturers should commission hardware penetration testing before launching any product where device compromise poses a security, safety, or intellectual property risk. This includes IoT device makers, automotive OEMs (for ECUs, telematics units, infotainment systems), medical device manufacturers, industrial equipment producers, smart card and payment terminal vendors, and consumer electronics companies. The EU Cyber Resilience Act and sector-specific regulations increasingly require evidence of hardware security validation. Testing should be performed before initial market release, after significant hardware revisions, when integrating new security components (secure elements, TPMs), and periodically for products in long-lifecycle deployments.

Related concepts

• Penetration TestingPenetration TestingAuthorized, methodical testing of a system for exploitable weaknesses, to find them before real attackers do.: Authorized, methodical testing of systems for exploitable weaknesses.
• Firmware SecurityFirmware SecurityProtects low-level software, boot processes, and hardware functions from tampering.: Protecting the software that runs directly on hardware from extraction, modification, and exploitation.
• Side-Channel AttackSide-Channel AttackAttack that exploits indirect information such as timing, power consumption, or electromagnetic emissions.: Extracting secrets by observing physical characteristics of a device during operation.
• Tamper ResistanceTamper ResistanceA system's characteristic of making physical or logical tampering difficult.: Hardware design measures that detect or prevent physical manipulation of a device.
• Secure BootSecure BootLaunches only cryptographically trusted boot components and firmware.: A mechanism that verifies firmware integrity before execution, preventing unauthorized code from running.
• Binary AnalysisBinary AnalysisExamination of compiled programs without necessarily having access to the source code.: Examining compiled code to understand functionality, find vulnerabilities, and extract embedded data.