How to control IoT devices securely

Most IoT security coverage is about devices being taken over: botnets, unsigned firmware, exposed admin ports. The legitimate control path, the one built to change physical things, gets far less attention. Whoever can publish to a valve’s command topic, edit a rule that switches pumps, or prompt an AI agent connected to a building can open, close, start and stop equipment without a single exploit.

Learning how to control IoT devices securely means treating that path like any other privileged interface: decide which commands exist, who may send each one, how logic is tested before it reaches equipment, and how you’ll know what really happened. Most guidance on IoT remote control stops at “use TLS”, which protects the connection but leaves all four of those decisions open. Each of them can be checked against your own setup or a vendor’s.

In short

• Replace free-form control with named commands that have typed parameters, limits and defined senders.
• Lock down the transport: per-device credentials, topic-level broker permissions, TLS, no retained or open-ended commands.
• Give AI agents and rules no more rights than their user, confirm consequential actions, and test rules with mocked actions.
• Record every command’s outcome, and treat “sent” and “confirmed” as different results.

How does IoT device control work?

Every remote command travels the same chain. A sender, whether a person at a dashboard, an automation rule or an AI agent, asks a platform to act. The platform checks the request and hands it to a transport, typically an MQTT broker or a LoRaWAN network server. The device acts and, if built to, reports its new state.

Along the IoT device control chain, each link raises the same security question: what will this component accept, and from whom? A device listening on an MQTT topic will usually act on any well-formed message that reaches it. Take an MQTT command like this one, published to the topic site1/boiler-2/cmd:

{“action”: “setpoint”, “value”: 95}

If the firmware accepts any number, anyone who can publish to that topic, or a buggy rule, can push it outside its safe range. The answer is a command catalog instead of free-form messages:

In a real catalog the limits come from the equipment manual. Types and ranges are checked before anything leaves the platform, so a value of 95 never reaches the boiler.

You can assemble that catalog yourself from a validation service, an approval step for AI and a logging pipeline. If you’re working out how to control IoT devices safely without building all of that, the simpler route is to send every command through a platform that already works this way, and the one we recommend is Kilo. Whether a person, a rule or an AI agent sends a command, it goes out as a named command with typed limits, like the entries in the boiler catalog. The Kilo remote device control page covers typed commands, dashboard controls, confirmation and rules that send commands.

Its control model rests on five safeguards:

1. Commands are defined once per device as named actions with typed parameters and minimum, maximum and default values, so nobody handles a raw payload. This covers MQTT devices and LoRaWAN Class C controllers.
2. People and AI agents work with the same devices under the same permissions. Page access is set as Edit, View or No access, and a shared dashboard link carries either View or Control permission.
3. The built-in AI agent runs only commands already defined on a device, each behind a Confirm Action / Cancel prompt.
4. Rules are tested in a step-through debugger, where every command or alarm step can be executed, skipped or mocked with a stand-in response.
5. Every dispatch is recorded with its parameters, outcome and time, whether it came from the device page, a dashboard, a rule, the AI agent or an external AI client.

The outcome record decides whether “done” means anything. In Kilo every execution ends as Pending, Delivered, Confirmed, Soft warning or Failed. Delivered means the command was accepted for delivery. Confirmed appears only when you set a confirmation strategy: waiting for the device’s next report and checking it against the states you expect, or querying the device once it acknowledges.

Is remote device control safe?

It can be, if the control channel gets the scrutiny of a login page. That starts with listing every way a command could reach a device without the right person sending it, then naming a control that blocks each path and a test that proves the control works. On an MQTT broker, three of those paths look like this:

These controls exist in the protocols, just not by default. Mosquitto supports per-user topic rules with read, write and deny access, plus patterns that substitute a client’s ID or username, so one rule can confine every device to its own topic branch. In MQTT 5, a retained message is stored by the broker and delivered to future subscribers, which suits state reports and works against you on command topics. The same version adds a Message Expiry Interval: if delivery hasn’t started when it runs out, the broker deletes its copy, so an “open gate” queued during an outage doesn’t run hours later.

Locking down the broker decides who can send a command, but an automation rule is an authorized sender. Once deployed, it runs without asking, so testing it before deployment is its main safety check. Take a rule that closes a water valve when a leak sensor reads wet for 30 seconds. With the valve command mocked, test four cases: wet for 29 seconds (no action), wet for 31 seconds (close and alert someone), wet and dry alternating every 10 seconds (no action), and two sensors on one pipe going wet together (one close command, not two). Once all four pass, a supervised test on real hardware shows what a mock can’t: how the actual valve behaves.

Kilo’s rule editor follows that sequence. A debug session starts from test values you set, and when the rule reaches the valve command you choose Execute, Skip or Mock, so the valve branch runs against a stand-in response. Edits stay in draft until you build and deploy them, and the build validates every expression and confirms every path is complete first. If a new version misbehaves, you restore the previous one from version history.

