The Internet of Things is a constantly changing landscape of technology and connectivity. It’s always evolving, and in today’s fast-moving technological environment, you either keep up or get left behind. That’s why adopting the right IoT strategy for your business is crucial — and IoT management tools are the hub that holds all of the IoT spokes in place.

What is IoT Device Management?

IoT device management refers to the suite of tools and practices designed to effectively organize, monitor, deploy, configure, and maintain the connected devices within an IoT ecosystem. It ensures that each device is provisioned, authenticated, configured, and monitored properly, allowing seamless interactions between the devices and guaranteeing that they operate efficiently and securely. It’s like having a meticulous conductor, ensuring each instrument in the orchestra plays in harmony, striking the right chords at the right time. 

IoT setups include a variety of components and connections. Since most sensors don’t have a traditional operating system (or at least not a “full” OS), they can be challenging to manage individually. But that’s also the purpose of the primary gateway — this, in effect, manages the sensors. You, in turn, manage the gateways using an IoT device management provider. 

The ability to remotely manage IoT devices is crucial to IoT device management. This allows administrators to control, update, and monitor the status of their devices from anywhere, providing unparalleled convenience and flexibility. Remote management is not just about convenience, though — it’s also about quick response times to any issues that may arise, ensuring uninterrupted service and reducing downtime. 

IoT devices can be managed in many contexts — in the enterprise (i.e., internal to an organization), B2B, B2E (business to employee), or B2C. For the B2B and B2C use cases, IoT device communication usually works over public cloud infrastructure. But for some internal enterprise networks or other high-security environments, this communication may occur via private cloud over a dedicated IoT gateway.

What Processes Govern IoT Device Management?

IoT device management is governed by principles and processes that largely mirror dedicated device management. In rough sequence, the IoT device management lifecycle goes like this:

1. Device provisioning and onboarding
2. Configuration and policy management
3. Monitoring and diagnostics
4. Firmware and software lifecycle management (OTA updates)
5. Decommissioning

Steps 2, 3, and 4 are repeated throughout the device’s lifecycle, with step 5 (decommissioning) marking the end of that device’s useful life.

Many scaled businesses require an IoT device management strategy, whether you’re in the retail, quick service restaurant, T&L, healthcare, or manufacturing industry. IoT is everywhere at this point, and almost any organization operating at enterprise scale needs IoT device management tooling.

Manage IoT Devices with Esper >

How Do I Manage IoT Devices? What Software do I Need?

Before you get into the tools used for managing IoT devices, it’s important to understand what an IoT device actually is. And that’s because there is no “one stop” IoT device management solution on the market — even if some of them may market this way. IoT is far too broad an ecosystem to bundle into a single management frontend (unless your definition of IoT is unusually narrow).

Sidebar: What really is an IoT device?

This is a tricker question to answer than you might think!

Some examples of commonly-managed IoT devices include (but definitely aren’t limited to):

• Building control systems (HVAC, lighting, door locks, cameras)
• Environmental sensors (thermostats, humidity / water sensors, movement sensors, smoke detectors)
• Fleet telematics devices (or even vehicles themselves, though this is debatable)
• Wearables (medical devices, AR glasses)
• Asset trackers
• Consumer appliances (health, lifestyle, sport, and home IoT)
• Retail transaction systems (POS systems, self-serve kiosks, handheld payment devices)
• Connected display signage
• Logistics and warehousing handhelds
• Industrial sensors (monitoring devices for manufacturing, agricultural equipment, and logistics)
• Infrastructure sensors (smart traffic lights, electrical grid monitoring, environmental disaster sensors)
• Network printers (yes, really)

Perhaps a better question is: What isn’t an IoT device? The best way to exclude something from the IoT category is to classify it as a general-purpose computing device — like a smartphone, tablet, laptop, or desktop computer. IoT devices usually serve a very narrowly defined, dedicated function. But “usually” does a lot of lifting there.

Note that some IT practitioners may argue that IoT only refers to simpler (often, explicitly headless) computers. But the definition of IoT is fuzzy, and there is no true bright line. Also, it’s common to confuse edge devices and IoT devices: The two terms are not mutually exclusive — many edge devices are IoT devices, and vice versa. Edge is about location (i.e., at the computing edge), IoT is about function. They aren’t two different “types” of device.

Common components of IoT devices

Most IoT setups are comprised of a handful of components: 

