IoT and OT Penetration
Testing Services | UK
Expert industrial control system (ICS) and IoT device security testing methodologies using a passive-first approach to ensure operational safety and uptime.
What Is ICS and IoT Device
Penetration Testing?
ICS and IoT device penetration testing is the safety-first security testing of the operational technology and connected devices that control physical processes, using methods designed so the testing itself never endangers the process.
An industrial control system (ICS) is the hardware and software that monitors and controls physical industrial operations. These systems typically comprise:
- Supervisory Control and Data Acquisition (SCADA) systems
- Programmable Logic Controllers (PLCs)
- Remote Terminal Units (RTUs)
- Distributed Control Systems (DCS)
- Human-Machine Interfaces (HMIs)
- Sensors and engineering workstations
OT testing targets process-control networks and their components, while IoT device testing targets the devices themselves, including firmware, hardware interfaces, radios, companion apps, and cloud APIs.
In OT environments, availability and safety outrank confidentiality. The classic confidentiality-integrity-availability priority flips: how readable the network is matters less than whether the process can be safely maintained or stopped. This inversion is why ICS testing is a distinct discipline, rather than a standard IT vulnerability scan retargeted at industrial infrastructure.
ICS / OT Components
SCADA, PLCs, RTUs, DCS, HMIs, sensors, and engineering workstations controlling physical processes.
IoT Device Targets
Firmware, hardware interfaces, radios, companion apps, and cloud APIs powering connected devices.
The Passive-First
Escalation Ladder
Our ICS/OT testing follows a passive-first escalation ladder: we map and analyse without touching live processes, replicate anything risky in a lab, and only run controlled active checks inside agreed windows with an ICS engineer approving each action. We never promise zero disruption; we promise a documented safety process with managed risk.
Minimal disruption is achieved through the following operational mechanics:
- Passive-first ordering of all activities.
- Lab validation of any active technique before live application.
- Per-action engineer approval for active checks.
- Strict maintenance-window scheduling.
- Defined stop/abort conditions.
- Zero lockout-inducing actions.
- No destructive testing on live devices.
Every engagement is governed by a rules-of-engagement document that names the safety contacts, the fail-safe states that must be preserved, and the explicit conditions under which testing stops immediately.
Tier 1: Passive
Passive testing utilizes SPAN-port monitoring and passive protocol capture to map assets and zones using the Purdue reference model (levels 0–5, zones and conduits) as scoping language. This phase involves zero operational contact with live systems. Passive analysis identifies the protocol mix, the data flows between zones, and the assets that would be unsafe to touch in later phases, which directly shapes the entire engagement plan.
Tier 2: Lab/Bench Replication
Lab replication involves firmware and device testing performed off-network, using testbed emulation for fragile, unpatchable, or safety-critical systems. We are transparent about the trade-off: lab replication takes more time and may not perfectly mirror production fidelity, but it eliminates risk to live operations. This tier is where firmware analysis, hardware interface investigation, and exploit validation happen, ensuring anything that could cause a fault on a live device is proven safe in the lab first.
Tier 3: Controlled Active
Controlled active testing consists of targeted checks run in maintenance windows, on-site, with named safety contacts and per-action approval. Explicit stop conditions are agreed before testing begins, including the safety instrumented functions and fail-safe states that must never be disrupted. Our working rule is no exploit execution on live process networks; where a finding needs proof of impact, that proof is obtained in the lab, not on production.
Protocol-Aware Findings
Testing validates the hardening pipeline (inventory → segment → harden → test) and does not replace any of those steps. The value of testing is proving that the pipeline has actually produced a defensible boundary.
| Protocol | What testing looks like | Common findings | Why remediation differs |
|---|---|---|---|
| Modbus/TCP | Passive capture and analysis of function codes; targeted checks on register access | Missing native authentication | This is a design limitation, not a configuration error. Remediation relies on segmentation and conduit control, not "add passwords." |
| DNP3 | Validation of secure-authentication options where deployed; analysis of unsolicited responses | Weak or absent authentication on legacy links | Where secure authentication is available, validate its configuration; where not, compensating controls and monitoring are required. |
| OPC UA | Assessment of the certificate-based security model for misconfiguration | Improper certificate validation or disabled security policies | This is a configuration flaw; remediation involves enforcing correct certificate chains and security policies. |
| PROFINET, EtherNet/IP, S7comm, IEC 60870-5-104, BACnet | Protocol-aware packet analysis and targeted checks within agreed scope | Non-encrypted traffic, missing integrity checks, rogue device access | Each protocol has distinct security models; remediation must map to the specific protocol's capabilities and the asset's role. |
How IoT Device Penetration
Testing Works
IoT device penetration testing targets the device itself — its firmware, hardware interfaces, radio communications, update mechanism, and the mobile app and cloud backend behind it — and unlike OT testing, destructive techniques are acceptable on development samples.
- Firmware analysis: Extraction from flash or update packages, static analysis, hardcoded credential identification, and review of embedded services. This layer often reveals backdoor accounts, debug interfaces left enabled in production builds, and hardcoded encryption keys that would let an attacker impersonate the device or decrypt its traffic.
- Update-mechanism review: Testing of signing, rollback protection, and the use of plaintext channels for update delivery. A device that accepts unsigned updates or lacks rollback protection can be permanently compromised by an attacker who intercepts one update cycle.
- Radio/wireless interfaces: Assessment of BLE, Wi-Fi, and Zigbee for pairing weaknesses, replay attacks, and range assumptions. Many IoT devices pair once and never re-authenticate, meaning an attacker within radio range can join the network or impersonate a trusted sensor.
- Hardware interfaces: Investigation of debug ports such as UART, JTAG, and SWD, plus flash extraction. This is normal and safe in device testing because the device is off-production. A device that leaves debug ports enabled in production can have its firmware extracted and cloned, defeating the security of every other layer.
- Companion mobile app and cloud API layer: Review of authentication, token handling, and API authorisation. A device's real risk often sits in its cloud management plane, not in the physical plastic. Testing the app and API reveals weak token handling, broken object-level authorisation, and insecure password-reset flows that let an attacker take over devices at scale.
The destructive-testing trade-off is explicit: development samples can be broken, but production-deployed devices follow the same passive-first discipline as OT. This is a material difference in depth; on dev samples we can desolder chips, dump flash, and attempt fault injection, whereas on production devices we limit ourselves to non-invasive checks.
Firmware Analysis
Extraction from flash or update packages, static analysis, hardcoded credential identification, and review of embedded services. This layer often reveals backdoor accounts, debug interfaces left enabled in production builds, and hardcoded encryption keys.
Update-Mechanism Review
Testing of signing, rollback protection, and the use of plaintext channels for update delivery. A device that accepts unsigned updates or lacks rollback protection can be permanently compromised by an attacker who intercepts one update cycle.
Radio / Wireless Interfaces
Assessment of BLE, Wi-Fi, and Zigbee for pairing weaknesses, replay attacks, and range assumptions. Many IoT devices pair once and never re-authenticate, meaning an attacker within radio range can join the network or impersonate a trusted sensor.
Hardware Interfaces
Investigation of debug ports such as UART, JTAG, and SWD, plus flash extraction. This is normal and safe in device testing because the device is off-production. A device that leaves debug ports enabled in production can have its firmware extracted and cloned.
Companion App & Cloud API
Review of authentication, token handling, and API authorisation. Testing the app and API reveals weak token handling, broken object-level authorisation, and insecure password-reset flows that let an attacker take over devices at scale.
The Destructive-Testing Trade-off
Development samples can be broken — desoldered, dumped, fault-injected. Production devices follow the same passive-first discipline as OT. This is a material difference in depth: on dev samples we can desolder chips, dump flash, and attempt fault injection; on production devices we limit ourselves to non-invasive checks.
OT vs IoT vs IT Testing: Which Test
Does Your Estate Need?
If your risk lives in a process network, you need an OT assessment; if it lives in a device you ship or deploy, you need IoT device testing; if your corporate IT can reach either, you need a hybrid scope.
| Aspect | OT Penetration Testing | IoT Device Penetration Testing | IT Penetration Testing |
|---|---|---|---|
| What is tested | Process-control networks and components (PLCs, RTUs, HMIs, historians) | The device itself: firmware, hardware, radios, companion app, cloud API | Corporate IT infrastructure, applications, and endpoints |
| How it is tested | Protocol analysis, passive mapping, controlled active checks in windows | Firmware extraction, static analysis, radio interface testing, hardware debug | Standard IT vulnerability scanning and exploitation techniques |
| Acceptable destructive testing | No destructive testing on live devices | Yes, on development samples | Generally avoided in production; tested in staging where possible |
| Disruption risk | Managed through safety process; never zero | Low for off-production devices | Moderate; can impact availability if not scoped |
| Typical findings | Segmentation gaps, protocol weaknesses, design limitations | Hardcoded credentials, insecure update mechanisms, weak pairing | Misconfigurations, unpatched software, access-control issues |
| Typical deliverables | Report ranked by operational and safety impact | Technical report with firmware, hardware, and API findings | Standard pentest report with CVSS-scored findings |
Manufacturing Lines
OT assessment for the control network and IoT testing for any smart sensors or connected machinery on the line. The key difference is safety: the control network demands passive-first discipline, while smart sensors can often be tested destructively off-line before deployment.
Energy and Utilities
OT assessment for critical infrastructure and IoT testing for smart meters and remote monitoring units. Availability is paramount, as a failed meter reading is tolerable but a failed substation control is not.
Building Management Systems (BMS)
OT assessment for HVAC and access-control networks and IoT testing for smart controllers and sensors. BMS estates often mix IT and OT equipment on shared infrastructure, making clear zone boundaries essential before testing starts.
Logistics/Cold-Chain Monitoring
IoT device testing for trackers and environmental sensors and network testing for the data backbone. The safety constraint is product integrity, not human safety, so testing can be more aggressive, though false alarms during transit are a real cost.
Connected-Product Makers
IoT device testing across the product range and cloud assessment for the management backend. For makers shipping consumer devices, the UK product-security regime (PSTI) and ETSI EN 303 645 set the minimum bar; testing validates the controls those regimes expect.
Testing Hybrid
IT/OT/IoT Environments
Most real compromises of OT and IoT estates arrive through the layers around them: the corporate network above and the cloud platforms behind. Testing must therefore span these domains to expose the paths an attacker would actually use.
Corporate IT → OT Pivot
Attackers often enter through vendor remote-access links, jump hosts, or flat paths across the Purdue Level 3/4 boundary. These routes are a test target, not just a hardening step.
Vendor remote-access appliances are particularly high-value targets because they sit on the boundary, often have weak authentication, and provide a direct channel into the process network. The test simulates what an attacker who has compromised a helpdesk laptop or a vendor support account could actually reach.
If your IT estate connects to your OT network, you need network penetration testing for the IT estate connected to your OT network to validate where those boundaries actually hold.
IoT Field Devices → Cloud Management Plane
Weak API authentication, compromised device-management backends, and unsecured update infrastructure are common attack surfaces. A single compromised management credential can give an attacker control over every device in the field, turning a single device weakness into a fleet-wide incident.
The device test finds local weaknesses, while the cloud test finds whether those weaknesses can be exploited at scale.
If your IoT devices depend on a cloud backend, you need cloud penetration testing for IoT platforms and device backends to assess the security of that management layer.
IT/OT convergence is the driver; hybrid testing is the response. A hybrid scope tests the paths between domains, not just each domain in isolation.
Why UK Organisations
Test ICS and IoT Systems Now
Testing generates the evidence these regimes expect: documented, current assurance over the systems that keep your operations running.
| Driver | What testing contributes |
|---|---|
| UK NIS Regulations 2018 / NCSC Cyber Assessment Framework (CAF) | Evidence for essential services that security measures are in place and effective, supporting CAF objectives on managing security risk and protecting against cyber attack. |
| NIS2 (for EU-exposed organisations) | Documented assurance for organisations operating in the EU, supporting compliance evidence under the successor regime. |
| IEC 62443 | Testing validates the zones, conduits, and security levels defined under the standard. It also provides the assurance evidence that an assessor would expect to see for SL-A claims. |
| NIST SP 800-82 | Testing aligns with the risk-management guidance for industrial control systems, providing the validation step that the guidance calls for. |
| MITRE ATT&CK for ICS | Findings are mapped to known adversary techniques, making the risk tangible to management and prioritised against real-world attack patterns rather than abstract vulnerability scores. |
| ETSI EN 303 645 and UK product-security regime (PSTI) | For connected-product makers, testing validates the security requirements for consumer IoT devices, including the absence of default passwords and the security of update mechanisms. |
| Insurer and board assurance | Non-regulatory driver; testing provides current, documented risk posture for renewals and investment decisions. Insurers increasingly ask for evidence of OT testing as a condition of cover for industrial risk. |
Testing supports and informs these programmes; it does not equal certification against any scheme. A test is a point-in-time validation, not a certificate of ongoing compliance.
[Note: verify current status of UK NIS, CAF, NIS2 applicability, and the UK product-security regime before publication.]
Are You Ready to Be Tested?
Prerequisites & Scheduling
You don't need a perfect asset inventory to start, but you do need to know what must never stop. A pre-engagement checklist helps you confirm readiness.
- Asset inventory (or a commitment to discovery-first)
- Network diagrams, including the Purdue levels in scope
- Protocol list
- Remote-access inventory — especially vendor links and jump hosts
- Maintenance windows
- Named safety and operations contacts with authority to approve or stop testing
- Agreed stop conditions, including the fail-safe states that must never be disrupted
- Site sign-off process for the rules of engagement
Honest-advisor note: If no inventory exists, passive discovery is a legitimate first engagement. This pre-qualifies rather than disqualifies you. A discovery-first engagement builds the asset map and protocol inventory that a future full test will need, and it carries essentially no operational risk because nothing is touched.
When not to choose full pentesting yet:
- Unmapped estate: Choose passive discovery first. Testing blind risks missing the critical assets and wasting the active window on low-value targets.
- Fragile unpatchable systems with no lab: Choose lab replication first. If a device is known to fail under load and there is no testbed, active testing on production is the wrong call.
- No site sign-off: Wait until operations and safety teams have approved the rules of engagement. Testing without that sign-off creates unacceptable liability for both sides.
Scheduling is production-driven. Active testing should align with maintenance windows, shutdown seasons, or commissioning periods. Passive monitoring can run anytime and is often the right first step while windows are being scheduled. On-site lead times require coordination with site engineers, so timelines follow your operational calendar, not the other way round. A typical engagement runs from initial scoping to report delivery over four to eight weeks, but the active phase itself is compressed into your available windows.
Deliverables, Reporting &
Engagement Models
Every engagement ends with a report ranked by operational and safety consequence, describing what an attacker could actually do to your process. CVSS is treated as an input, not the verdict. A CVSS 9.0 flaw on an internet-facing IT server is treated differently from a CVSS 6.0 flaw that could trip a safety instrumented function, so the report ranks by what matters to your operation rather than a generic severity score.
A good OT/IoT report includes:
- Executive summary for operations leadership: Outlining what was found, what it means for the process, and what to do first.
- Technical detail with reproduction steps: Ensuring your engineers can verify each finding and re-test fixes.
- Operational and safety impact ranking: Detailing what an attacker could actually do to the process.
- MITRE ATT&CK for ICS mapping: Showing which adversary techniques each finding corresponds to, where useful.
- Remediation roadmap: Distinguishing configuration fixes from design-limitation mitigations such as segmentation and compensating controls.
- Debrief and walkthrough: A working session with the testers rather than just a document.
- Optional retest to confirm that agreed fixes have been implemented effectively.
Delivery stages: Scoping call → Rules of engagement → Passive phase → Lab/active phase per scope → Reporting and debrief.
OPTIONAL RETESTEngagement models vary by phase. Remote phases: Cover passive monitoring, firmware analysis, and reporting. On-site phases: Required for controlled active testing in maintenance windows and for any hardware-level device testing. Some engagements are entirely remote, typically discovery-first or firmware-only scopes, while full OT assessments usually need at least one on-site visit for the active phase.
Scope and complexity factors that affect an engagement include: number of sites and protocols, Purdue levels in scope, number of device families, lab availability and window access. These are confirmed during scoping. A single-site, single-protocol assessment is very different from a multi-site, multi-protocol programme, and the scope is designed to fit your estate rather than forced into a fixed template.
Who Performs the Testing — and How
to Compare ICS/OT Providers
Questions to ask any provider
Use these criteria to determine if a provider understands the physical risks associated with operational technology.
- 1. What is your ICS-specific methodology, and what are your stop conditions? If they cannot articulate stop conditions, they have not thought about what could go wrong.
- 2. What is your safety case, and how does per-action approval work? Who on their team can halt a test, and under what circumstances?
- 3. Which protocols do you cover, and how do you interpret findings differently per protocol? A provider that treats Modbus like HTTP has not done OT work.
- 4. How do you rank findings: by safety or operational impact, or by raw CVSS? The answer tells you whether they understand your environment.
- 5. Do you have lab capability for fragile or unpatchable systems? If not, what is their plan for devices that cannot tolerate active testing?
- 6. What is your sector experience? Manufacturing, utilities, and BMS have different safety profiles and protocol mixes.
- 7. Can you share a redacted report structure? The report is the product, and you should see what you are buying before you buy it.
Common mistakes when buying
Avoid these common pitfalls to ensure your testing engagement does not inadvertently cause the downtime it is meant to prevent.
- ✕ Treating OT like IT and running aggressive scans, which is how production lines stop and safety systems trip.
- ✕ Assuming scanning tools are safe by default; many active scanners send probes that legacy devices cannot handle.
- ✕ Ignoring vendor remote-access links as a test target, as these are the single most common entry point into OT networks.
- ✕ Conflating compliance certification with security testing; certification proves process, while testing proves posture.
- ✕ Scheduling active tests without site sign-off, which creates liability and risks a safety incident.
Practitioner caveats we work with
Our testing is performed by practitioners with ICS-relevant experience. [Credential slots to confirm: GICSP, GRID, GCIP, IEC 62443 certificates, CREST, OSCP.]
- Legacy systems: Compensating controls are validated, not assumed. If a system cannot be patched, the test verifies that the segmentation, monitoring, and access controls around it actually hold.
- Fragile devices: Lab replication is used. If there is any doubt about whether a device will survive a test, it goes to the lab first.
- Design limitations: These are distinguished from misconfigurations. The report tells you which findings you can fix with a configuration change and which need an architectural mitigation.
- Production-driven timelines: Active testing waits for windows. The testing schedule bends around your operational calendar.
We are a London-based team delivering nationwide across the UK. To help you compare ICS/OT providers, we recommend reviewing these safety-first criteria.
[Credential slots to confirm: GICSP, GRID, GCIP, IEC 62443 certificates, CREST, OSCP.]
Frequently Asked Questions
Find answers to common technical and methodology questions regarding the security testing of industrial control systems and connected devices.
What is an industrial control system (ICS)?
An industrial control system (ICS) is the hardware and software used to monitor and control physical industrial processes. It encompasses SCADA systems, PLCs, RTUs, DCS, HMIs, sensors, and engineering workstations, all working together to manage operations such as manufacturing, energy distribution, and water treatment. These systems act on the physical world, meaning safety and availability outrank data protection in their security priorities.
What is an OT penetration test?
An OT penetration test is a security assessment of operational technology networks and components, including PLCs, RTUs, and HMIs. Unlike generic ICS security reviews, it uses a safety-first, passive-to-active methodology to identify vulnerabilities without disrupting the physical process under control. The test validates whether an attacker could manipulate the process, disrupt availability, or move laterally from IT into OT under rules of engagement that protect the process first.
What are the 5 C's in security?
The 5 C's are commonly cited as change, compliance, cost, continuity, and coverage, though definitions vary across sources. In OT environments, continuity (availability) is the dominant factor because a process outage can have safety consequences. A testing approach that could stop a production line fails the continuity test regardless of how thorough its coverage is.
What are the four main types of access control methods?
The four main types are discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based/rule-based access control (ABAC/RuBAC). In OT environments, testing focuses on how these apply to engineer workstations, jump hosts, vendor remote-access accounts, and physical controller access. A common finding is over-reliance on a single model, such as having RBAC on the network while physical access to controllers remains completely open.
What are the top security testing tools for ICS and IoT?
Tool choice follows the agreed safety methodology, never the reverse. Effective ICS and IoT testing uses several tool categories:
- Passive discovery and protocol analysis tools
- Firmware extraction and analysis tools
- Controlled protocol-aware assessment tools
- Lab emulation or honeypot frameworks
Aggressive scanning tools are not appropriate for live production OT networks. The right tool depends on the tier: passive capture tools for Tier 1, firmware analysis tools for Tier 2, and controlled protocol-aware tools for Tier 3.
Start with a Scoping Call
Tell us about your environment and we'll tell you, honestly, what can be tested safely and how.
The scoping call covers your environment overview, constraints, what is testable now versus discovery-first, and indicative next steps. We confirm what can be tested safely, what should go to the lab first, and what a realistic scope looks like.
The safety conversation comes first; if your estate is not ready for a particular type of test, we will tell you what the right first step is, even if it is smaller than the scope you originally had in mind.
Explore all penetration testing services to see the full range of what we offer.