IoT Security App Development

Companies building IoT security platforms face an adversarial environment that standard web application security practices were not designed for. IoT devices run on constrained hardware with limited compute for cryptographic operations. Firmware updates must be delivered over untrusted networks without bricking production devices. Device fleets in the millions cannot be individually managed; security must be enforced at fleet level through automated policy. And the regulatory environment is hardening: the UK Product Security and Telecommunications Infrastructure (PSTI) Act 2022 mandates minimum security baselines for consumer IoT, the EU Cyber Resilience Act imposes mandatory vulnerability disclosure and update obligations, and IEC 62443 governs industrial IoT (IIoT) security in critical infrastructure sectors. Scrums.com builds the engineering infrastructure for IoT security platforms: device identity and certificate lifecycle management, zero-trust network segmentation, secure OTA firmware update pipelines, anomaly detection and threat intelligence, and compliance reporting, engineered for the constraints and scale of production device fleets.

Our dedicated engineering teams have built IoT security infrastructure for smart home device manufacturers, industrial automation vendors, connected medical device platforms, and enterprise IoT fleet management products. We deliver dedicated squads (senior engineers, tech leads, QA) integrated into your sprint cycle, typically deploying first production infrastructure within 21 days of kickoff.

Core Architecture of an IoT Security Platform

IoT security platforms must solve problems that have no equivalent in conventional web application security: constrained device hardware, physically inaccessible deployment environments, and fleet-scale policy enforcement. Four subsystems form the core of a production IoT security platform.

Device Identity and Certificate Lifecycle Management

Every IoT device must have a unique, unforgeable identity before it can be trusted on the network. The device identity service issues X.509 certificates from a multi-tier PKI (root CA air-gapped, intermediate CA online) at manufacturing time, storing the private key in the device's hardware security module (TPM 2.0, Microchip ATECC608, or ARM TrustZone). Certificate provisioning integrates with the manufacturing line via EST (RFC 7030) or SCEP. Certificate rotation is automated: devices poll the renewal endpoint approaching expiry, receive a new certificate via mutual TLS, and the old certificate is revoked in OCSP/CRL. Device attestation (verifying the device is running unmodified firmware from a known-good state) uses TPM measured boot extending PCR values, with remote attestation providing cryptographic proof of device state.

Zero-Trust Network Segmentation and Policy Enforcement

IoT devices on a flat network are a lateral movement risk: a compromised smart sensor can reach core infrastructure if network access is unrestricted. Zero-trust architecture assigns each device a network identity (certificate-bound), and network policy permits only the specific protocol/port/destination pairs required for the device's function. Microsegmentation is enforced at the SDN layer (Cisco SD-Access, VMware NSX, or iptables/nftables at gateway) or via a service mesh sidecar for cloud-connected devices. Device behaviour is baselined at onboarding: normal outbound destinations, protocols, and data volumes are recorded. Deviations from baseline trigger policy-based responses (quarantine, bandwidth throttling, alert) configurable per device class and severity.

Secure OTA Firmware Update Pipeline

Over-the-air updates are the primary mechanism for patching vulnerabilities in deployed device fleets. A botched update that bricks devices at scale is a critical incident. The OTA pipeline requires: update package signing (code signing key in HSM, signature verified on device before installation), differential updates (binary delta to minimise bandwidth on constrained networks: bsdiff, xdelta, or Zephyr MCUboot), staged rollout (canary group, progressive rollout with automatic halt on failure rate threshold), rollback capability (A/B partition scheme with bootloader rollback on failed boot sequence), and delivery protocol appropriate to device constraints (MQTT, CoAP, or HTTP with TLS 1.3 minimum). Update delivery status is tracked per device with timeout and retry logic, providing fleet-wide patch compliance visibility.

Anomaly Detection and Threat Intelligence

Rule-based detection (port scan signatures, known malware C2 patterns, Mirai/Gafgyt botnet signatures) provides immediate coverage against known threats. ML-based anomaly detection builds behavioural baselines per device class (expected telemetry frequency, packet size distribution, outbound destinations) and flags statistical deviations for analyst review. Threat intelligence feeds (NIST NVD CVE feeds, ICS-CERT advisories, vendor security bulletins) are ingested and correlated against the device inventory to surface devices running vulnerable firmware versions before exploitation. Incident response automation quarantines devices matching threat signatures, generates evidence packages (network logs, device telemetry, certificate chain), and opens tickets in the SIEM/SOAR platform.

Compliance Architecture: PSTI Act, EU Cyber Resilience Act, and IEC 62443

IoT security regulation has moved from voluntary frameworks to mandatory baselines with enforcement consequences. The three frameworks below cover consumer IoT, EU market access, and industrial control system security.

UK PSTI Act 2022 and EU Cyber Resilience Act

