What it is and why it matters

A smart speaker hears a shout. A doorbell camera sees who came to the gate. A fitness band records a heartbeat that stops. A smart lock notes which code opened the door at two in the morning. None of these devices was built to be evidence and none stores data the way a computer does, yet they now appear in burglary, domestic violence, arson, insurance fraud and factory incident cases.

What sets IoT forensics apart is that the evidence is split three ways. The device holds a little, usually in flash memory on a board with no port. The companion app on the owner's phone holds a copy of events, settings and login tokens. The maker's cloud holds the full history, reachable through the account or by legal request to a company that may sit in another country. An examiner who looks only at the device will usually find less than the case needs.

The network is a fourth source. Every connected device talks, over Wi-Fi, Bluetooth Low Energy, Zigbee, Z-Wave or Thread, and most of that traffic passes through a hub or the home router. A capture shows which devices were active and when, even where the content is encrypted. This is why the discipline draws on mobile, network and hardware forensics together rather than being a field of its own.

Types of digital evidence

  • Event Logs

    Timestamped records of motion detected, door opened, light switched, voice command heard or alarm armed. They live in the app database, the hub and the cloud, rarely in full on the device.

  • Sensor and Health Readings

    Heart rate, step counts, sleep periods and temperature from wearables and home sensors, which can place a person in a state or a place at a time.

  • Audio and Video Clips

    Recordings from cameras, doorbells and speakers, stored locally on a card, on a hub or in the cloud for a retention period set by the plan.

  • Companion App Databases

    SQLite stores and preference files on the phone with device lists, event history, account identity, Wi-Fi credentials and tokens.

  • Device Identities

    MAC addresses, serial numbers, device IDs and the firmware version that tie a physical device to an account and to traffic on the network.

  • Router and Hub Records

    DHCP leases, connected device lists and connection logs that show what was on the network and when it joined.

  • Firmware and Configuration

    The software image and settings on the device, which reveal the model, the servers it talks to and whether it was modified.

Devices and data sources

  • Smart speakers and displays with voice assistants
  • Video doorbells, Wi-Fi cameras and baby monitors
  • Smartwatches, fitness bands and medical devices
  • Smart locks, alarm panels, door and window sensors
  • Smart TVs, streaming sticks and game consoles
  • Smart plugs, bulbs, thermostats and connected appliances
  • Home hubs, routers and mesh Wi-Fi systems
  • Industrial controllers and building management systems
  • The companion apps on phones and the cloud accounts behind them

How an examination runs

The order matters. Each step protects the one after it.

  1. 01
    Authority and Scope

    Settle whose devices and whose accounts are covered. A home has several occupants and the account holder is not always the person under investigation.

  2. 02
    Map the Ecosystem

    List every device, hub, app and account in the premises. Photograph each device in place, note whether it is powered and record model and serial numbers.

  3. 03
    Decide on Live Capture

    Many devices lose state on power loss. Capture traffic at the router before anything is unplugged, and record the state of hubs and apps while they are still connected.

  4. 04
    Preserve the Cloud

    Send a preservation request to the maker early, since clip retention can be days. Where the account holder consents, export the history through the account and document how.

  5. 05
    Extract the Phone

    Acquire the companion app's databases with a mobile forensic extraction. This is often the richest single source and the quickest to obtain.

  6. 06
    Acquire the Device

    Use a USB, debug or export interface where the maker provides one. Otherwise consider board-level access under written authority, knowing that many devices hold little once the cloud and app are in hand.

  7. 07
    Correlate

    Align the sources on one timeline. Device clocks drift, apps store local time and the cloud stores UTC. Resolve that before drawing conclusions.

  8. 08
    Report by Source

    Say what the device, the app, the cloud and the network each showed and where the gaps are.

Tools used in this discipline

Independent profiles: what each tool does, where it stops and what you need to know before using it.

Terminology

