IoT penetration testing in Dubai, UAE
Our IoT penetration testing covers the whole connected product: the firmware, the radio protocol, the companion application and the cloud platform it communicates with, as well as the network it sits on.
A connected device is four systems, and each one is tested
A connected product is firmware running on hardware, a radio protocol carrying its traffic, a mobile or web application controlling it, and a cloud platform holding its data. A compromise of any one of these can give access to the others.
Network testing examines how the device behaves on your network, which is useful but covers one layer. IoT testing also extracts the firmware from the chip, searches for hardcoded credentials, and checks whether the cloud API verifies the identity the device presents.
This requires physical access to sample devices and the tools to read their firmware.
IoT penetration testing services we deliver
A full engagement covers all four layers. Scope can be narrowed where a specific concern drives the work, and the report records any layer that was excluded.
Firmware extraction and analysis
Firmware is extracted from the device and examined for hardcoded credentials, keys, debug functionality and third-party components with known vulnerabilities.
Hardware interface testing
Debug ports, serial interfaces and storage are examined for access that remains enabled in shipped units.
Secure boot and update testing
Whether the device verifies the firmware it is asked to install, which decides whether an attacker can load their own firmware permanently.
Storage and cryptography review
What the device stores locally, whether it is encrypted, and whether the keys protecting it are unique to each unit.
Protocol security testing
Wi-Fi, Bluetooth, Zigbee, LoRa, MQTT and industrial protocols are examined for weak authentication and unencrypted traffic.
Traffic interception
Whether communications can be read or altered in transit, including whether certificate validation is performed as the documentation states.
Replay and injection testing
Whether a captured command can be replayed, or a crafted command accepted, which is a practical route to controlling a device remotely.
Network exposure assessment
What the device exposes on the network it sits on, and what it can reach from there if it is compromised.
Mobile application testing
The companion application is examined for insecure storage, weak authentication and embedded API keys.
Cloud platform testing
The backend is tested for authorisation between tenants, device identity handling and whether one customer can reach another customer's data.
API security testing
Object-level authorisation, rate limiting and data exposure across the interfaces between device, application and platform.
Identity and provisioning
Enrolment, authentication and decommissioning are checked, including whether a stolen unit remains trusted after it should have been revoked.
Supplier and third-party assessment
Devices from vendors are assessed before procurement, so that fixes can be required as a condition of the contract.
Continuous validation
Retesting as firmware versions change, because a new release can reintroduce or add vulnerabilities.
Remediation retesting
Verification that each fix closed the route it was meant to close, performed on the shipped firmware.
Compliance-scoped testing
Testing scoped to the control being examined where an obligation drives the work, with the report written for the assessor.
Common IoT testing findings
These four types of finding occur across device categories and manufacturers.
How an IoT engagement runs
The layers in scope and the physical units that may be taken apart are agreed, because some testing destroys hardware.
- Sample devices supplied for destructive work
- Permitted techniques and exclusions written down and signed before testing begins
- Clinical and industrial equipment scoped together with the engineers responsible for it
What the device is, what it runs and what it communicates with is mapped before any attack is attempted.
- Components and chipsets identified, because they determine the firmware extraction method
- Traffic observed in normal operation to establish the device's baseline behaviour
- Vendor documentation and published advisories reviewed for known issues
The firmware is extracted and examined, which is the stage that produces many of the significant findings.
- Hardcoded credentials, keys and certificates searched for first
- Third-party components checked against known vulnerabilities at the shipped version
- Update and secure boot mechanisms tested by attempting to install unsigned firmware
The radio traffic, the companion application and the cloud interfaces are tested as one connected system.
- Interception attempted in practice
- Replay and crafted commands sent to the device
- Tenant separation on the cloud platform tested with two accounts
Findings are rated on what an attacker could reach with them, with the reproduction steps recorded for each one.
- A chain across layers rated as the compromise it enables
- Evidence captured for each finding
- A separate version written for the manufacturer where the fix sits with them
Once fixes ship, the shipped firmware is tested again. A finding is closed when the path is shown to be closed.
- Testing performed on the release build
- Related routes retested, because a partial fix can leave the underlying weakness in place
- A closure statement suitable for an assessor or a customer
Connected device obligations in the UAE
Connected equipment falls under general security obligations and, in some sectors, under requirements written specifically for it.
UAE Information Assurance Standards
The IAS expects periodic technical testing with documented findings and evidence of remediation, and connected devices are in scope in the same way as other equipment on the network. Scope is agreed against the control set you report on.
ADHICS
Abu Dhabi healthcare entities carry obligations covering connected medical equipment, where a security fault has patient safety implications and testing has to be scoped with biomedical engineering.
Critical infrastructure requirements
Operators of essential services face additional requirements on industrial and connected equipment, including separation between operational and corporate networks.
UAE PDPL
Devices that collect personal data bring the PDPL into scope, covering what is collected, where it is stored and who can access it through the platform behind the device.
Why choose iConnect for IoT testing
Firmware and hardware included
Firmware extraction and hardware interface testing are included in the engagement, in addition to network-layer testing.
All four layers together
Device, radio, application and cloud are tested as one system, because a compromise can chain across them.
Sample units
Destructive testing runs on units supplied for the purpose, so that no equipment in service is put at risk by the test plan.
Tested before you buy
Assessment during procurement allows fixes to be required from the vendor before the contract is signed.
Retested on shipped firmware
Verification is performed against the release build, so that the fix is confirmed on the product as shipped.
Care with clinical and industrial equipment
Medical and plant equipment is scoped with the engineers responsible for it, and tested on bench units wherever possible.
Sectors we test connected devices for
The consequences of a compromised device differ by sector, and that determines how the test has to be scoped.
Healthcare
Connected medical devices under ADHICS, where a fault affects patient safety.
Manufacturing
Industrial controllers and sensors on plant networks that cannot be stopped.
Government
Smart city equipment, surveillance and building systems at scale.
Retail and E-commerce
Payment terminals, in-store sensors and connected logistics equipment.
Banking and Finance
ATMs, kiosks and branch equipment holding cardholder data.
Education
Campus building systems and connected teaching equipment.
What our clients say
“Whenever an issue arises, iConnect is there immediately: quick, efficient and proactive in keeping everything running without disruptions. iConnect has become a crucial part of our operations.”
Head of IT Infrastructure and Network SecurityDragon OilIoT penetration testing questions
Because the device is only one part of the product. A connected product consists of firmware, a radio protocol, a mobile application and a cloud platform, and a weakness in any one of them can compromise the whole. Standard network testing examines how the device behaves on your network. IoT testing also extracts the firmware, searches for hardcoded credentials, and checks whether the cloud API verifies the identity the device asserts.
This page describes testing: the devices are attacked and the report states what succeeded. The OT and IoT security service is the operational side, covering asset discovery, segmentation and monitoring for environments you already run. Manufacturers and integrators need the testing. Operators of connected equipment can use both, with the test results directing where the operational controls are needed.
Yes, and this makes up a large part of the service. A purchased device includes whatever the manufacturer shipped, which may include hardcoded credentials or an update mechanism without signature verification. Testing before procurement or before a wide rollout allows fixes to be required from the vendor during the contract. Testing after deployment identifies the compensating controls the deployment needs.
Some hardware testing is invasive, and firmware extraction can leave a unit unusable. Physical testing is therefore performed on sample devices you supply for the purpose. The scope, the permitted techniques and the units that may be destroyed are agreed in writing before testing starts.
Hardcoded credentials and keys. Debug interfaces left enabled in shipped units. Update mechanisms with no signature verification, which allow an attacker to install their own firmware. Unencrypted storage of sensitive data. Third-party software components with known vulnerabilities, checked at the version included in the shipped firmware.
Yes. Clinical equipment needs particular care, because it cannot be taken out of service without planning and a fault has patient safety implications. Testing runs on sample or bench units wherever possible, and any work that touches a live clinical environment is scoped together with your biomedical engineering team.
A single device, including firmware, radio, application and cloud, is scoped at two to four weeks. A product family with shared firmware takes less time per device. Hardware that resists firmware extraction extends the schedule, because extraction can take longer than the analysis that follows it.
Yes. The Information Assurance Standards expect technical testing with documented findings, and operators of essential services carry additional obligations covering connected equipment. ADHICS applies to connected medical devices in Abu Dhabi healthcare. The scope is mapped to the control being examined and the report is written in the form an assessor asks for.
Talk to our team about your requirement
We’re happy to answer any questions you may have and help you determine which of our services best fit your needs.
Our Value Proposition
- Tailored Solutions for Your Organization
- Unbiased Expertise
- Proven IT Competence
- Outcome-Driven Approach
- Proactive Problem-Solving
- Transparent Processes
What happens next?
We’ll arrange a call at your convenience.
We do a discovery and consulting meeting
We’ll prepare a detailed proposal tailored to your requirements.