The UK PSTI Act (effective April 2024) mandates three baseline requirements for consumer IoT products placed on the UK market: unique default passwords per device (no universal default credentials), a published vulnerability disclosure policy, and a published minimum support period for security updates. Non-compliance triggers Trading Standards enforcement, including product recalls and market withdrawal. The EU Cyber Resilience Act (CRA, applying from 2027) extends obligations to all products with digital elements sold in the EU: mandatory vulnerability disclosure to ENISA within 72 hours of discovery, security updates for the product's expected lifetime, and CE marking requires documented security assessment. The IoT security platform must generate compliance evidence for both frameworks: credential uniqueness attestation at manufacturing, vulnerability disclosure workflow logs, and update delivery evidence per device serial number.

IEC 62443 for Industrial IoT and Critical Infrastructure

IEC 62443 is the international standard for industrial automation and control system (IACS) security, referenced in critical infrastructure regulations globally (NERC CIP for energy, NIS2 Directive for EU critical sectors). The standard defines Security Levels (SL 1-4) and requires: zone and conduit modelling (identifying trust boundaries within the ICS network), security requirements per zone based on the assessed Security Level, and assurance testing against the defined requirements. For software components at SL 2 and above, IEC 62443-4-2 specifies device-level requirements: unique device identity, authenticated software updates, audit logging, and network access controls. The IoT security platform must demonstrate SL compliance for the zones it protects, with documented threat modelling and security test evidence for certification.

ETSI EN 303 645 and Matter Protocol Security

ETSI EN 303 645 (Cyber Security for Consumer IoT) provides 13 baseline provisions that underpin the PSTI Act and similar national implementations across Europe and beyond. The Matter protocol (formerly Project CHIP) provides a standardised commissioning and device attestation model for smart home devices, using Device Attestation Certificates (DAC) rooted in the Connectivity Standards Alliance (CSA) Product Attestation Authority (PAA). Matter commissioning requires the device to prove its DAC chain against the Distributed Compliance Ledger (DCL), which also publishes certificate revocations. Building Matter-compliant IoT products requires integration with the CSA certification process and HSM-based DAC provisioning at manufacturing time.

Scrums.com's mobile app development teams build IoT security infrastructure covering device identity, OTA update pipelines, anomaly detection, and PSTI Act, EU Cyber Resilience Act, and IEC 62443 compliance.

Technology Stack for IoT Security Platforms

IoT security platforms span firmware, hardware security modules, cloud services, and network infrastructure. Technology choices must account for device constraints (limited RAM, no persistent storage for large certificate chains, CPU cycles consumed by cryptographic operations) as well as the fleet management scale of millions of simultaneous connections.

Device Connectivity and Message Broker

AWS IoT Core, Azure IoT Hub, or Google Cloud IoT for managed MQTT/AMQP/HTTPS device connectivity at scale, with built-in certificate-based mutual TLS authentication. Eclipse Mosquitto or HiveMQ for on-premises MQTT broker deployments where cloud connectivity is restricted. Apache Kafka for high-throughput telemetry event ingestion from large device fleets into the analytics pipeline. DTLS 1.3 for UDP-based communication on constrained devices where TCP overhead is prohibitive.

Identity and PKI Infrastructure

HashiCorp Vault or AWS ACM Private CA for certificate authority management with automated rotation. EJBCA or Dogtag Certificate System for on-premises PKI deployments. EST server (RFC 7030) for automated certificate issuance at manufacturing line throughput. OCSP responder and CRL distribution point for certificate revocation. AWS CloudHSM, Thales Luna Network HSM, or Microchip ATECC608 for private key protection at both server and device level.

OTA Update Infrastructure

Eclipse hawkBit or Mender.io for OTA campaign orchestration, rollout scheduling, and per-device status tracking. MCUboot for A/B partition bootloader on Zephyr RTOS and Linux-based devices. AWS IoT Jobs or Azure Device Update for managed cloud OTA delivery. xdelta3 or bsdiff for binary delta generation to minimise bandwidth on LPWAN networks (NB-IoT, LTE-M). HSM-protected code signing keys ensure update package authenticity before installation.

Anomaly Detection and Security Analytics

Elastic Security (formerly SIEM) or Splunk for log aggregation, rule-based detection, and alert management. Apache Flink or Spark Streaming for real-time ML inference on device telemetry streams. TensorFlow or PyTorch for anomaly detection model training; ONNX runtime for inference deployment to cloud endpoints. Suricata IDS for network-layer signature-based detection at the IoT gateway. TheHive and Cortex for incident response orchestration and automated enrichment.

Cloud and Edge Architecture

AWS Greengrass v2 or Azure IoT Edge for local compute on constrained gateways, running security policy enforcement, local anomaly detection, and OTA update staging without requiring constant cloud connectivity. Kubernetes on cloud for platform services; k3s or KubeEdge for edge node orchestration. InfluxDB or TimescaleDB for time-series device telemetry storage with automated downsampling. Grafana for fleet health and security posture dashboards.

Why Engineering Teams Choose Scrums.com for IoT Security Development

