What to Look for in an Industrial IoT Device Before You Buy

In late 2023, CISA documented at least 75 compromised Unitronics PLCs across the U.S. water sector. Default passwords. Direct internet exposure. No segmentation. The devices worked fine until an adversary decided they shouldn’t. This incident highlights the security challenges facing IoT-based equipment for municipalities, where critical infrastructure often runs on connected devices with inadequate protection.

That’s the headline failure. The quiet version is more common: a device that passes the demo, survives the pilot, then turns into an orphan. Firmware goes end-of-life two years in. The cloud platform shuts down. The battery lasts 14 months instead of the quoted five years because nobody tested it at the actual reporting rate and ambient temperature.

Knowing what to look for in an industrial IoT device means looking past the spec sheet. The real question is whether that device survives the actual installation, integrates with your existing systems, stays secure through its operating life, and can be replaced without rebuilding from scratch. After 15+ years deploying IoT in environments from aviation MRO facilities to container terminals, here’s the evaluation framework I use.

Start with the Failure Mode, Not the Feature List

Before you evaluate a single vendor, write down one sentence: what physical condition are you trying to detect, and what happens if you miss it?

That sounds obvious. It isn’t. I’ve watched procurement teams request quotes for “an IIoT sensor” before they’ve defined what they need to measure, at what accuracy, with what response time, or who acts on the alert. The result is hardware that collects data nobody uses. Or worse, data too noisy to be actionable.

At Siemens’ Amberg electronics plant, edge analytics for milling-spindle health don’t rely on new exotic sensors. They use existing rotational speed and drive current data already available from the machine. A gateway and an edge application turned signals that were being ignored into a predictive-maintenance workflow.

The lesson: the most useful industrial IoT device might be one that extracts value from signals you already have. Before adding a sensor, ask whether a gateway or edge computer could acquire existing process data from your PLCs or instruments.

A quick use-case specification should cover:

• Asset and failure mode you’re targeting
• Physical variable to measure (temperature, vibration, current, position, humidity)
• Required accuracy, range, and response time
• Who acts on the data, and how fast
• Installation environment: indoor/outdoor, temperature extremes, chemical exposure, wash-down requirements
• Existing interfaces available (Ethernet, serial, CAN, analog I/O)
• Expected device lifetime in the field

This document becomes your filter. Every hardware candidate either meets these requirements or doesn’t. Features beyond them are nice-to-haves, not selection criteria.

Survival Means More Than an IP Rating

An IP67 rating tells you the enclosure resists dust ingress and temporary water immersion. It does not tell you the device survives vibration, salt-fog corrosion, chemical splash, electrical interference, or explosive atmospheres. NEMA explicitly states that an IEC IP rating is not equivalent to a NEMA enclosure Type, because NEMA Types include requirements beyond ingress protection and assume a fully installed, ready-for-use enclosure.

This distinction matters more than most spec sheets suggest. In our own deployments, I’ve seen devices rated IP65 fail within weeks in a maritime container yard because salt-fog corrosion ate through connector seals the IP test never covered.

What to request instead:

• The actual test standard, severity level, and pass criteria for vibration. IEC 60068-2-6 specifies sinusoidal vibration testing, but severity varies dramatically across applications. Just printing “IEC 60068” on a brochure doesn’t tell you the tested g-force or frequency range.
• Corrosion resistance data relevant to your environment (salt spray hours, chemical compatibility, UV exposure).
• EMC test reports showing the device operates correctly near motors, variable-frequency drives, or welding equipment.
• For hazardous locations: OSHA requires equipment approved for the specific location classification, with correct class, group, and temperature markings. A weatherproof enclosure is not a substitute for a hazloc approval.

Installation details can defeat even a well-rated device. Siemens’ own IOT2050 operating manual specifies indoor operation with at least 50 mm clearance above and below the unit. Compact form factor does not mean “mount anywhere.”

The rule: test the assembled installation (device, connectors, cables, mounting bracket) in the actual operating environment. Bench-test survival is necessary but insufficient.

Match Connectivity to the Workload

Protocol selection is where I see the most expensive mistakes. Someone reads that MQTT is “the IoT standard” and specifies it for everything, without asking whether their PLCs speak Modbus, their SCADA expects OPC, or their reporting requirements demand timing guarantees that publish/subscribe alone doesn’t provide.

When evaluating industrial IoT solutions, treat connectivity as four separate decisions:

1. Physical/electrical interface (Ethernet, serial, CAN, analog, wireless radio)
2. Network transport (cellular, Wi-Fi, private 5G, LoRaWAN, wired Ethernet)
3. Application protocol (OPC UA, MQTT, Modbus TCP, HTTP/REST)
4. Data model and semantics (how values are named, timestamped, and interpreted by the receiving system)