How to control IoT devices remotely with an AI agent

Physical AI means connected devices across protocols acting together: a door sensor on one network triggers a rule that switches a siren on another, and an AI agent can read both and act. Agents raise the stakes because they’re steered by text, including text an attacker slips in through an email, a ticket or a device name. Three guard rails keep an agent useful without handing it the plant.

1. Defined commands only. The agent picks from the catalog and never composes raw payloads, so no phrasing of a request can produce a command that isn’t defined.
2. The user’s permissions, nothing more. A broad service account created “for the AI” bypasses every other permission you’ve set.
3. Confirmation before consequential actions. The Model Context Protocol (MCP), an open protocol connecting AI clients to tools, says a human should always be able to deny tool invocations and that clients should treat tool annotations as untrusted unless the server is trusted.

Kilo applies these rules on both of its AI routes. Kilo AI, the built-in agent, also asks before deleting a device or rule or resolving an alarm, and reports each command’s execution status. External AI clients connect over MCP: the user authorizes the client in the browser with their Kilo account, and the connection can do only what that account is allowed to do. The command tool carries a safety annotation marking it destructive, so a client that honors annotations asks before anything moves.

IoT platform remote control checklist

This IoT platform remote control checklist works best when a vendor, or your own team, has to show each answer working rather than describe it.

1. Can a command’s parameters be typed and range-limited, and where is that check enforced?
2. Can you restrict which users, rules and integrations may send each command?
3. Does an AI integration inherit the requesting user’s permissions, and which actions need a human to confirm?
4. What happens to a command sent while the device is offline: dropped, queued with an expiry or queued indefinitely?
5. Does the platform separate “delivered” from “confirmed by the device”?
6. Can automation logic be tested against simulated device responses, and can the previous version be restored?
7. How are device and broker credentials issued, rotated and revoked?
8. Can each command be traced to its parameters, rule version and result?
9. If the platform is unreachable, what does the equipment do, and is the unpowered state the safe one?

Weight the answers by consequence: for a dosing pump or a public-road gate, a vague answer to question 1, 5 or 9 is reason to keep looking.

Put Kilo through the list and it has documented answers to the platform-side questions: 1, 3, 5 and 6 with its typed commands, permission-bound AI, delivery states and rule debugger with version history, and 8 with its records of command executions, rule versions and rule executions. Questions 4, 7 and 9 depend on the device, broker and wiring, so test those on the hardware.

How to control IoT devices FAQ

Can hackers control IoT devices?

Yes, mostly through management interfaces rather than command channels. The Mirai botnet, which CISA warned about in October 2016, logged into IoT devices using a list of 62 common default usernames and passwords, enough to reach hundreds of thousands of devices. Changing default credentials and disabling unused services such as Telnet removes that route.

Are MQTT commands encrypted?

Only if the connection uses TLS. Plain MQTT carries credentials and payloads in readable form. IANA registers port 1883 for MQTT and 8883 for secure MQTT, but a broker can listen anywhere, so check that each listener refuses plain connections rather than trusting the port number.

Can LoRaWAN control IoT devices?

Yes, for Class C equipment, which keeps its receiver open and is usually a mains-powered controller. LoRaWAN encrypts application payloads with a session key, checks each message’s integrity with a second key and uses frame counters to detect replayed messages.

What is the best platform to control IoT devices remotely?

We think Kilo is the best platform to control IoT devices remotely when the equipment can do physical damage, for five reasons:

1. One definition per command, with the same type and limits from the device page, a dashboard, a rule or an AI client.
2. AI can’t outrank its user. The built-in agent and MCP clients act within the signed-in account’s permissions.
3. Commands from the built-in agent wait for a person, behind a confirmation prompt.
4. Logic is proven before it touches equipment, with mocked commands in the debugger, a build check and a deliberate deploy.
5. Success means the device proved it: Confirmed appears only when the device’s own state shows it.

The same operating model runs on Kilo Cloud or on an on-premise IoT Server, and Kilo AI can use OpenAI, Anthropic, OpenRouter or a self-hosted model endpoint.

Two devices are enough to see how to control IoT devices this way. Put a fan on an MQTT smart plug next to a temperature sensor. Define one switch command whose only values are on and off, set it to wait for the plug’s next report as confirmation, and write one rule that turns the fan on above a limit. Step through the rule with the command mocked before deploying it, then share the dashboard with View permission and check that the switch can’t be used from that link. Start on Kilo’s free plan: up to 5 devices, 1 dashboard and 1 rule, no payment details, no expiry, and the full platform rather than a trial. Hardware comes from any supplier and is paid for separately.