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. This includes 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, 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 stopped. This is why ICS testing is a distinct discipline, not an 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.
Tier 1: Passive
SPAN-port monitoring and passive protocol capture to map assets and zones using the Purdue reference model. Zero operational contact with live systems. Identifies unsafe assets and shapes the engagement plan.
Tier 2: Lab / Bench Replication
Firmware and device testing off-network using testbed emulation for fragile or unpatchable systems. Transparent trade-off: more time, zero risk to live operations. Firmware analysis and exploit validation happen here.
Tier 3: Controlled Active
Targeted checks run in maintenance windows with named safety contacts and per-action approval. Explicit stop conditions agreed before testing. No exploit execution on live process networks; proof obtained in the lab.
Protocol-Aware Findings
Testing validates the hardening pipeline (inventory → segment → harden → test); it 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
Firmware Analysis
Extraction from flash or update packages, static analysis, hardcoded credential identification, and review of embedded services. Often reveals backdoor accounts and debug interfaces.
Update-Mechanism Review
Testing of signing, rollback protection, and plaintext channels. A device that accepts unsigned updates can be permanently compromised.
Radio / Wireless Interfaces
Assessment of BLE, Wi-Fi, and Zigbee for pairing weaknesses, replay attacks, and range assumptions. Many devices pair once and never re-authenticate.
Hardware Interfaces
Investigation of debug ports (UART, JTAG, SWD) and flash extraction. Normal and safe in device testing; enabled debug ports facilitate firmware cloning.
Companion App & Cloud API
Review of authentication, token handling, and API authorisation. The device's real risk often sits in its cloud management plane.
The Destructive-Testing Trade-off
Dev samples can be broken — desoldered, dumped, fault-injected. Production devices follow the same passive-first discipline as OT.
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; IoT testing for any smart sensors on the line. The control network demands passive-first discipline; smart sensors can often be tested destructively off-line.
Energy and Utilities
OT assessment for critical infrastructure; IoT testing for smart meters and remote monitoring units. A failed meter reading is tolerable, a failed substation control is not.
Building Management Systems
OT assessment for HVAC and access-control networks; IoT testing for smart controllers. BMS estates often mix IT and OT, making clear zone boundaries essential.
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. 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
Weak API authentication and compromised device-management backends. 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 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) | 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. Provides assurance evidence 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 mapped to known adversary techniques, making risk tangible and prioritised against real-world attack patterns. |
| ETSI EN 303 645 / UK PSTI | For connected-product makers, testing validates the security requirements for consumer IoT devices, including the absence of default passwords. |
| Insurer & Board Assurance | Non-regulatory driver; testing provides current, documented risk posture for renewals and investment decisions. |
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 Purdue levels
- Protocol list
- Remote-access inventory (vendor links)
- Maintenance windows
- Named safety & operations contacts
- Agreed stop conditions & fail-safe states
- Site sign-off process for rules of engagement
Honest-advisor note: If no inventory exists, passive discovery is a legitimate first engagement. A discovery-first engagement builds the asset map and protocol inventory a future full test will need, with essentially no operational risk.
When not to choose full pentesting yet
- Unmapped estate: Choose passive discovery first. Testing blind risks missing critical assets.
- Fragile unpatchable systems with no lab: Choose lab replication first.
- No site sign-off: Wait until operations and safety teams have approved the rules of engagement.
Scheduling is production-driven. Active testing aligns with maintenance windows; passive monitoring can run anytime. A typical engagement runs four to eight weeks from scoping to report delivery.
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.
Executive Summary
For operations leadership — what was found, what it means for the process, and what to do first.
Technical Detail
With reproduction steps so your engineers can verify each finding and re-test fixes.
MITRE ATT&CK Mapping
Where useful — showing which adversary techniques each finding corresponds to.
Remediation Roadmap
Distinguishing configuration fixes from design-limitation mitigations (segmentation, compensating controls).
Delivery stages: Scoping call → rules of engagement → passive phase → lab/active phase per scope → reporting and debrief.
OPTIONAL RETESTWho Performs the Testing — and How
to Compare ICS/OT Providers
ICS and IoT testing is a safety discipline first: the differentiator is whether the team has stood next to a plant engineer, not how many IT networks it has scanned. We are a London-based team delivering nationwide across the UK.
Questions to ask any provider
- 1. What is your ICS-specific methodology, and what are your stop conditions?
- 2. What is your safety case, and how does per-action approval work?
- 3. Which protocols do you cover, and how do you interpret findings per protocol?
- 4. How do you rank findings: by safety or operational impact, or by raw CVSS?
- 5. Do you have lab capability for fragile or unpatchable systems?
- 6. What is your sector experience in manufacturing, utilities, or BMS?
- 7. Can you share a redacted report structure before we buy?
Common mistakes when buying
- ✕ Treating OT like IT and running aggressive scans
- ✕ Assuming scanning tools are safe by default
- ✕ Ignoring vendor remote-access links as a test target
- ✕ Conflating compliance certification with security testing
- ✕ Scheduling active tests without site sign-off
Practitioner caveats we work with
Our testing is performed by practitioners with ICS-relevant experience. We work with the following caveats to ensure safety and accuracy:
- Legacy systems → Compensating controls are validated, not assumed. If a system cannot be patched, the test verifies that the controls around it actually hold.
- Fragile devices → Lab replication is used. If there is any doubt about survival, it goes to the lab first.
- Design limitations → Distinguished from misconfigurations. The report tells you which findings are configuration changes versus architectural mitigations.
- Production-driven timelines → Active testing waits for windows. The schedule bends around your operational calendar.
[Credential slots to confirm: GICSP, GRID, GCIP, IEC 62443 certificates, CREST, OSCP.]
Frequently Asked Questions
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. The defining characteristic is that these systems act on the physical world, which is why 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 — and it does so 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 "C" because a process outage can have safety consequences, and this is why testing methodology prioritises operational continuity. 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 often 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 — for example, RBAC on the network while physical access to controllers is completely open, or vendor accounts that bypass every model.
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 categories of tools: passive discovery and protocol analysis tools, firmware extraction and analysis tools, controlled protocol-aware assessment tools, and 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 and emulation tools for Tier 2, and carefully controlled protocol-aware tools for Tier 3 active checks.
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. 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.
Explore all penetration testing services to see the full range of what we offer.