Which encryption methods work best for IoT app integration

A baby monitor connects to a parent's phone. A fitness tracker syncs to a cloud dashboard. A smart speaker sits on the kitchen counter, always listening. Each of these devices makes a promise to its user: that their data is private, that the connection is secure, and that nobody else is listening in. Keeping that promise is harder than it sounds, because the devices themselves often have very little to work with in terms of processing power, memory, and battery life.

The encryption method you choose is shaped by what your device can actually do, not just what the security textbook recommends.

Encryption is the core mechanism that keeps that promise. But which encryption method you choose, and where you apply it, depends entirely on what your device can actually do. A method that works perfectly on a cloud server can grind a small sensor to a halt. A shortcut that seems fine at the MVP stage can become a liability the moment your product scales. These are not abstract concerns. We encounter them on real projects, and the decisions made early tend to be the ones that are hardest to unpick later.

There are now over 21 billion connected IoT devices worldwide, according to SumatoSoft, 2026, and each one represents a potential entry point if its security model was chosen carelessly. This article walks through the encryption landscape for IoT app integration: what the real constraints are, which methods fit which contexts, and where the decisions that look technical are actually product decisions in disguise.

Why Encryption Choice Is a Strategic Decision, Not a Technical One

Developers often treat encryption as a technical checkbox. Pick an algorithm, apply it, move on. But the choice of how and where to encrypt data shapes what your product can do, how quickly it responds, how long the device battery lasts, and whether the system can grow without being rebuilt from scratch.

A product that encrypts everything using a heavy standard will drain battery faster, introduce latency, and require firmware updates across every device when the standard needs changing. A product that encrypts too little will eventually face a data breach or a compliance problem. Neither failure is purely technical. Both have commercial and reputational consequences.

The strategic question is about trade-offs: which data is sensitive enough to require the strongest protection, which connections are genuinely at risk, and what the device can reasonably handle. Getting that calibration right is a design and product decision as much as an engineering one. A team that treats encryption purely as infrastructure will often over-engineer some parts and under-engineer others, because they are solving for theoretical best practice rather than the actual threat model of the product.

This is the same kind of thinking that shapes architecture choices more broadly. On the mental health and wellness product we worked on, we ruled out serverless architecture early because the endpoint usage pattern would have produced unacceptable cold-start latency for real users. The right architecture was the one that served the product's actual behaviour, not the one that looked cleanest on a diagram. Encryption decisions follow the same logic.

The Constraints IoT Actually Imposes on Encryption

IoT devices are not small computers. Some of them are, but many are microcontrollers with kilobytes of RAM, processors running at a fraction of a smartphone's speed, and batteries that need to last months or years without replacement. Standard encryption algorithms were designed for machines with far more headroom than this.

The real constraints fall into four categories. Processing power limits which algorithms can run at all. Memory limits the size of keys and the complexity of the cipher. Battery life means every computation has a cost that compounds over millions of cycles. And network conditions, which can be intermittent or severely bandwidth-limited, affect how much overhead the encryption protocol adds to each transmission.

These constraints vary enormously across device types. A connected home speaker has mains power and a capable processor. A soil moisture sensor in a remote field has neither. An encryption approach that is perfectly reasonable for one product can be completely unsuitable for another, even within the same product category.

Connectivity is a constraint of its own. On a travel product we built for younger backpackers visiting off-grid locations, unreliable connectivity was a core design constraint from the start. We restructured the architecture around what could be stored offline, what had to remain online, how to queue actions and replay them on reconnection, and how to minimise the data sent between app and server. Any encryption layer added to a product like that has to account for the same realities: a handshake that assumes a stable connection will fail in the field.

Symmetric Encryption: Where It Fits and Where It Falls Short

Symmetric encryption uses the same key to encrypt and decrypt data. AES (Advanced Encryption Standard) is the most common example, and it is well-suited to IoT in many contexts because it is fast, computationally light relative to asymmetric alternatives, and widely supported across hardware and firmware environments.

The appeal is straightforward. Once both sides of a connection share a key, AES-128 or AES-256 can protect data in transit with low overhead. For devices sending frequent small payloads, like a fitness tracker logging heart rate every second, this efficiency matters. The device does not have to spend much power on encryption, and the latency is negligible.

Symmetric encryption is fast and computationally light, but the key distribution problem is where the real complexity lives.

The limitation is key management. Symmetric encryption works on the assumption that both parties already share a secret key, and getting that key onto the device securely is a problem the algorithm itself does not solve. If you hard-code a key into firmware, you create a single point of failure: anyone who extracts that key from one device can compromise all devices using the same key. If you give each device a unique key, you need a secure way to provision and store it, and a way to rotate it when it is compromised.