OPC UA provides cross-vendor semantic interoperability: it defines not just how data moves, but what the data means. Sparkplug adds topic structure, payload format, and birth/death session-state conventions to MQTT for industrial use. These are complementary, not competing. OPC UA can itself use MQTT for transport, which means “OPC UA versus MQTT” is often the wrong framing entirely.

For wireless, the real question isn’t “5G or Wi-Fi?” It’s: does the device need mobility? Long range at low power? High bandwidth? What happens during a handover or a coverage gap? 5G-ACIA describes millisecond-level URLLC use cases for demanding industrial applications, but an advertised radio capability is not the same as measured performance in your plant, with your interference sources, at your scale.

One timing distinction trips up many teams: sampling interval, reporting interval, and decision latency are three different numbers. A sensor sampling at 100 Hz but reporting every 60 seconds through a congested gateway, then waiting for a cloud round-trip before an operator sees the alert, might have a decision latency measured in minutes. If safety or process control depends on that signal, map the full timing chain from measurement to action.

Make Security Demonstrable, Not Assumed

The Unitronics incident wasn’t a sophisticated nation-state attack. Actors accessed internet-exposed PLCs using default credentials. They altered device configurations and erased original ladder logic. At least 34 of the 75+ compromised devices were in U.S. water systems.

That’s what “insecure by default” looks like in the field. And it’s not limited to legacy controllers. Any industrial IoT device with a network interface, a management console, or a firmware update mechanism is a potential entry point.

NISTIR 8259A defines six foundational cybersecurity capabilities every IoT device should support. I turn each one into an acceptance test:

Beyond these six, ask for a Software Bill of Materials (SBOM), a documented vulnerability disclosure process, and clear patch timelines. If the vendor holds ISA/IEC 62443 certification, verify the scope. A 4-1 certificate covers the development lifecycle process. A 4-2 certificate covers technical component security requirements. They’re not interchangeable, and neither one tells you whether the specific firmware version you’re deploying was the one actually assessed.

Patching in OT environments carries its own risk. NIST’s OT security guide recommends testing, regression analysis, and maintenance-window planning before deploying patches to production systems. Rapid vulnerability response and controlled OT change management have to coexist. A vendor that pushes automatic updates without your approval is solving one problem while creating another.

Price the Decade, Not the Purchase Order

The unit price of an industrial IoT device is typically a fraction of what it costs to own. The real number includes installation labor, network integration, cellular or satellite connectivity, platform licensing (often per-endpoint, per-month), calibration schedules, battery replacements, firmware maintenance, field-swap logistics, and eventually, decommissioning and data migration.

A useful planning equation:

Lifecycle cost = hardware + installation + integration + connectivity + software/cloud + security maintenance + calibration + replacements + downtime risk + migration and decommissioning

Two concrete examples of why this matters:

Some IIoT gateway datasheets list different OS end-of-life dates by configuration — for example, 2027 for one software variant and 2031 for another on the same product family. The same document may advertise operating temperatures of -40 to 85°C in one section and -40 to 70°C with LTE enabled in another. A procurement team selecting the headline temperature spec without checking the LTE-specific limit could deploy a device that overheats under its actual radio workload. Match the exact SKU and configuration to the exact spec, not the product family brochure.

CISA’s IoT acquisition guidance recommends requiring at least five years of regular security patches from contract start. That’s a useful floor. But if your infrastructure lifecycle runs 10 or 15 years (common in aviation, energy, and maritime operations), negotiate accordingly or budget for a planned mid-life hardware refresh.

Battery-powered devices deserve extra scrutiny. The quoted battery life usually assumes a favorable reporting interval, strong signal quality, and moderate ambient temperature. Change any one variable, and the number changes with it. A tracker quoted at “5 years” under ideal conditions might last 18 months when reporting every 15 minutes in a poor-signal, high-temperature environment. Request the exact assumptions behind the claim, then validate under your actual operating profile.

The broader spending trend reinforces this point. IoT Analytics reported that in 2024, IoT-related cloud infrastructure spending grew 22% and SaaS grew 21%, while controller and gateway hardware spending declined 8%. The recurring software and platform costs are where the money goes. A cheap device with expensive subscriptions is not a bargain.

Plan Your Exit Before You Deploy

In August 2023, Google discontinued IoT Core. Every device feeding data through that platform needed a migration path. Some organizations had one. Many scrambled.

This is not an anomaly. Cloud services evolve, get acquired, change pricing, or shut down. If your device’s functionality depends on a vendor’s platform, you need two things proven before deployment: the device retains local operation without cloud connectivity, and a documented migration path exists for your data, configuration, and device management.

Since September 2026, the EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities within 24 hours and provide fuller notification within 72 hours. For buyers, this creates a concrete procurement question: does your supplier have a functioning incident-response and customer-notification process today? Not a compliance roadmap for next year. A working process, right now.

