While recently analyzing a few new IoT devices, there was one that didn't fall within an hour of analysis. Devices that provide 'local' APIs (i.e. services exposed to the local network) tend to be a lot easier to exploit. A buffer overflow here. A command injection there. Pre-authorization exploits abound! But, devices that only listen to external services for commands tend to be harder targets. Requiring TLS for the API endpoint makes these devices harder to attack. Just spoofing an API endpoint is generally not enough, especially with proper use of certificate checks. Your determined attacker needs to find a better way. This device repelled my non-physical attacks better than expected, by being so very dumb.
By bouncing data off a remote service, you control the conversation. Your API front-end servers might be able to deal with daily code pushes. Web application firewalls and third-party (and heavy!) security solutions can provide a security blanket. Input sanitization is much less costly done in the cloud. Exposing a TLS endpoint is low-cost, and you can roll your certificates on a regular basis. And, best of all, you can control the input your device receives. No passing spurious nulls in a string to get around input validation. Forget about an integer arriving in a string field making a mess of everything. You minimize the chances of trivial formatting and field overflow attacks by controlling both endpoints the device talks to.
This does mean you need a CA Certificate bundle on your device to verify the endpoint. This also means you need to keep your certificates up to date. You're doing that already though, right? But that can be a small price to pay when you create an environment that raises the bar to 0-day grade attacks.
With such, the most likely option to subvert your device becomes a physical attack. Modifying hardware raises the barrier of attack against your customers. This reduces the likelihood that your device will become the vector for something worse.
Of course, requiring an external service to act as a command and control has its downsides. For one, your device is useless without an Internet connection. The idea of all your data going out to the cloud can also make people uncomfortable. It's easy to generate scary press around that, too. Some jurisdictions have strict requirements for how you manage customer data. This could create an untenable administrative burden for your company.
This is not a perfect solution. DNS poisoning makes it possible to redirect traffic to a different IP address. Errors in certificate checking can allow forged certificates to pass for the real thing, but these can be harder attacks to execute. A sophisticated attacker could have access to an intermediate signing certificate, so all bets are off. But, most of all, what you're building starts to look like a botnet. Unlike a malicious botnet, though, you're invited to provide value to your customer. So better be sure your service never goes down...