For products where devices are provisioned in a controlled environment and the threat model is relatively narrow, symmetric encryption is a sound choice for encrypting data at rest and in transit. For products where devices are manufactured at scale, distributed widely, and potentially subject to physical tampering, the key distribution problem demands a more considered approach.

AES in practice

AES-128 is the standard starting point for most IoT products. AES-256 adds a margin of safety at a modest additional cost. The decision between them is rarely the hard part. The hard part is deciding how keys are generated, stored, distributed, and rotated across a device fleet.

Asymmetric Encryption and Public Key Infrastructure in IoT Contexts

Asymmetric encryption uses a pair of keys: a public key that anyone can use to encrypt data, and a private key that only the recipient holds and uses to decrypt it. RSA and elliptic curve cryptography (ECC) are the main examples. The advantage is that you can share the public key openly without compromising security, which solves the key distribution problem that symmetric encryption leaves unaddressed.

The disadvantage for IoT is computational cost. RSA operations are significantly more expensive than AES, and on a low-power microcontroller, the difference can be substantial. ECC offers comparable security to RSA with much smaller key sizes, which makes it far more practical for constrained devices. A 256-bit ECC key provides roughly the same security as a 3072-bit RSA key, with a fraction of the computational overhead.

Public Key Infrastructure (PKI) extends this further by adding a chain of trust: certificates issued by a certificate authority verify that a public key genuinely belongs to who it claims to belong to. This matters in IoT because devices need to authenticate the server they are talking to, and the server needs to authenticate the device. Without that mutual verification, the encryption itself can be subverted by a man-in-the-middle attack.

PKI works well for devices that have enough capacity to handle certificate processing and enough connectivity to check revocation status. For the most constrained devices, the overhead of managing certificates across a large fleet can become its own engineering challenge. The practical approach for many products is to use asymmetric cryptography for the initial key exchange and authentication, then switch to symmetric encryption for the ongoing data session.

Lightweight Cryptography for Resource-Constrained Devices

For devices where even ECC is too heavy, a category of algorithms has been developed specifically for resource-constrained hardware. Lightweight cryptography covers ciphers, hash functions, and authentication schemes designed to run on processors with very limited clock speed, RAM, and power budgets.

NIST completed a standardisation process for lightweight cryptography in 2023, selecting ASCON as its standard for lightweight authenticated encryption. ASCON is designed to run efficiently on hardware as small as an 8-bit microcontroller, and it provides both encryption and authentication in a single pass, which reduces the processing steps needed.

The practical difference between standard and lightweight algorithms can be significant. A study testing 32 lightweight algorithms across device categories including Raspberry Pi Zero W and iMX233 measured power consumption, RAM usage, and execution time, finding considerable variation between algorithm families, according to Springer (Information Systems Frontiers). The point is that algorithm choice has a measurable impact on the device's real-world behaviour, not just on paper security ratings.

Match the algorithm to the device's actual hardware. Test your chosen cipher on the target microcontroller, not on a development machine. Execution time and power draw on a Raspberry Pi Zero W will look very different from the same test on a desktop processor.

Lightweight cryptography is not a compromise in terms of security. The algorithms that have passed standardisation offer genuine protection. The compromise is that they are newer, less widely deployed, and may have less tooling support in existing IoT frameworks. That is a practical consideration, not a security one.

Transport Layer Security: Applying TLS Correctly Across IoT Endpoints

TLS (Transport Layer Security) is the protocol that secures connections between devices and servers. It handles the negotiation of encryption algorithms, the exchange of certificates, and the creation of an encrypted session. It is the same protocol that secures web traffic, and it is the standard baseline for any IoT product that communicates over the internet.

Applying TLS correctly in IoT requires attention to a few specific issues that do not arise as often in standard web applications. Older versions of TLS, particularly TLS 1.0 and 1.1, have known vulnerabilities. TLS 1.2 and 1.3 should be the minimum supported versions, with TLS 1.3 preferred where device firmware allows it, as it reduces the number of round-trips needed for the handshake and removes several legacy cipher suites.

Certificate validation matters

A common mistake in IoT implementations is disabling certificate validation to avoid the complexity of managing certificates on constrained devices. This removes the protection against man-in-the-middle attacks entirely. The device will encrypt its data, but it will happily encrypt it to an attacker posing as the legitimate server. Certificate pinning, where the device checks the server certificate against a known value rather than relying on a certificate authority chain, is a practical alternative for products where managing full PKI is not feasible.