A 2026 CISA advisory on ABB AWIN gateways illustrates why fleet-level firmware visibility matters. The advisory identified specific vulnerable firmware versions and corrected alternatives. Organizations that could map their deployed firmware to the advisory acted fast. Those running untracked versions could not.

True interoperability ties into this: it means your data, configuration, and operational history can move to another platform or device without loss. A vendor claiming “open standards” while locking your historical data behind a proprietary dashboard isn’t interoperable. It’s connected, which is a different thing.

Test this before you commit: can you export all historical data in a standard, machine-readable format? Can a replacement device from a different manufacturer connect to your infrastructure without rebuilding integrations? If the answer is no, you’re buying a dependency, not a device.

Test Failure Recovery, Not Just Functionality

Most pilot deployments prove a device works under normal conditions. That’s the easy part. The test that actually predicts long-term success is failure recovery.

Disconnect the network. Fill the local buffer. Kill power. Restore everything. Did the device reconnect automatically? Did buffered data arrive intact and in order? Did alarms fire correctly during the outage? Did the system distinguish between a stale reading and a live one?

Then test security: attempt unauthorized access through every exposed interface. Push an unsigned firmware image. Try to extract stored credentials from a physically captured device. If any of those tests succeed, no feature list compensates.

Test integration with your actual systems, not the vendor’s demo environment. Demonstrate communication with the installed PLC, the existing SCADA, the actual Wi-Fi or cellular infrastructure with its real-world interference sources. A clean dashboard on the vendor’s bench has almost zero predictive value for your plant floor, your port yard, or your fleet on the road.

Schneider Electric’s results at their Lexington plant (26% lower energy use, 20% equipment-downtime reduction) came from an integrated system: connected meters feeding analytics, feeding workflows, feeding operational decisions made by teams. Not from a single device on a shelf. Those are vendor-reported outcomes across a broader modernization program. The lesson for your own acceptance test: define success as an operational outcome, not a hardware functionality check.

In asset tracking, this principle is especially sharp. The device that reports position perfectly during a pilot around the warehouse may go silent once it’s inside a steel container at sea, or stacked between ULDs on a tarmac. The operating environment for a tracker isn’t the friendly demo loop. It’s months of vibration, temperature swings, poor signal conditions, and no human intervention. If you’re evaluating devices for those conditions, our asset tracking device catalog includes hardware we’ve tested and deployed in exactly those scenarios.

Frequently Asked Questions

What makes an IoT device “industrial” versus consumer-grade?

No single label settles it. Look for environmental and electrical suitability for your specific installation (temperature range, vibration profile, ingress, EMC), maintainable firmware with a defined support lifecycle, reliable integration with OT systems, and security capabilities you can verify. An IP rating or the word “industrial” on the box proves only part of the picture.

Should I buy a smart sensor, gateway, or edge computer?

Buy the role your use case requires. If useful signals already exist in your equipment (drive current, spindle speed, process temperatures), a gateway or edge application may deliver more value than a new sensor. If the physical variable isn’t measured at all, you need the sensor first. Define the signal and the required response before selecting the compute platform.

Does MQTT support guarantee interoperability between devices?

No. MQTT defines a transport mechanism, not data semantics. Two devices can both publish and subscribe without understanding each other’s payloads at all. Sparkplug adds topic structure, payload format, and session-state conventions. OPC UA addresses semantic interoperability at a deeper level. Verify that devices actually interpret each other’s data correctly, not just that both claim MQTT support.

How long should vendor support last for an industrial IoT device?

CISA recommends at least five years of security patches from contract start as a procurement baseline. For assets with 10-15 year lifecycles (typical in aviation, energy, maritime), negotiate longer support or plan a mid-life device refresh. Always verify the exact firmware and OS end-of-life dates for your purchased configuration, not the product-family headline.

Can an industrial IoT device keep working when the cloud goes down?

It should. Define which alarms, measurements, control functions, and data buffers must remain available offline. Then test by actually disconnecting the cloud connection and verifying those functions. Google IoT Core’s 2023 discontinuation showed that entire device fleets can lose functionality when a platform disappears. Local continuity isn’t optional.

Does every device need AI or edge computing capabilities?

No. Cisco’s 2026 industrial AI survey found 51% of decision-makers expect greater connectivity and reliability requirements to support AI workloads, and 44% need more edge capacity. That means the infrastructure around the device needs to accommodate AI where it’s justified. It does not mean every sensor or tracker needs a GPU. Budget the system architecture, not just the endpoint.

If your team is scoping industrial IoT devices for asset tracking, environmental monitoring, or fleet visibility across tough operating environments, we’re happy to talk through requirements. That’s what we do. info@datanetiot.com