Laptops get patched every month, run endpoint protection and belong to a named person. The temperature sensor in the server room, the controller on the boiler and the camera over the loading bay often have none of that, yet each one is a small computer with firmware, credentials and a connection to your network or to the internet. IoT device security is the work of making sure those small computers can't be turned against you, and that the data they produce reaches only the people it's meant for.

Most of the improvements are unglamorous: better questions when buying, sensible key handling, encrypted links and a platform that limits what anyone can do. The rest of this article walks through them in the order you'd meet them, from the risks to the standards, the data and the software that manages it all.

In short

  • IoT security covers four layers: the device, the network it uses, the data it sends and the platform that manages it.
  • The main risks are botnets, network entry points, exposed or falsified data and physical actions triggered by the wrong party.
  • New rules, such as the UK's PSTI regime and the EU Cyber Resilience Act, now put security duties on manufacturers.
  • The platform deserves as much scrutiny as the devices, because it holds the keys and can send commands to all of them.

What is IoT security?

IoT security is the set of practices and technical controls that protect connected devices, the networks they communicate over, the data they produce and the platforms that collect that data and control the devices. It's a branch of cybersecurity, but the conditions are different enough that habits from office IT don't transfer cleanly.

Four differences explain most of the difficulty. Many devices can't run security software at all, because a battery-powered sensor has a tiny processor and a power budget measured in years. They also stay in service for a long time, often much longer than the vendor plans to support them. On top of that, they sit in physically reachable places, such as corridors, car parks and plant rooms, where someone can unscrew an enclosure. And they're bought by facilities, operations or engineering teams as often as by IT, so they can arrive without anyone checking how they're secured.

That's why IoT device security keeps going long after the purchase. It involves how a device is built, how it's set up, where its data goes and who can act on it, and each of those stages has its own owner.

What risks are posed by IoT devices?

The best-known example is Mirai. In 2016, this malware took over large numbers of internet-connected cameras and home routers by trying a short built-in list of factory-default usernames and passwords, then used them to flood targets with traffic. One of those attacks, against the DNS provider Dyn in October 2016, made a number of major websites unreachable for parts of the day. The devices weren't unusual in any way; what they had in common was default passwords and services reachable from the internet.

Botnets are only one of the risks, though. The table below lists the ones that matter for a business deployment, with what each looks like and the cause behind it.

Risk What it looks like Usual cause
Recruitment into a botnet The device sends attack traffic on someone else's behalf Default or shared passwords, services exposed to the internet
Entry point to the network An attacker reaches servers through a compromised device Flat network, unpatched firmware
Exposed data Readings, video or locations are seen by outsiders Unencrypted traffic, weak platform accounts
Falsified data Fake or replayed readings hide a real problem No message authentication or replay protection
Unwanted physical action A relay, valve or lock is operated by the wrong party Broad command rights, no limits on what can be sent
Abandoned devices Known flaws that will never be fixed Vendor support ends, no stated support period

The last two rows have little equivalent in office IT, where the worst case is usually data loss. With connected equipment, the worst case can be a door unlocked at night or a pump switched off. And because devices often outlive their software support, a device that was well secured on the day you installed it can become the weakest point in the building a few years later. Falsified data is subtler still. If a cold-room sensor's messages could be recorded and replayed, a copy of yesterday's normal 3 °C reading could keep a dashboard looking calm while today's compressor has already failed.

IoT device security standards

For years, device security was voluntary. That's changing, and the standards that grew up in the meantime now give buyers a useful vocabulary.

ETSI EN 303 645, a European standard first published in 2020, sets a baseline for consumer IoT devices in 13 provision categories. Its first three are no universal default passwords, a way to report vulnerabilities, and keeping software updated. A universal default password is one that's identical on every unit, the classic admin/admin, which anyone can look up in a manual. Although it's written for consumer products, many business buyers use it as a reference because it's short and concrete.

In the United States, NIST published a core baseline of device capabilities in 2020, NISTIR 8259A. It names six: device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness, meaning the device can report on its own security state.

Regulation has followed. The UK's product security regime under the Product Security and Telecommunications Infrastructure (PSTI) Act came into force on April 29, 2024. It bans universal default passwords on connectable consumer products, requires a published way to report vulnerabilities and requires manufacturers to state a minimum period of security updates. In the EU, the Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on December 10, 2024. Its obligations to report actively exploited vulnerabilities apply from September 11, 2026, and most of its other requirements apply from December 11, 2027.

You don't need to memorize any of this to buy well. The standards boil down to questions you can put to any device vendor:

  1. Does every unit ship with a unique password or key, or force you to set one during setup?
  2. How are firmware updates delivered, and for how many years will security updates be provided?
  3. Is there a published way to report a vulnerability, and does the vendor say how fast it responds?
  4. Is data encrypted between the device and the gateway or server, and with which keys?
  5. Are keys unique per device, and can they be changed if one is exposed?
  6. If someone opens the enclosure, are debug ports or stored secrets reachable?