• Devices/Sensors: The feelers of the IoT, gathering intel from their surroundings. Things like door sensors, temperature monitors, and even cameras fall into this category. 
• Connectivity: This ensures all devices are in sync and in harmony, whether through Wi-Fi, Bluetooth, or other networks.
• Cloud Data: The collection point where all the data gathered by the devices and sensors is stored. It’s a central repository where every device, sensor, and gateway transmits data. 
• Gateway: This is the control center of the entire operation — the bridge between the sensors, the cloud, and the user. This may or may not have a display.

This can vary, and more complex scenarios will involve more parts. But, by and large, this is the gist of how an IoT network operates on a basic level. 

Types of IoT Device Management Software

With a good definition of IoT device in hand, you’ve probably already guessed something: You don’t want the same software managing your corporate HQ HVAC sensors as you do your retail point of sale systems. One of those systems might need a software update every year or two (the HVAC), the other might need one once a week (POS). One is a revenue-critical system (POS), the other isn’t (HVAC).

Simple IoT device management (control systems, sensors, and headless)

Like the HVAC example above, you might call this the spiritual “core” of IoT — the devices that operate silently, reporting tiny data streams all day, every day, so that everything keeps running smoothly, safely, and within acceptable performance parameters. These are the simple, headless sensors and control devices that comprise the vast volume of the IoT universe.

Managing sensors, controllers, and other simple headless devices is a commodified use case. There are platforms in the UEM (Unified Endpoint Management) and explicitly IoT-targeted space that are well-suited for such devices, and have commensurately commodified pricing models. 

Typically, pricing for simple IoT management software is weighted much more on cloud messaging usage than the number of devices managed — devices may cost pennies per hundred or thousand registered.

These tools are appropriate for enterprise, B2B, and B2C uses. 

Complex IoT device management (POS, kiosk, medical, and handhelds)

This is where our POS system from the earlier example comes into play. Complex IoT use cases require “management as infrastructure” tooling that can guarantee robust uptime, reachability, updateability, and always-on monitoring. These devices tend to be business or revenue-critical, and often (though not always) have some kind of HID (human interface device) use case.

Managing complex IoT devices like POS systems, self-serve kiosks, patient monitoring systems, and logistics handhelds is a dedicated enterprise infrastructure use case. You need software that can meet the robust demand and performance expectations your organization has set for these devices. That means frequent updating, high velocity deployment (often, in distributed, remote locations), and powerful remote monitoring and support capabilities. There are relatively few tools on the market that specialize in complex IoT device management, and fewer still that can offer support for multiple operating systems (given your devices may run Android, Windows, Linux, or iOS — or a mix of them).

Pricing for complex IoT management software is based on device count (a high volume of messaging and communication is assumed, and often built in) and the set of capabilities needed for those devices.

For the rest of this post, we’ll focus on the complex IoT management use case.

Features of Complex IoT Device Management Software

There are core tooling features you want to look for when managing complex IoT devices. Here’s a list breaking down some of the most important ones.

Provisioning: Of course, it should be included, but it should also give you the ability to streamline the provisioning process, and eventually go to zero-touch (power on and step away) device provisioning.

Multiple OS support: It’s difficult to adopt a centralized IoT device management strategy when you need a different management frontend for each of the operating systems you run. Multi-OS support is a major value-add. Explicit support for vendor-specific enrollment like Samsung Knox and Apple Business Manager are also big “nice to haves.”

Centralized dashboard: All of your managed devices should appear in a single dashboard.

Remote access and control: See what’s happening on your devices and take control of the interface remotely over a secure connection.

Remote CLI: For platforms like Android, Windows, and Linux, remotely CLI or terminal access can be crucial to debugging and testing devices in the field.

Remote log access: Get device logs from anywhere to supercharge your debugging workflow.

OTA updating: For applications, content, and firmware, it’s crucial to have direct control over your OTA process. When you hit “deploy,” something should actually happen. And you should have the option to deploy your apps and firmware directly.

Security and compliance tools: The ability to lock down devices to prevent tampering, monitor their location, and ensure they have the latest security patches are all important.

Telemetry monitoring: You should have programmatic access to device status, including temperature, battery health, CPU, storage, and RAM usage, and more to ensure device health remains optimal.

Automated alerts and reporting: The ability to define your own custom alerting regime so that you can get alerts that actually matter to you is critical as your fleet scales. Stop the noise, and focus on the conditions that you know tell you something meaningful.

API and SDK: The ability to plug your device tooling into your existing workflows and infrastructure can be a game-changer for scale and innovation. A good device SDK lets you customize your setups and behavior in the ways that your use case uniquely requires.

How to Choose an IoT Device Management Platform

