NACSA licence in progress
Hardware · Firmware · Radio · Cloud

IoT Penetration Testing Malaysia

Full device-to-cloud kill chain assessment for Malaysian manufacturers, smart building operators, and industrial OT environments. We test hardware interfaces, firmware binaries, BLE/Zigbee/LoRaWAN radio protocols, and cloud APIs — not just the network perimeter.

The Challenge

Why IoT security is not a standard pentest

A conventional web or network pentest operates on documented, standardised platforms — HTTP, TCP/IP, Active Directory. IoT devices introduce layers that most security firms are not equipped to test: embedded firmware compiled for ARM or MIPS processors, proprietary radio protocols operating at 2.4 GHz or sub-GHz frequencies, and debug interfaces physically exposed on the PCB that bypass software authentication entirely.

Malaysian manufacturers shipping connected products to the EU or UK face regulatory pressure under the EU Cyber Resilience Act and the UK PSTI Act. Building owners operating smart HVAC, access control, and energy management systems face a different risk: a single compromised gateway device can bridge from an isolated OT network into corporate IT infrastructure, enabling lateral movement that no network firewall anticipated.

nCrypt's IoT penetration testing methodology follows a four-layer model — hardware, firmware, radio, and cloud — ensuring every component of the device-to-cloud kill chain is evaluated, not just the parts visible from the network perimeter.

Methodology

Four-layer IoT assessment methodology

Each layer of the device-to-cloud architecture is tested independently and as part of the full attack chain. A finding at one layer — a hardcoded credential in firmware, for example — is traced through to its impact at the cloud layer.

Layer 1

Hardware & Debug Interfaces

Physical access to the device is the attacker's first opportunity. We examine exposed debug ports — JTAG, UART, SPI, I2C — for unlocked access that bypasses authentication entirely. We probe test pads, identify chip markings, and attempt to dump memory directly from flash chips using clip-on readers when firmware extraction through software channels is blocked. Secure boot chain verification confirms whether a device will refuse tampered firmware or silently execute it.

  • JTAG / UART / SPI debug port probing
  • Flash memory chip-off extraction
  • Secure boot bypass attempts
  • EEPROM and NVRAM data recovery
  • Hardware fault-injection scoping
Layer 2

Firmware & Embedded Software

Firmware is the operating system of an IoT device — and most of it has never been audited. We extract firmware via software update mechanisms, debug ports, or direct chip reads, then unpack and analyse it statically. Binwalk unpacking reveals hidden filesystem structures, hardcoded credentials, private keys, and certificate chains baked into the image. We identify the OS, kernel version, and all third-party libraries to flag known CVEs. Dynamic analysis under QEMU emulation confirms exploitability where full hardware isn't required.

  • Binwalk filesystem extraction and analysis
  • Hardcoded credential and API key hunting
  • Third-party library CVE mapping
  • Encryption key extraction from firmware images
  • QEMU-based dynamic emulation
  • Update mechanism integrity verification
Layer 3

Radio & Protocol Testing

IoT devices communicate using a range of wireless protocols — each with distinct attack surfaces. BLE devices are probed for unauthenticated GATT service enumeration and characteristic write access. Zigbee networks are tested for unencrypted traffic, network key extraction, and device spoofing. LoRaWAN deployments used in smart metering and industrial sensors are reviewed for DevEUI/AppKey exposure, replay attacks, and gateway authentication. Wi-Fi-connected devices are additionally subject to WPA2/WPA3 and captive portal testing from the wireless assessment playbook.

  • BLE GATT service enumeration and write testing
  • Zigbee network key extraction
  • LoRaWAN DevEUI/AppKey exposure and replay
  • MQTT broker authentication and authorisation review
  • CoAP endpoint fuzzing
  • Protocol downgrade and replay attacks
Layer 4

Cloud Backend & Companion API

Almost every IoT device talks to a cloud backend — and the cloud is where attacker impact scales. We test the companion mobile application and its API endpoints using OWASP-aligned methodology: authentication bypass, broken object-level authorisation (BOLA), insecure direct object references that expose other users' device data, and weak or missing API rate limiting that enables device enumeration. Cloud infrastructure hosting the device management platform is reviewed for publicly exposed management interfaces, overly permissive IAM policies, and misconfigured storage that may expose telemetry data at scale.

  • API authentication and authorisation testing
  • BOLA / IDOR across device-owner relationships
  • Device telemetry data exposure via cloud storage
  • IoT platform management console access control
  • Over-the-air (OTA) update endpoint authentication
  • Cloud-side rate limiting and enumeration controls
Engagement Scoping

Lab assessment or on-site: choosing the right approach

The right delivery model depends on whether you are validating a product before shipment or testing devices already deployed in your environment.

Lab Assessment

You ship us one or more physical devices. We conduct all hardware, firmware, and radio testing in our facilities and test cloud/API endpoints remotely. Ideal for product manufacturers validating a device before launch or at a pre-shipment milestone.