MQTT, the messaging protocol used widely in IoT, runs over TCP and can be secured with TLS. HTTPS endpoints in IoT apps follow standard web TLS rules. The challenge is ensuring that the TLS configuration on both the device and the server is consistent and that weaker cipher suites are not negotiated as a fallback during connection setup.

End-to-End Encryption Versus Encryption in Transit

Encryption in transit protects data as it moves between a device and a server. End-to-end encryption (E2EE) protects data from the point it is created on the device to the point it is read by the intended recipient, with no intermediate system able to decrypt it.

The distinction matters because most IoT architectures route data through a cloud backend that processes, stores, and redistributes it. Encryption in transit protects the data while it is moving, but the server that handles it in the middle can read it. For most IoT products, that is acceptable: the cloud backend is part of the product's own infrastructure, and the data needs to be processed there.

E2EE becomes relevant when the data is genuinely private and the server should have no access to its content. A health monitoring device sending readings to a personal health record, where neither the device manufacturer nor the cloud provider should be able to read the data, is a case where E2EE has a strong argument. A smart thermostat sending temperature readings to a control server is not, because the server needs to process those readings to do its job.

Before specifying end-to-end encryption, map out exactly who needs to read the data and at which point in the journey. E2EE removes the server's ability to process data, so any feature that relies on the server reading and acting on the data will need a different design approach.

The implementation cost of E2EE in IoT is real. Key management becomes far more complex when the server cannot access keys. Onboarding users, recovering access when a device is lost, and allowing multi-device access all require careful design. E2EE is the right choice for genuinely sensitive personal data, but it is a product architecture decision as much as a security one.

When There Is No API Layer to Hide Behind

A conventional web or mobile app communicates through an API that sits between the client and the database. The API validates requests, enforces permissions, and acts as a controlled intermediary. Much of the security work happens at that layer, and the database can be configured to trust the API server.

IoT products and certain lean MVPs sometimes remove that intermediary. On the performance coaching survey app we built, we made a deliberate early decision to skip a traditional API for the MVP, connecting the app directly to Firebase. That decision kept the build lean and appropriate for a proof of concept, but it meant that every security rule had to live in Firebase's security rules configuration. There was no API to catch a malformed request before it reached the database.

The result was that we had to scrutinise every security rule very carefully to ensure that neither the app nor the web response page could be exploited. We built a multi-layered model: only authenticated coach accounts could create surveys, each QR code contained a unique key granting read access to only that specific survey, and we used a cookie combined with device fingerprinting to restrict write access to one submission per device per survey. This prevented duplicate responses and ensured respondents could not read each other's answers.

The same challenge applies in IoT when a device communicates directly with a database or cloud storage service rather than through a dedicated API. The encryption and authentication rules that would normally live in server-side code have to be built into the device's communication logic and the database's access control configuration. That is achievable, but it requires more rigour at the design stage, not less.

Direct database communication in IoT

Products using Firebase Realtime Database or Firestore directly from a device need security rules that are as tight as anything an API server would enforce. On the messaging product we worked on, we found that reworking how messages were stored and adding the right database indexes allowed security permission checks to run far more efficiently. The lesson is that security rules and data structure are not separate concerns: how you store data shapes whether the rules can be applied correctly and at what cost.

Authentication and Encryption Are Not the Same Problem

Encryption protects data from being read by the wrong party. Authentication confirms that the party communicating is who they claim to be. Both are necessary, and conflating them leads to products that do one well and the other poorly.

A device can encrypt all its communications and still accept commands from any source that knows the endpoint address. Encryption without authentication means the data is private but the device is controllable by anyone. Authentication without encryption means only the right parties are communicating, but anyone intercepting the connection can read what they are saying.

In IoT, device authentication is a distinct problem from user authentication. A device needs to prove its identity to the server, and the server needs to prove its identity to the device. User authentication then sits on top of that: the person using the app needs to prove who they are, separately from the device proving what it is.

On the anonymous messaging app we worked on, we had to put authentication right upfront because the product required us to tie messages back to specific users on the backend, even though the messaging appeared anonymous to other users within the product. This was necessary for legal reasons, specifically to handle cases of abuse or harassment. The encryption of messages was a separate concern from that authentication requirement. Both had to be designed deliberately, and one could not substitute for the other.

Treat device authentication and user authentication as separate design problems. A device certificate or hardware security key handles the former. A session token or one-time code handles the latter. Mixing them up creates gaps in both.

Testing Encryption Without Real Hardware

Testing an IoT product's encryption implementation before physical hardware is available is a genuine challenge. You cannot verify that a cipher runs within acceptable power and latency budgets on a device you do not have. But waiting for hardware before testing anything is expensive and slow.