With the context we’ve laid out above, you should now have an understanding of basic IoT device management principles, what an IoT device is, how IoT device types have different management requirements, and which bucket your use case tends to fall into as a result.

If your IoT device use case is exclusively of the “simple” device type, you need a commodity IoT device management platform. Whether that’s a niche tool designed for your particular set of uses (e.g., building sensors, industrial control systems) or something built for extreme B2B/B2C scalability (e.g., into the millions of devices), requires further evaluation.

If your IoT device use case involves even some complex IoT devices, you need a dedicated IoT-as-infrastructure device management platform. The specific features you’ll require will vary depending on the exact nature of your use case, but some of the core capabilities to look for include:

• Support for multiple operating systems
• Robust remote access and support featuresets
• Real-time device monitoring
• Direct control over OTA / FOTA processes
• Broad scalability and support for managing complex organizational hierarchy

If you have complex IoT device management requirements, here’s a questionnaire you can take to vendors that asks specific, nuanced questions about many of the capabilities we’ve discussed here. 

IoT device management software questionnaire

Remote features

• Can I remotely control devices, not just view them?
  
  • On which operating systems?
  • Does your remote control feature only work with specified vendors or devices? Is there a published list?
  • Do you charge extra for remote control?
• Can I access a remote terminal on my devices?
  
  • For which operating systems?
  • Does your remote terminal feature only work with specified vendors or devices? Is there a published list?

OTAs and updates

• Can I schedule my OTA updates in stages?
  
  • Can I define pass/fail logic for staged OTA rollouts?
• Can I target OTA updates by device group?
• What stores or services do you support for delivering OTA updates?
  
  • Can I deliver OTA updates from my own cloud?
  • Do you offer a cloud to distribute OTA updates from your management platform directly?
• Can I automate OTA rollouts based on delivery of a new application package to a cloud bucket?
• Do failed OTA updates automatically retry on devices? How long between tries?
• Can you estimate how long an OTA rollout of a 100MB application package would take for a fleet of 1000 devices?

API and SDK dev features

• Do you have a public API? Is it documented? Provide a link to the documentation.
  
  • Is there an additional charge for API access?
• Do you provide a device SDK? Is it documented? Provide a link to the documentation.
  
  • Does your SDK have a device compatibility list? Provide a link to the list.

Telemetry

• List the telemetry metrics your platform gathers from devices
  
  • Are these same metrics available to all devices, or only to specified vendors or models?
• Can I stream telemetry via API from your platform? 
  
  • Does that include all the telemetry metrics you described above?
  • Are there restrictions on throughput?

Device grouping 

• Can I group devices arbitrarily? 
  
  • Can I place a device in multiple groups? 
  • Can I place devices in nested subgroups?

Multi-OS

• Do you support multiple operating systems? If yes, which ones?
  
  • Describe the ways the remote viewing and control feature sets for those operating systems differ.
  • Can I see devices with different operating systems inside the same window of your management frontend?
  • Can I place devices with different operating systems inside the same group?

Multi-tenant and RBAC

• Can I spin up multiple managed tenants of your platform?
  
  • Is there an extra cost associated with multiple tenants?
• Do you have role-based account control (RBAC)?
  
  • Describe all the permissions which can be delegated.
  • How many role types can I have per tenant?

IoT device management tool red flags

Our questionnaire is designed to make one thing very apparent when evaluating vendors: Are they actually comfortable getting into details about their platform capabilities, or do they quickly pivot to vague commitments and a lot of “I’ll get back to you on that”s? But there are other red flags to watch for as you conduct your search — here are a few.

• Red flag 1: Lots of features tied to preferred device vendors or device models.
  
  • Why: This vendor is going to try to push hardware on you and lock you in to a specific device maker.

• Red flag 2: No public developer documentation (no public API, no SDK).
  
  • Why: There’s no customization “secret sauce” that’s so secret a vendor can’t risk documenting it. More likely: Their APIs are constantly in flux or don’t work reliably for many devices or vendors.

• Red flag 3: Heavy focus on employee smartphone and tablet use cases in demos.
  
  • Why: These are platforms designed for BYOD use cases that have extremely lax requirements around core capabilities like remote access, OTA updateability, telemetry, and device customization. You’re fundamentally looking at the wrong tool.

• Red flag 4: Lots of promises that “we can build that for you.”
  
  • Why: Building lots of one-off features that won’t get support without a costly ongoing professional services contract just means your customizations will eventually break — either due to a device or hardware update or a platform one. It’s not “if,” it’s “when.”

‍