Best suited for:

  • Product manufacturers
  • Pre-launch security validation
  • Single device model
  • Regulatory compliance evidence

On-Site Assessment

Our consultants attend your facility to test devices in their deployed environment: factory floor, server room, retail fit-out, or building management system. On-site testing captures network-layer attack paths that only exist when the device is connected to your production infrastructure.

Best suited for:

  • Smart building owners
  • Industrial manufacturers with OT networks
  • Multi-device estates
  • Post-deployment validation
Deliverables

What your IoT assessment report contains

Every nCrypt IoT assessment produces a structured written report covering all four layers. Findings are mapped to the OWASP IoT Top 10 and, where relevant, ETSI EN 303 645 provisions for manufacturers requiring regulatory evidence.

01Executive summary — board-readable, one page
02Device-to-cloud kill-chain narrative with annotated screenshots
03Layer-by-layer findings register (Critical / High / Medium / Low / Informational)
04Firmware binary analysis appendix (extracted files, identified credentials, CVE mapping)
05Radio capture evidence with annotated protocol decodes
06Cloud API findings with HTTP request/response evidence
07Remediation guidance mapped to OWASP IoT Top 10 and ETSI EN 303 645
08Retesting scope — which findings to retest after patching
FAQ

Frequently asked questions

Common questions about IoT penetration testing for Malaysian manufacturers and building operators.

What types of IoT devices do you test in Malaysia?

We test a wide range of connected devices: industrial controllers and PLCs used on factory floors, building management system (BMS) gateways and smart HVAC controllers, medical devices (subject to additional scoping for patient-safety constraints), retail POS terminals with embedded OS, asset-tracking tags and smart meter gateways, and consumer-grade devices such as IP cameras and smart locks. If your device runs embedded firmware and communicates over any wireless or wired protocol, we can scope a test against it.

Do we need to send you a physical device, or can the test be done remotely?

Hardware and firmware layers require a physical device. Chip-level flash extraction, JTAG probing, and radio testing cannot be done remotely. Cloud backend and API testing can be conducted remotely once we have test credentials and API documentation. For most engagements we combine lab-based hardware/firmware testing with remote API testing. Where devices are embedded in immovable infrastructure (building BMS, factory equipment), we attend on-site with specialist hardware.

How does IoT penetration testing differ from a standard web or network pentest?

Standard web and network pentests operate on well-documented, standardised platforms (HTTP, TCP/IP, Active Directory). IoT testing requires specialist hardware tools — logic analysers, JTAG adapters, SDR radios, and clip-on flash readers — and the ability to analyse compiled firmware binaries, often for custom or modified RTOS environments. The attack chain also spans more layers: from physical hardware through embedded software, proprietary radio protocols, and up to cloud APIs. This breadth requires a different toolset and skill set from a web or network-only practitioner.

Is IoT security testing relevant for Malaysian manufacturers exporting to the EU or UK?

Yes — this is increasingly a commercial requirement. The EU Cyber Resilience Act (CRA) and UK PSTI Act both impose security requirements on connected products. The EU CRA applies to products sold in the EU market from 2027; it requires vulnerability handling processes and security-by-default design. ETSI EN 303 645 is the baseline security standard referenced by both regimes. nCrypt's IoT assessment maps findings to ETSI EN 303 645 provisions, providing evidence useful for manufacturers preparing compliance documentation for EU/UK market access.

Can IoT penetration testing disrupt production devices or networks?

It can, if not scoped carefully — which is why we agree a testing plan before any activity begins. For production devices, we use test units isolated from the live network wherever possible. Radio testing (BLE, Zigbee, LoRaWAN) is conducted within agreed frequency ranges and power limits. Any fuzzing or exploit attempts that could crash a device are conducted on test units, not production hardware. All testing proceeds under a signed scope document with an agreed abort procedure. We have not caused production outages on any engagement to date.

What is the OWASP IoT Top 10 and do you test against it?

The OWASP IoT Top 10 is a reference list of the most significant security risks affecting IoT products, covering areas including weak/guessable/hardcoded credentials, insecure network services, lack of a secure update mechanism, use of insecure or outdated components, and insufficient physical security. nCrypt's IoT assessment methodology covers all ten OWASP IoT Top 10 categories and maps each finding to the relevant category in the deliverable report. We also map to ETSI EN 303 645 provisions where relevant for compliance evidence.

Talk to a senior security consultant

Share your scope. We'll come back with a fixed-fee proposal.

Get a Free Quote

Share your scope. We'll come back with a fixed-fee proposal.

Reply within 1 business day. No spam, ever.

Secure your IoT ecosystem before it becomes the weakest link

From device firmware to cloud API, nCrypt's IoT penetration testing maps the full attack chain so you can remediate what matters most.

Not sure what you need?

Tell us what needs testing and we come back with a fixed fee within 48 hours — no hourly estimates.