How to Secure Your IoT Apps: Best Practices for Data Protection

What the 2026 Data Says About Connected Devices

The numbers below come from vendor telemetry and regulators. They measure different things, so read each one for what it says and no more.

Two cautions. Bitdefender counts observations, meaning matches between a device and a known vulnerability. One device can produce many, and the figure is not a count of successful attacks. Forescout's sample is described only as "millions of devices" in its Device Cloud, so treat its averages as a direction rather than a census.

Cheap, long-lived devices are the ones most likely to go unpatched, and your app will be paired with hardware like that.

The Seven Practices, in Build Order

1. Give every device its own credentials

A shared factory password is the oldest failure in IoT and still the first one a security review checks. The UK has made it law, and the EU is following.

Since 29 April 2024 the UK's product security regime requires that a default password be unique to each product or set by the user, and it bars passwords built from counters or guessable patterns (GOV.UK). The EU CRA's secure-by-default requirement applies from 11 December 2027.

What to build:

• Per-device identity at manufacture. A unique key pair or certificate injected during provisioning, never a fleet-wide secret in firmware.
• Forced credential setup on first pairing. The app should not let a user finish onboarding on a default.
• Mutual authentication. The device proves who it is to the cloud, and the cloud proves it to the device. Token-only schemes leave the device open to a spoofed server.
• Revocation. A lost or stolen device must be removable from the fleet from the admin console in minutes.

2. Encrypt data in transit and at rest

The CRA's Annex I asks products to protect the confidentiality of stored, transmitted or otherwise processed data, such as by encrypting relevant data at rest or in transit with "state of the art" mechanisms. That is the regulator's wording for what should already be your default.

• In transit: TLS 1.3 between app, gateway and cloud, and TLS or DTLS on the device link where the hardware can carry it. Use mutual TLS for device-to-cloud traffic. For Bluetooth Low Energy, use LE Secure Connections pairing and treat any "just works" mode as unauthenticated.
• At rest: encrypt local databases and caches on the phone and gateway, and keep keys in the platform keystore or a secure element rather than in application code.
• Segregate secrets from telemetry. A temperature reading and a door-lock command do not need the same protection level, and mixing them makes both harder to audit.

3. Harden the app and the cloud around the device

The device gets the attention, yet the mobile app and cloud API are where most of the personal data lives. The OWASP Mobile Application Security Verification Standard (MASVS) is the practical checklist for the app side.

• Store tokens in the iOS Keychain or Android Keystore, never in plain preferences or logs.
• Ship no API keys or device secrets inside the app binary. Anything in the binary can be extracted.
• Use short-lived access tokens with scoped permissions, so a stolen token opens one device for a short time and not the whole account.
• Apply object-level authorisation on every API call. A common cloud flaw (broken object-level authorisation, API1 in the OWASP API Security Top 10) is a valid user reading another user's device by changing an ID.
• Rate-limit and log authentication endpoints.

4. Make signed over-the-air updates a launch requirement

A device you cannot patch is a permanent liability. The CRA requires that vulnerabilities can be addressed through security updates, including automatic updates enabled by default where applicable, and a support period of at least five years unless the product is expected to be used for less time. The detail on how to build that pipeline is in our guide to IoT features that give a competitive edge. The security core is short:

• Cryptographically signed images, verified on the device before install.
• Staged rollout by cohort, with automatic rollback if a device fails to boot.
• A record of which device runs which build, so you can answer a customer's security questionnaire in an hour.
• A published end date for security support, shown at the point of sale. The CRA requires the end month and year to be specified at purchase.

5. Collect less data

Data you never collect cannot leak. The CRA's Annex I lists data minimisation as an essential requirement: process only data that is adequate, relevant and limited to what is necessary for the product's purpose.

• Decide per sensor field whether it is needed, and drop the rest at the edge.
• Aggregate or anonymise on the gateway before upload where the use case allows.
• Set retention limits and delete on schedule. A year of raw location history is a liability, not an asset.
• Keep personal data and device telemetry in separate stores with separate access rules.

Every field you stop collecting also shrinks what a leak can expose. For scale, IBM's $4.99 million average breach cost covers all industries, not IoT alone.

6. Shrink the attack surface

The CRA's Annex I asks that products be designed to limit attack surfaces, including external interfaces. In practice:

• Ship with Telnet, FTP and unused debug ports disabled, and lock debug interfaces (UART, JTAG) in production builds.
• Close every listening port the product does not need, and document the ones it does.
• Validate every input from the network, the app and the device, since attackers can reach every interface.
• Isolate the device from the customer's other systems. A smart plug should not be able to reach a file server on the same Wi-Fi.

This is the same ground that DDoS botnets cover. Cloudflare's 5 February 2026 report recorded a 31.4 Tbps peak from the Aisuru-Kimwolf botnet. The defence on your side is mundane: no default credentials, no exposed management ports, patched firmware.

7. Run a vulnerability process before you need one

Under CRA Article 14, since 11 September 2026, a manufacturer that learns of an actively exploited vulnerability owes the authorities an early warning within 24 hours. A process that exists only on the day of an incident will not meet that.

• Publish a security contact and a disclosure policy. The UK regime already requires a published point of contact and stated acknowledgement times.
• Keep a software bill of materials for firmware and app, so you can tell within hours whether a new library flaw affects you.
• Log security-relevant events on device and cloud, and keep a named owner for triage.
• Rehearse once. A tabletop exercise that fails on paper is cheap.

2027 Compliance Checklist

The CRA does not replace good engineering. It writes the checklist into law for products with digital elements sold in the EU.

The maximum fine for breaching the essential requirements is EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Regulation (EU) 2024/2847, Article 64). Penalties are set at national level, and the European Commission notes that micro and small enterprises are not fined for missing the 24-hour deadline. Harmonised standards and Commission guidance were still being finalised when this was written, so check for updates before treating any single standard as your route to compliance.

Products already on the market generally need to comply only if they undergo a substantial modification. A new app release that adds features to existing hardware can count as one, so ask your legal team before assuming a grandfathered product stays exempt.

A Quick Self-Audit

Score each line yes or no. Any "no" is the next sprint.

The Bottom Line

Security for an IoT app comes down to seven things you can check in a review: unique credentials, encryption, a hardened app and cloud, signed updates, less data, fewer open doors and a vulnerability process that works. The 2026 data shows where the exposure sits, in routers and cheap long-lived devices, and the CRA gives 2027 its deadline.

Start with the self-audit table. If more than three lines are a "no", that is where a short security review pays for itself. If you are planning a connected product or tightening an existing one, get in touch and we will walk through your architecture with you. You can also read how AI is changing IoT app development and why IoT is a growth opportunity for businesses in India.