July 31, 2026
ICS & OT Penetration Testing: Securing Industrial Systems
ICS & OT Penetration Testing: Securing Industrial Systems
Fiza Nadeem
New Update: Our new blog is updated.
Free download
Fiza Nadeem is an SEO content writer at ioSENTRIX with 2.5+ years of experience in content writing, copywriting, and SEO.
IoT devices have changed the way businesses collect data, automate processes, and connect physical environments to digital systems. Smart cameras, medical devices, industrial sensors, POS systems, and other embedded devices now communicate with APIs, cloud platforms, and enterprise networks.
This connectivity also creates a wider attack surface. A single IoT product may contain hardware components, firmware, wireless interfaces, cloud services, and physical access points. A weakness in any one of these layers can affect the security of the wider ecosystem.
This is where IoT penetration testing becomes important. It combines security testing across the device and its supporting ecosystem to determine how an attacker could gain access, manipulate functionality, or move into connected systems.
So, how do you penetration test an IoT device? The process typically starts with scoping and attack-surface mapping, followed by hardware testing, firmware analysis, network and wireless assessment, mobile and API testing, controlled exploitation, and remediation validation.
IoT penetration testing is a security assessment that simulates realistic attacks against an IoT device and the systems connected to it. It looks at how weaknesses can be discovered, combined, and exploited across different layers of the IoT ecosystem.
An assessment can include the device's hardware, firmware, operating system, network services, wireless interfaces, communication protocols, companion mobile applications, APIs, cloud infrastructure, and physical interfaces.
The scope depends on the product. For example, testing a smart camera may involve its firmware, web interface, Wi-Fi connection, mobile application, cloud API, and physical debug ports.
Testing an industrial IoT device may also require assessment of industrial protocols, device integrations, network segmentation, and operational technology environments.
This makes IoT security testing different from a conventional web or network penetration test. A web application test may focus primarily on HTTP requests, authentication, authorization, and application logic.
An IoT assessment may require a tester to inspect a circuit board, identify chips, access a UART interface, extract firmware, reverse engineer binaries, analyze wireless traffic, and then connect those findings to API or cloud weaknesses.
IoT penetration testing also considers physical attack surfaces. An attacker who can access a device may be able to interact with debug interfaces, extract firmware, recover secrets, or tamper with hardware. These risks are particularly important for devices deployed in public, industrial, healthcare, or other physically accessible environments.
Vulnerability scanning is useful for finding known vulnerabilities at scale. However, it generally does not provide the depth needed for embedded device security.
For example, a scanner may identify an outdated service running on an IoT device. A penetration tester can go further by determining whether that service can be exploited, whether authentication can be bypassed, what access it provides, and whether the weakness can be chained with another issue to compromise the device.
Manual testing is especially important for IoT products because hardware interfaces, proprietary protocols, firmware logic, device pairing, and business logic often require human analysis.
The OWASP IoT Security Testing Guide reflects this broader approach by organizing testing around areas such as processing units, memory, firmware, data exchange services, internal interfaces, physical interfaces, wireless interfaces, and user interfaces.
A complete IoT security assessment should map the full attack surface rather than treating the physical device as an isolated asset. Depending on the product and scope, testing can cover the following areas.
Hardware security testing examines the physical components that make up the device and the interfaces used to communicate with them. Testers may inspect the printed circuit board (PCB), identify chips and storage components, and look for exposed interfaces such as:
The assessment may also examine flash memory, secure elements, hardware-based authentication, physical tampering controls, and protections that prevent unauthorized access to device components.
A key objective is to determine whether physical access gives an attacker a path to privileged functionality or sensitive information.
For example, an exposed debug interface may provide access to a bootloader, operating system shell, memory, or configuration data that should not be available to an unauthorized user.
Firmware controls much of an embedded device's functionality, making it a critical part of embedded device security. Firmware analysis can reveal vulnerabilities that are not visible from the device's external network interface.
Testing may include firmware extraction, file-system analysis, binary analysis, reverse engineering, and dynamic analysis. Testers look for:
Firmware testing also helps determine whether the device properly protects its software from unauthorized modification. This can include reviewing secure boot, firmware signing, integrity checks, and update mechanisms.
IoT devices often communicate with other devices, applications, gateways, and cloud platforms through a combination of standard and IoT-specific protocols. Testing may cover:
Testers assess whether communications are properly authenticated and protected. They may examine encryption, certificate validation, session handling, replay resistance, message integrity, and protocol configuration.
The goal is not simply to determine whether encryption exists. The assessment should establish whether it is implemented correctly and whether an attacker can manipulate or replay messages, impersonate a device, intercept sensitive information, or send unauthorized commands.
Many IoT devices rely on Android or iOS applications for setup, configuration, monitoring, and remote control. As a result, the mobile application becomes part of the device's attack surface. Testing can cover:
For example, a mobile application may appear secure at the interface level but expose an API that does not properly verify whether the authenticated user actually owns the requested device. That could allow unauthorized users to access another customer's device or issue commands.
The cloud layer often handles device registration, authentication, telemetry, remote commands, updates, and user management. A weakness in the backend can therefore affect large numbers of connected devices.
Testing may examine:
An IoT security assessment should determine whether a compromise at the API or cloud layer can be used to control devices or access information belonging to other users.
IoT devices are often deployed outside traditional data centers. Some may be placed in homes, stores, hospitals, factories, vehicles, public spaces, or other locations where attackers can physically interact with them.
Testing can determine whether physical access allows an attacker to:
The level of physical testing should reflect realistic threats. A device installed inside a secured facility may have a different physical threat model from a consumer device mounted in a public location.
IoT penetration testing typically involves defining the scope, mapping the attack surface, analyzing hardware and firmware, testing network and wireless communications, assessing mobile applications and APIs, validating vulnerabilities through controlled exploitation, and reporting and retesting the findings.
A strong assessment follows a structured methodology because IoT products contain multiple connected components. OWASP's IoT Security Testing Guide similarly uses a device model, attacker model, testing methodology, and component-specific test cases to help testers build a consistent approach.
The first step is to establish exactly what will be tested and how testing will be performed. The scope may include:
Testers should also define what actions are prohibited. This is particularly important for industrial, medical, automotive, and other safety-sensitive environments.
For example, actively disrupting a production controller may create operational or safety risks. In such cases, testing may need to use a laboratory device, test environment, offline replica, or controlled maintenance window.
Clear rules of engagement ensure that the assessment produces useful security evidence without creating unnecessary operational risk.
Once the scope is established, testers build an inventory of the IoT ecosystem. This includes identifying:
The objective is to understand how the components communicate and where trust boundaries exist. For example, a connected camera may follow this path: Device → Firmware → Network → Mobile App → API → Cloud
Each connection represents a potential attack surface. A weakness in the mobile application may expose an API. An API flaw may expose device commands. A device command may then provide a route to sensitive functionality. Attack-surface mapping helps testers avoid focusing too narrowly on the device itself.
A hardware pentest examines the physical security of the embedded device. Testers may begin with PCB inspection and chip identification. They then identify available interfaces and determine whether they provide access to sensitive functions.
UART, JTAG, and SWD interfaces are particularly important because they can sometimes expose debugging or low-level access. SPI and I²C may also provide access to connected memory or peripherals, depending on the device architecture.
Testing can include:
The purpose is not simply to find an exposed port. Testers need to determine what access the interface provides and whether security controls prevent unauthorized use. Hardware testing can therefore uncover weaknesses that network-based testing would never see.
Firmware analysis is one of the most important parts of an IoT security assessment because firmware often contains the logic, configuration, credentials, and services that make the device operate.
Where authorized, testers obtain the target firmware from the vendor, update package, device storage, or other approved source. They then analyze its structure and contents. The process can include:
Firmware extraction: Obtaining the firmware from a legitimate source or directly from device storage when permitted.
File-system analysis: Identifying configuration files, scripts, binaries, certificates, keys, logs, and other embedded resources.
Static analysis: Reviewing firmware without executing it to identify suspicious functionality, insecure configurations, vulnerable components, and embedded secrets.
Binary analysis and reverse engineering: Examining compiled code to understand functions, control flow, security checks, and device behavior.
Dynamic analysis: Observing how the firmware behaves while running. OWASP's IoT testing guidance includes dynamic analysis of installed firmware to examine how data is processed and stored at runtime.
Testers may search for:
The assessment should also examine bootloaders and secure boot controls. If an attacker can replace firmware without proper signature or integrity verification, the device may be vulnerable to persistent compromise.
Firmware analysis should also evaluate the update mechanism. A secure device should restrict updates to authorized sources and verify that the software being installed is legitimate.
NIST's IoT guidance identifies secure software updates as a core device capability and recommends mechanisms that authenticate or verify updates before installation.
After understanding the device internally, testers assess its network-facing behavior. They identify exposed services and determine whether each service is necessary and adequately protected. Testing can look for:
IoT-specific protocols such as MQTT and CoAP deserve particular attention because they may carry device commands, telemetry, or sensitive information. For example, testers may determine whether an unauthorized client can subscribe to an MQTT topic, publish unauthorized commands, or access information belonging to another device.
The same principle applies to proprietary protocols. Even when a protocol is not widely documented, testers can analyze traffic to understand message structure, authentication mechanisms, encryption, and command handling.
.webp)
Wireless connectivity can introduce additional attack paths that are not visible from traditional network scans. Depending on the device, testing may cover:
Testers examine device discovery, pairing, authentication, encryption, and communication integrity. They may also assess:
The objective is to determine whether an attacker within realistic wireless range can interact with the device without proper authorization.
An IoT device should rarely be tested in isolation when a mobile application controls or communicates with it. The tester evaluates how the application authenticates users, stores information, communicates with APIs, and identifies devices.
Testing can include:
One important question is whether the backend trusts information supplied by the mobile application without independently validating it.
For example, changing a device identifier in an API request should not allow a user to control another user's device. Authorization must be enforced by the backend rather than assumed from the mobile application's interface.
This is why connected device security requires testing the complete relationship between the device, application, API, and cloud service.
Firmware updates are a critical part of the IoT security lifecycle. An attacker who can replace legitimate firmware with unauthorized code may gain persistent control over the device. Testing should evaluate:
A secure update process should verify that an update comes from an authorized source and that its integrity has not been compromised. NIST's current IoT capability catalog specifically includes authorized software updates and verification mechanisms such as digital signatures, checksums, and certificate validation.
Testers should also assess whether older firmware can be reinstalled after a device has been updated. Without downgrade protection, attackers may deliberately return a device to a vulnerable version and exploit a weakness that had already been fixed.
Finding a potential vulnerability is not always enough to determine its real risk. IoT penetration testing uses controlled exploitation to validate whether a weakness can actually be abused. Depending on the scope, testers may perform:
For example, an exposed debug interface may initially appear to be a high-risk finding. The tester can validate whether it provides privileged access, whether security controls restrict that access, and what an attacker could do after gaining it.
Exploitation must remain controlled and within the approved rules of engagement. The objective is to demonstrate realistic risk, not to cause unnecessary disruption.
Technical vulnerabilities need to be translated into business risk. The potential impact of an IoT compromise depends heavily on the device and its environment. Possible consequences include:
For example, compromising a consumer smart device may expose personal data, while compromising an industrial IoT device could affect production or operational safety. A strong assessment therefore considers both exploitability and consequence.
The final report should provide security teams with enough evidence to understand, prioritize, and fix each finding. A comprehensive IoT penetration testing report can include:
The report should explain not only what is wrong but also why it matters and how the organization can address it.
IoT vulnerabilities can exist at almost every layer of a connected product. The following issues are particularly important during an IoT security assessment.
Hardcoded usernames, passwords, API keys, certificates, and cryptographic keys can expose devices and supporting services.
Secrets stored in firmware or mobile applications may also be extracted through reverse engineering. If the same credential is reused across many devices, one compromised product could expose an entire device fleet.
Testers therefore examine firmware, applications, configuration files, and storage for credentials and other sensitive information.
Firmware may contain outdated components, unnecessary services, exposed debug functionality, insecure configurations, or weak security controls.
A device can appear secure from the outside while still containing serious weaknesses inside its firmware. This makes firmware analysis an essential part of embedded device security.
IoT devices may use default passwords, weak authentication mechanisms, or insufficient authorization checks. Another common concern is device ownership. A user should not be able to access or control another user's device simply by changing an identifier in an API request.
NIST's IoT guidance also emphasizes device identification and authentication as important capabilities for distinguishing authorized from unauthorized entities.
UART, JTAG, SWD, and other interfaces can provide low-level access to embedded systems. If these interfaces remain exposed without adequate protection, an attacker with physical access may gain access to firmware, memory, logs, or privileged functions.
A hardware pentest helps determine whether these interfaces are accessible and what security controls protect them.
Unencrypted traffic, weak encryption, poor certificate validation, and insecure proprietary protocols can expose sensitive information or allow attackers to modify device communications.
Testing should examine both the confidentiality and integrity of communications. Protecting data from unauthorized access and modification is also a core capability identified in NIST's IoT guidance.
An update mechanism that does not verify firmware authenticity or integrity can become a direct path to device compromise. Common issues include:
Secure updates should restrict installation to authorized software and verify updates before they are installed.
IoT cloud services often manage large numbers of devices. Weak access controls can therefore have a broad impact. Potential issues include broken authorization, exposed device commands, weak authentication, insecure direct object references, sensitive data exposure, and inadequate tenant isolation.
Testing should determine whether a compromise of one account or device can affect other users or devices.
Physical access can introduce risks that remote testing cannot identify. Depending on the design, attackers may extract firmware, access storage, recover secrets, connect to debug interfaces, or tamper with components. The level of protection should match the realistic physical threat model of the device.
IoT devices are often connected to networks containing other business-critical systems. If an attacker compromises an IoT device and the network does not properly isolate it, the device could become a stepping stone into internal infrastructure.
Testing should therefore examine whether IoT assets are appropriately segmented and whether communication between IoT, corporate, cloud, and operational networks is properly controlled.
Do not assess only the physical device. Include firmware, mobile applications, APIs, cloud services, network connections, wireless interfaces, and other integrations that are within scope. A weakness in one component may provide the entry point needed to compromise another.
Automated tools can provide broad coverage and quickly identify common issues. However, manual testing remains essential for hardware, firmware, proprietary protocols, device logic, and complex attack paths.
The strongest IoT security testing programs use both approaches rather than treating them as alternatives.
Firmware and hardware can expose deep-rooted vulnerabilities that are difficult to identify through external scanning. A device may have a hardened network interface but still expose sensitive credentials through firmware or provide privileged access through an unprotected debug port.
Individual vulnerabilities do not always show the full risk. Testers should determine whether multiple weaknesses can be chained together.
For example, an exposed API may provide device information, a firmware weakness may expose credentials, and a weak authorization control may then allow unauthorized device access.
Attack-chain testing helps organizations understand what a determined attacker could realistically achieve.
IoT security should extend across the device lifecycle. Assess security during:
NIST's updated IoT manufacturer guidance emphasizes cybersecurity activities across the product lifecycle, including pre-market and post-market considerations, maintenance, support, and end-of-life.
Fixing a vulnerability is not the final step. Retesting verifies that the original issue has been resolved and that the fix has not introduced another weakness. It also provides evidence that the organization's remediation efforts have reduced the actual security risk.
IoT security requires more than a conventional network scan. It requires an understanding of how hardware, firmware, communication protocols, applications, APIs, and device integrations work together.
ioSENTRIX provides specialized penetration testing for ICS, IoT, and IIoT environments, with testing focused on firmware, network communication protocols, device integrations, and business-critical functionality.
Its published methodology combines automated and manual testing to identify issues such as insecure firmware, weak authentication, communication protocol weaknesses, and insufficient access controls.
The approach also includes controlled exploitation to understand how vulnerabilities can be chained and what impact they could have. Findings are supported with Proof of Concept evidence and practical remediation guidance, followed by retesting to help verify fixes.
For organizations assessing connected and embedded products, this broader approach helps move beyond isolated vulnerability discovery toward understanding realistic attack paths.
Talk to ioSENTRIX today to assess your IoT attack surface and strengthen your connected devices against real-world threats.
IoT penetration testing typically begins with defining the scope and threat model. Testers then map the device's attack surface, inspect hardware and physical interfaces, analyze firmware, test network and wireless communications, assess companion mobile applications and APIs, examine update mechanisms, and validate vulnerabilities through controlled exploitation. The final stages involve reporting, remediation guidance, and retesting.
Traditional penetration testing often focuses on applications, networks, or infrastructure. IoT penetration testing can cover those areas but also adds hardware, firmware, wireless communications, physical interfaces, embedded operating systems, and device-specific protocols. IoT testing therefore requires a broader attack-surface model and may involve hardware analysis and reverse engineering in addition to conventional security testing.
Yes. Mobile applications and cloud APIs are often essential parts of an IoT ecosystem. If they control device registration, authentication, configuration, telemetry, or commands, they should be considered part of the attack surface when they are within scope. Testing them can reveal vulnerabilities that allow unauthorized users to access or control connected devices.
There is no single testing frequency that applies to every IoT product. Testing should be considered before launch, after major hardware or firmware changes, following significant architecture changes, after security incidents, and periodically during the product lifecycle. Organizations should also reassess devices when they are connected to new networks or integrated with sensitive systems.
A strong report should include the assessment scope, methodology, attack surface, individual vulnerabilities, severity, technical evidence, Proof of Concept details, business impact, attack paths, remediation recommendations, and retest results. The report should be useful to both technical and business stakeholders.