IoT security is one of the hardest engineering domains: you must design for devices that are physically inaccessible after deployment, have limited compute for cryptographic operations, may run for 10+ years without hardware replacement, and form fleets too large for manual intervention. Across our client engagements, the most expensive technical decisions we encounter are those made without accounting for device constraints: PKI systems that work on a development bench but cannot replicate at manufacturing line throughput, or OTA pipelines that assume broadband connectivity for devices that communicate over NB-IoT at 50 kbps.

Device-Constrained Engineering Experience

Our engineers have designed PKI provisioning pipelines that operate at manufacturing line speed (hundreds of certificates per minute), OTA update systems that deliver differential patches over LPWAN networks, and anomaly detection models calibrated to device-class behavioural baselines rather than generic thresholds. We do not apply web application security patterns to IoT problems: the attack surface, hardware constraints, and failure modes are fundamentally different.

Compliance-First Architecture

PSTI Act compliance, IEC 62443 Security Level assessment, and ETSI EN 303 645 provision coverage are built into the platform architecture from day one rather than added as documentation after the fact. The platform generates compliance evidence as a byproduct of normal operation: vulnerability disclosure workflow logs, update delivery records per serial number, and device credential uniqueness attestation certificates. This means your compliance evidence exists before a Trading Standards review or certification audit, not after.

Dedicated Squads, Not Rotating Contractors

Each engagement is staffed with a fixed squad (senior engineer, mid-level engineer, tech lead, and QA) who stay with your project for its duration. IoT security systems require deep context: PKI hierarchy decisions, device attestation model choices, and OTA rollout strategies cannot be reconstructed from documentation. Typical first production deployment is within 21 days of kickoff.

Discuss your IoT security platform requirements at Scrums.com/start-a-project, or explore how we staff dedicated engineering squads for security-critical products.

Frequently Asked Questions

How does device certificate provisioning work at manufacturing line speed?

Certificate issuance at manufacturing line speed (typically 100 to 500 devices per minute per line) requires a locally deployed EST server or SCEP endpoint with direct access to the intermediate CA. The manufacturing test fixture calls the provisioning API, receives the signed certificate and chain, injects it into the device's secure element or TPM, and records the serial number to certificate binding in the device registry. The root CA remains air-gapped; only the intermediate CA is accessible to the manufacturing network. Certificate issuance throughput is bounded by the HSM's signing operations per second: typically 1,000 to 10,000 RSA-2048 signatures per second depending on hardware, well above manufacturing line requirements.

How do you prevent an OTA firmware update from bricking a deployed device fleet?

A/B partition architecture is the primary protection: the bootloader maintains two firmware partitions and boots from the partition flagged as confirmed. A new update installs to the inactive partition; the device reboots into the new firmware, runs a health check sequence, and if successful marks the new partition as confirmed. If the health check fails within a configurable timeout, the bootloader rolls back to the previous partition automatically. Progressive rollout (1% of fleet, then 5%, then 20%, then 100%) with automated halt on failure rate threshold (typically 2-5% of the canary group failing their health check) catches update problems before they reach full fleet deployment.

What is the difference between IEC 62443 Security Levels 1, 2, 3, and 4?

IEC 62443 Security Levels describe the threat actor capability that the system is designed to resist. SL 1 protects against casual or unintentional violations: basic access controls and network segmentation. SL 2 protects against intentional violation using simple means and low resources: authentication, encrypted communications, and audit logging. SL 3 protects against intentional violation using sophisticated means and moderate resources: advanced authentication, integrity checking, and detailed audit capability. SL 4 protects against state-sponsored attackers using sophisticated means and extended resources: hardware security modules, formal security analysis, and deep defence in depth. Most industrial IoT deployments target SL 2 as a minimum, with safety-critical infrastructure targeting SL 3.

How does Matter protocol device attestation work?

Matter device attestation proves that a device was manufactured by a CSA-certified vendor and has not been cloned. At commissioning, the commissioner (a smartphone app or hub) sends an attestation challenge to the device. The device signs the challenge using its Device Attestation Key (DAK), which is stored in a secure element. The commissioner verifies the signature against the Device Attestation Certificate (DAC), traces the certificate chain to the Product Attestation Intermediate (PAI) and then to the Product Attestation Authority (PAA), and checks the PAA against the CSA Distributed Compliance Ledger to confirm it has not been revoked. The entire chain must be valid for commissioning to succeed.

How do you design anomaly detection that avoids alert fatigue on a large device fleet?

Alert fatigue comes from uniform thresholds applied to heterogeneous device behaviour. The solution is per-device-class baseline modelling: a temperature sensor in a data centre has very different expected telemetry patterns from a consumer smart lock. Baselines are established during a defined onboarding period (typically 7 to 14 days) and updated with exponential smoothing as behaviour evolves. Alert scoring combines anomaly magnitude with device criticality: a deviation on a medical device triggers immediate escalation; the same deviation on a low-risk consumer device generates a logged event for batch review. Suppression rules prevent storm conditions (a network outage that causes 10,000 devices to go offline simultaneously) from generating 10,000 individual alerts.