Companion App
The phone app that sets up and controls a device. Its local database is usually the easiest copy of the device's history to obtain.
Hub
A bridge that links low-power devices on Zigbee, Z-Wave or Thread to the home network and the internet. It often keeps logs the devices do not.
Zigbee and Z-Wave
Short-range mesh radio protocols used by bulbs, sensors and locks. Their traffic does not pass the Wi-Fi router, so it needs a hub or a dedicated sniffer to capture.
Bluetooth Low Energy
The link most wearables use to a phone. Data lives in the phone app and the vendor cloud more than on the wearable.
MQTT
A lightweight publish and subscribe protocol many devices use to talk to their cloud. Seen in a capture, its topic names can identify devices and actions.
Firmware
The software burnt into the device. Its version decides what the device logs and whether a known method exists to read it.
Debug Header
Unpopulated pins on a circuit board, often UART or JTAG, through which a laboratory can read the device under authority.
Cloud-First Device
A device that uploads nearly everything and keeps almost nothing. The examiner's effort goes into the account and the legal request, not the hardware.

Challenges and limits

What makes it hard

  • Thousands of makers, protocols and storage designs, with no common interface for acquisition
  • Short cloud retention means footage or events can be gone before a request is approved
  • Makers outside India, so cloud data depends on mutual legal assistance or the provider's own process
  • Encrypted traffic and storage limit the network capture to metadata and the device to little
  • Device clocks are unreliable and several time bases must be reconciled on every case
  • Shared households make consent and ownership of data unclear
  • Tool support is patchy, so much of the decoding is done by hand from the app's database

Keeping the evidence intact

  • Capture the network before disconnecting anything and record the capture point and time
  • Photograph devices in place and record their power state before they are moved
  • Hash every extraction, export and capture file at the time it is made
  • Keep a log of every app screen viewed and every cloud export performed, with account, time and method
  • Note the time base of each source and the conversion applied in the timeline

Standards and legal considerations

  • ISO/IEC 27037:2012

    The identification, collection and preservation guidance that still applies when the evidence is a lock, a camera and a phone app rather than a hard drive.

    Read the guide
  • NIST SP 800-101 Rev. 1

    Guidelines on Mobile Device Forensics, which govern the companion app extraction that most IoT cases depend on.

    Read the guide
  • CERT-In Directions of April 2022

    Require service providers, intermediaries and organisations in India to keep system logs for 180 days and to report incidents, which affects what an Indian provider can be asked to produce.

    Read the guide
  • Digital Personal Data Protection Act, 2023

    Connected devices collect personal data continuously. The Act frames how that data may be processed and when lawful exceptions for investigation apply.

    Read the guide
  • ENISA Baseline Security Recommendations for IoT

    The European agency's 2017 baseline, useful for understanding how devices are meant to be built and where their logs and interfaces usually sit.

In practice

  • A Doorbell and a Break-In

    A house is burgled while the family is away. The doorbell camera's clips have expired from the cloud, but the companion app's database on the owner's phone still lists motion events with thumbnails at 1.40 am, and the router's lease table shows an unknown phone joined the Wi-Fi guest network that evening.

  • A Watch in a Death Inquiry

    A person is found dead at home and the time is disputed. The fitness band's data in the phone app shows heart rate readings stopping at a specific minute and step counts ceasing an hour earlier. The examiner reports the readings with the band's known sampling interval and the phone's time zone.

  • Which Code Opened the Lock

    In a domestic case a smart lock's app history shows a guest code used at a time the complainant says the respondent was barred. The examiner preserves the cloud history through the account holder, extracts the app database and reports both, noting that the log shows the code used, not the hand that entered it.

This page is educational material, not legal advice. Laws and standards change, commence on different dates and are interpreted differently across jurisdictions. Always read the official text linked on this page and take advice from a qualified professional for a real matter.

Questions people ask

Is the data on the device itself?

Usually only a small part. The phone app and the maker's cloud hold most of the history. The device is worth examining when the app and cloud are unavailable or when tampering is suspected.

Can a smart speaker's recordings be recovered?

Voice assistants keep recordings and transcripts in the account, subject to the user's settings and deletion. The speaker holds little locally. Access is through the account or a lawful request to the provider.

Does unplugging a device destroy evidence?

It can erase volatile state and stop the network from being captured. The usual advice is to capture traffic and record app state first, then disconnect in a documented order.

Why are network tools listed for an IoT case?

Because the traffic is often the only neutral record of which devices were active. Wireshark, Zeek and NetworkMiner read captures taken at the router, and the pattern of connections can confirm or contradict the app history.

More in Emerging and specialised

Go deeper with DFRTI

Free pages explain the ground. Structured courses, lab work and a mentor take you from knowing about it to doing it on a case.