On the baby monitor project we worked on, we built a prototype that ran a web server from the device. This allowed us to connect to it, inspect its internals, verify that settings being applied in the app were correctly reflected on the device side, and simultaneously control the device through the app. We were effectively simulating the full communication loop between app and hardware before the final hardware was production-ready.

The same approach can be applied to encryption testing. A simulated device that implements the target encryption protocol allows you to verify that the app and server handle encrypted payloads correctly, that certificate validation works as expected, and that key exchange completes within acceptable timeframes. The things you cannot test this way are hardware-specific: power consumption, timing on a specific processor, and the behaviour of a hardware security module if one is used.

For lightweight cryptography in particular, algorithm performance on the actual target hardware is the test that matters. Benchmarks from similar device categories give a starting point, but the only reliable figure is one measured on the device that will ship.

How Offline and Intermittent Connectivity Complicates Encryption

Most encryption protocols assume a reliable connection. TLS handshakes require a round-trip exchange. Certificate revocation checks require network access. Key rotation requires both endpoints to be reachable. When a device can go offline for extended periods, all of these assumptions need revisiting.

On the travel product for backpackers visiting off-grid locations, we restructured the architecture around four principles: what information could be stored offline, what had to remain online, how to queue offline actions and replay them once reconnected, and how to minimise the data exchanged when a connection was available. Anything that could be baked into the product was. Everything else was kept as lightweight as possible.

An IoT product that operates in areas with intermittent connectivity faces the same questions applied to encryption. If a TLS session expires while a device is offline, reconnecting requires a new handshake. If certificate revocation cannot be checked, the device has to decide whether to trust a cached certificate or refuse to connect until it can verify. These are product decisions that need to be made explicitly, with a clear policy for what the device does in each scenario.

1. Define which data is encrypted before storage on the device, so offline data is protected even if the device is physically accessed.
2. Set a clear policy for certificate validation when revocation checks are unavailable.
3. Handle session re-establishment gracefully on reconnection, without requiring user intervention.
4. Queue encrypted payloads for transmission rather than holding unencrypted data until a connection is available.

Products that skip these questions at the design stage tend to discover the gaps in the field, which is both harder and more expensive to fix.

Scaling Encryption Decisions Across a Growing Device Ecosystem

An encryption approach that works for a pilot fleet of fifty devices can create significant operational problems at fifty thousand. Key management is the area where this most commonly surfaces. If every device has a unique key provisioned at manufacture, you need processes for generating, storing, distributing, and rotating those keys at scale. If you use a shared key across a device class, a single compromised device can expose the entire fleet.

Certificate lifecycle management compounds this. Certificates expire. When they do, every device in the field needs to receive a new certificate through a firmware update or an over-the-air provisioning mechanism. If that update fails on a subset of devices, those devices stop functioning. The engineering effort to handle this reliably across a large fleet is substantial.

The learning management system for cybersecurity that we worked on used a serverless architecture with AWS Lambda and S3, which kept servers from running continuously and avoided charges for idle capacity. That kind of architectural efficiency at scale applies equally to the infrastructure that supports encryption operations: certificate authorities, key management services, and revocation checking all have operational costs that grow with the device fleet.

The practical implication is to design for scale from the start, even if you are launching with a small number of devices. The encryption architecture that requires manual key provisioning is manageable at ten devices and becomes a full-time operational problem at ten thousand. Choosing a hardware security module that supports automated provisioning, or a key management service that handles rotation automatically, adds modest complexity early and avoids a much larger rebuild later.

Conclusion

Encryption in IoT is a series of decisions, each shaped by what the device can do, what data it handles, who needs to read that data and when, and how many devices will eventually be in the field. The right answer for a baby monitor with mains power and a capable processor is different from the right answer for a soil sensor with a coin cell battery and a two-year service interval.

The projects we have described here share a common thread: the security model that worked was the one designed around the actual product, not the one borrowed from a different context. The performance coaching survey app needed tight Firebase security rules because there was no API layer. The fitness social app needed randomised location offsets because the user base made precise location sharing a genuine safety risk. The off-grid travel product needed an offline-first architecture because the connectivity assumption did not hold.

Good encryption decisions start with an honest account of the constraints: hardware capability, connectivity reliability, data sensitivity, and the threat model that actually applies to the product. From there, the choice of algorithm, protocol, and key management approach follows logically. The complexity is real, but it is tractable when the questions are asked in the right order.

If you are building an IoT product and want to think through the encryption architecture before it becomes a problem to fix, let's talk about your IoT security model.

Frequently Asked Questions