How do you ensure IoT data security?

IoT data security means protecting readings, images and locations at every stage: while they travel, while they're stored and when someone opens them. Each stage needs its own control.

In transit, the device's own radio protocol does part of the work. LoRaWAN, a common low-power radio protocol for sensors, encrypts payloads with AES-128 and uses separate session keys for two jobs: a network session key that checks a message's integrity, and an application session key that encrypts its content. Frame counters let the network reject a recorded message that someone tries to replay. A LoRaWAN sensor also has no IP address, so it can't be scanned or logged into from the internet the way a camera can; its weak points are its keys and physical access to the unit itself. Devices that speak IP, such as cameras and gateways, should use TLS with certificate checks, so that a device can't be fooled into sending data to an impostor server.

At rest, data on servers should be encrypted, and the keys that protect it should be stored separately from the data itself. The same discipline applies to device keys during installation. A spreadsheet of device keys emailed between installers is a common weak point, because anyone who gets the file can impersonate every device on it.

Then there's minimization. A sensor that reports occupancy every minute paints a far more detailed picture of people's behavior than one that reports a daily count. If the use case only needs the daily count, configure the daily count, so the detailed picture never exists anywhere to be exposed. Decide retention up front, too: how long readings, locations and recordings are kept, and who decides to delete them.

What does IoT platform security cover?

The platform is the software that registers devices, stores their data, runs automations and sends commands back. Because it holds the device keys, the user accounts and the ability to act on every device at once, a weakness there is worse than a weakness in any single sensor. IoT platform security therefore covers who can sign in, what each account can see and do, how integration credentials are issued and revoked, where device keys are kept, how commands are constrained, and what records exist afterward.

One way to test any platform is to walk through a contractor leaving. Ideally you remove one account and that person's access to the data, the devices and the commands ends there, while the credentials their tools used can be replaced one at a time without breaking anything else. If three installers shared one login, or an integration runs on somebody's personal password, nothing can be withdrawn cleanly, and you won't know afterward who did what.

What is the best IoT platform for data security?

Firmware updates, default passwords and debug ports are decided by the device maker, which is why the questions you put to device vendors matter so much. The platform choice covers everything after a reading leaves the device, and for IoT data security the best platform is the one that lets you decide precisely who can reach the readings, the device keys and the integrations. On that test, Kilo is the best choice, and three of its controls show why.

Access is set per page, so nobody needs full admin rights just to do one job. Each person gets Edit, View or No access on pages such as Devices, Rules, Connectors and API Keys, and Kilo's attribute-based access control also takes membership and ownership into account. An installer can register devices without touching the subscription, and a site manager can follow the readings without being able to change a rule.

Device keys go into Key Vault instead of a spreadsheet. It stores LoRaWAN device keys, the EUIs and key pairs, encrypted and behind its own page permission, so the people who add sensors can reach the keys while everyone else is set to No access.

When another tool needs the data, it gets its own API key instead of a person's login. Each key is bound to one organization and scoped per area, usually with separate Read and Write scopes. A new key grants nothing until you select scopes, it can carry an expiry date, and rotating it deactivates the old value immediately. The access model and the API key controls are described in more detail on Kilo's IoT security overview.

IoT device security FAQ

What is the most common IoT security vulnerability?

The OWASP IoT Top 10, published in 2018, ranks weak, guessable or hardcoded passwords first. Insecure network services come second and insecure ecosystem interfaces, such as the web, cloud and mobile interfaces around a device, come third.

How long should IoT devices get security updates?

Under the EU Cyber Resilience Act, the support period should reflect how long the product is expected to be used, and it must be at least five years unless the product is expected to be in use for less time. Many industrial devices stay installed longer than that, so the stated period is worth comparing with your own replacement plans.

Who is responsible for IoT device security?

Both the maker and the operator. Regulations such as the Cyber Resilience Act place duties on manufacturers and also on importers and distributors. The operator still controls installation, network placement, credentials and decommissioning, which includes factory-resetting a removed device and deleting its keys from the platform.

Does IoT device security include physical security?

Yes, because many devices sit within reach of the public or of contractors. Common measures are tamper switches that report when an enclosure is opened, security screws, mounting out of easy reach, and vendors disabling or locking debug interfaces such as UART and JTAG on production units.

You can set this up today on Kilo's free plan, which covers up to five devices, needs no payment details and doesn't expire. Register a few LoRaWAN sensors with their keys stored in Key Vault instead of a shared file, give a colleague who already has a Kilo account View access to the Devices page, and create a read-only API key for the tool that will pull the data. Device diagnostics then show whether each message was routed, mapped and stored.