Top 5 IoT Platforms for Custom Development in 2026: A Pros/Cons Guide for Buyers and Builders

Key takeaways:

• The top picks in 2026 split by fit: AWS IoT Core (enterprise on AWS), Azure IoT Hub (Azure-first + network realities), ThingWorx (industrial IIoT), Particle (connected products + OTA), ThingsBoard (open-source + self-host control).
• Cloud platforms can sprawl in services/cost; ThingWorx is enterprise-licensed and specialized; Particle couples you to its ecosystem; open-source shifts ops and scaling to your team.
• Choose by constraints: data residency (US/EU), offline/edge needs, protocol/gateway requirements, and who will run the platform day-to-day.
• Plan for predictable failure modes: device identity chaos, no OTA discipline, alert fatigue, integration drag, and network/proxy constraints.

Platform selection is one of the most consequential decisions in a custom IoT project, yet it often receives less scrutiny than it deserves.

Most teams can establish connectivity and push telemetry within a week. The complexity surfaces later, as requirements expand to include safe firmware delivery across a fleet, tenant isolation, access-control auditing, and message-cost management at scale. These are the factors that determine whether a platform choice holds up in production, and they are rarely visible during a proof of concept.

There is also a stability dimension that belongs within the selection process. Google shut down Cloud IoT Core in August 2023. IBM Watson IoT Platform was discontinued in December of the same year. In both cases, teams that had built on those platforms were left to manage migrations they had neither planned nor budgeted for. Vendor longevity and operating model affect the long-term cost and risk profile of any system built on top of them.

This article reviews five platforms that remain strong candidates for custom IoT development in 2026. For each one, we cover what it is, where it performs well, and where its limitations become relevant.

How we evaluated platforms

We scored each platform against eight criteria that typically determine project outcomes in production:

1. Connectivity and protocol support: MQTT, HTTP, AMQP, and how the platform handles gateways and corporate network constraints.
2. Device lifecycle management:  provisioning, fleet management, and OTA update controls.
3. Data plane: ingestion capacity, routing and rules, storage patterns, and retention policies.
4. Security model: authentication, authorization, tenant isolation, and audit capabilities.
5. Integration cost: SDK and API quality, connector availability, eventing support, and documentation.
6. Edge and offline fit: local buffering, gateway patterns, and behavior under intermittent connectivity.
7. Operational load: observability tooling, debugging, scaling behavior, and incident response support.
8. Commercial fit: pricing predictability, vendor lock-in risk, and support model.

For US and EU deployments, we also considered data residency options and compliance posture, as these affect platform viability for regulated industries and multinational organizations.

AWS IoT Core

AWS IoT Core is a managed device gateway that provides rules-based message routing to the AWS service ecosystem. It supports publish/subscribe over MQTT and WebSockets, and publish-only over HTTPS. Its Rules Engine allows teams to filter and transform inbound data and route it to AWS services or external endpoints.

Why teams choose it

AWS IoT Core suits projects where the IoT layer is one component of a broader AWS architecture. Rather than imposing a fixed application model, it provides connectivity and routing primitives that teams assemble into their own pipeline. This composability is its primary advantage, and its primary challenge.

Pros

• Secure MQTT and WSS for publish/subscribe, with HTTPS available for publish-only scenarios where a persistent connection is not practical.
• SQL-like rule definitions in the Rules Engine allow teams to filter, transform, and route messages without additional middleware.
• Integrates directly with the broader AWS service catalog, making it a natural fit for teams that have already standardized on AWS for storage, analytics, and application hosting.

Cons

• Architecture sprawl is a consistent pattern in AWS IoT Core deployments. Teams rarely use IoT Core in isolation; the final system typically spans multiple AWS services, which increases both operational complexity and billing opacity.
• Lock-in accumulates in the data plane. The more a system relies on downstream managed AWS services, the more difficult migration becomes over time.

Best fit

Enterprise fleets and product companies that have already standardized on AWS, particularly where custom telemetry routing, multiple data consumers, and a mature cloud operating model are requirements.

Azure IoT Hub

Azure IoT Hub is a managed backend service for secure bidirectional communication between devices and the cloud. It supports HTTPS, AMQP (including over WebSockets), and MQTT (including over WebSockets). Microsoft publishes explicit guidance on protocol trade-offs, including latency, connection persistence, and scenarios where each protocol is the appropriate choice.

Why teams choose it

For organizations where identity management, governance, monitoring, and downstream applications already run on Azure, IoT Hub functions as a natural entry point for device connectivity. It fits into existing enterprise governance structures without requiring a separate operational model.

One consideration: corporate networks frequently block standard MQTT ports. Microsoft’s documentation explicitly states that MQTT over WebSockets on port 443 is a supported workaround. In B2B and enterprise deployments, this kind of network-layer guidance reflects real-world constraints that affect implementation timelines.

Pros

• Clear protocol documentation, including known limitations and recommended alternatives for each supported protocol.
• IoT Edge is available as a field gateway for protocol translation in environments where devices cannot communicate using native protocols.
• Published SLAs and documented quota limits support capacity planning and enterprise procurement processes.

Cons

• IoT Hub is a core component, not a complete platform. A production system requires additional Azure services for analytics, storage, routing, and monitoring.
• Cost estimation becomes non-trivial once the full service composition is taken into account.

Best fit

Enterprises standardized on Microsoft and Azure, particularly in environments where network constraints, firewalls, proxies, and restricted ports make WebSocket-based connectivity a requirement.

PTC ThingWorx

ThingWorx is an industrial IoT platform designed to support the transition from pilots to enterprise-scale deployments, with pre-built applications and developer tooling oriented toward manufacturing, service, and engineering use cases. It supports on-premises, cloud, and hybrid deployment models.

Why teams choose it

ThingWorx is built around industrial workflows rather than generic telemetry pipelines. For teams connecting industrial equipment, running operations dashboards, and translating sensor signals into service actions, a purpose-built IIoT platform reduces the amount of custom scaffolding required to reach a production-ready system.

Pros

• The platform’s application model is shaped around the manufacturing, service, and engineering domains, reducing development time when those use cases align with the platform’s assumptions.
• On-premises, cloud, and hybrid deployment flexibility is a core product feature, which matters for plant environments and regulated industries with data sovereignty requirements.
• When the platform’s structure matches the project domain, the path from pilot to production rollout is typically shorter than with general-purpose platforms.

Cons

• Enterprise licensing terms make ThingWorx a poor fit for small and mid-sized businesses.
• Teams require dedicated time to learn the ThingWorx application model and to integrate it with existing enterprise systems. Implementation typically requires specialized expertise.

Best fit

Industrial enterprises that need an IIoT platform structured around operational workflows, not just data ingestion and routing.

Particle

Particle is a connected-product platform with a strong emphasis on OTA firmware updates and fleet management. Its platform covers pushing IoT updates to individual devices or entire fleets, including application firmware, Device OS, and asset updates for other system components, with encryption and sender verification as standard features of the update process.

Why teams choose it

For connected product teams, the most common operational risks center on firmware delivery: the ability to ship fixes safely, roll back a failed update, and manage devices at scale without building custom tooling. Particle’s platform is organized around these concerns, treating OTA as a core system capability rather than a feature to be implemented separately.

Pros

• OTA updates and fleet-wide delivery controls are first-class platform features, not add-ons.
• A central console and REST API reduce the custom development burden for routine device operations.
• Encryption and sender verification are built into the OTA process by default.

Cons

• The platform’s value is tied to the integrated stack. Teams that require flexibility to swap components or migrate to other infrastructure will find portability limited.
• Unit economics can shift as fleet size grows. Many teams revisit their platform decision once per-device costs at scale become the dominant consideration.

Best fit

Startups and product teams that need reliable OTA and fleet operations from day one, without investing in building their own platform infrastructure.

ThingsBoard (open-source)

ThingsBoard is an open-source IoT platform covering device management, data collection, processing, visualization, and MQTT/CoAP/HTTP connectivity. It supports multi-tenancy and rule chains for telemetry processing and alarm triggering. ThingsBoard also provides an IoT Gateway with connectors for MQTT, OPC-UA, Modbus, and BLE, relevant for projects that need to bridge legacy IoT or industrial systems.

Why teams choose it

Some organizations require full control over their platform: data residency constraints, internal security policies, custom extension requirements, or a deliberate decision to avoid vendor dependency. ThingsBoard consolidates dashboards, rule processing, and device management into a single self-hostable stack, making it an open-source base for teams with the operational capacity to run it.

Pros

• Deployment is fully under the organization’s control, on-premises or cloud, with no vendor dependency on data storage or processing.
• Rule chains and alarm logic are built in, allowing teams to implement processing and alerting behavior without modifying the platform layer.
• Gateway connectors reduce integration complexity for industrial and legacy data sources.

Cons

• All operational responsibilities fall to the team: patching, monitoring, scaling, backup, and security hardening. This is a substantial ongoing commitment.
• Scaling ThingsBoard is achievable, but the architecture decisions and operational execution are the team’s responsibility.

Best fit

Teams that want an open-source foundation for a custom IoT platform and have, or can build, the DevOps and SRE capacity to operate it reliably.

Architecture of an IoT platform

An IoT platform is a layered system, and understanding which layers it covers and which it does not is essential to making a sound selection decision.

At the device layer, hardware falls into three broad categories: microcontrollers (MCUs) for constrained, low-power devices; microprocessor units (MPUs) for devices that require a full operating system; and server-class hardware for edge nodes with significant compute requirements. When devices cannot communicate directly with the cloud, a gateway handles protocol translation and forwards messages upstream.

The IoT cloud layer handles four core functions: device registry (a persistent record of enrolled devices and their metadata), device provisioning (the process of securely onboarding devices at scale), service APIs (the programmatic interface through which applications interact with the platform), and device updates (the mechanism for delivering firmware and configuration changes to devices in the field).

Message processing is the central hub of the platform. Inbound telemetry passes through enrichment logic before being routed to downstream consumers. The routing layer determines which messages go to storage, analytics pipelines, alerting systems, or external integrations.

Device management and control operate as a bidirectional channel. Commands and configuration updates flow from the platform to devices; status, acknowledgment, and diagnostic data flow back. This layer is what enables remote monitoring and actuation at scale.

The downstream cloud services that consume platform output: storage, analysis, visualization, and automation are provided either by the broader cloud ecosystem (as in AWS IoT Core and Azure IoT Hub, where teams assemble these services themselves) or built into the platform directly (as in ThingWorx).

Four cross-cutting concerns underpin all layers: security (authentication, authorization, encryption, and audit), solution management (configuration, versioning, and deployment tooling), high availability and disaster recovery (redundancy and failover design), and scalability.

Multi-tenant vs single-tenant deployment

The deployment model is one of the architectural decisions in an IoT platform. The choice between multi-tenant and single-tenant deployment affects how data is stored, how updates are managed, and how the platform scales, with direct consequences for cost and operational complexity.

Multi-tenant deployment

In a multi-tenant architecture, multiple organizations share the same underlying infrastructure and database. Tenant data is logically separated using identifiers and access control rules, rather than physically through dedicated infrastructure.

The primary advantage is cost efficiency. Shared infrastructure reduces per-tenant overhead for compute, storage, and operations. Updates are applied centrally, so all tenants benefit without individual action. ThingsBoard supports multi-tenancy as a core feature, allowing a single self-hosted deployment to serve multiple organizational units or customer accounts.

The trade-off is isolation. For organizations with strict data separation requirements, such as regulated industries, high-security environments, or customers with contractual isolation obligations, logical separation may not satisfy IoT compliance requirements.

Single-tenant deployment

In a single-tenant architecture, each organization runs on dedicated infrastructure with its own database. There is no shared layer between tenants at any level of the stack.

The isolation is complete by design. This model supports custom configurations that would not be practical in a shared environment and eliminates the risk of cross-tenant data exposure. For enterprise customers and industries with IoT regulatory requirements, single-tenant deployment is often a procurement requirement.

The cost is higher. Dedicated infrastructure means that compute, storage, and operational overhead scale with the number of tenants rather than being amortized across them. Updates must be applied to each environment individually.

Implications for platform selection

For SaaS products serving multiple end customers, the deployment model affects both platform architecture and commercial model. A multi-tenant foundation reduces infrastructure costs and simplifies operations, but requires careful access control design and limits tenant-specific customization.

For enterprise deployments where each customer requires dedicated infrastructure, single-tenant architecture aligns with expectations but increases cost and operational complexity. Teams evaluating platforms for this use case should verify whether the platform supports single-tenant deployment natively or requires custom implementation.

Comparison table

Platform	Best for	Strength	Primary compromise
AWS IoT Core	Enterprise on AWS	Protocol + routing primitives that compose well	Cost/complexity across a multi-service architecture
Azure IoT Hub	Azure-first enterprises	Device connectivity + documented protocol guidance	“Platform” is assembled from several services
PTC ThingWorx	Industrial enterprises	IIoT application enablement + flexible deployment story	Licensing + specialized implementation
Particle	Connected products	OTA + fleet operations treated as core platform capabilities	Ecosystem coupling; scale economics
ThingsBoard	Control/self-hosting	Open-source, multi-tenancy, rules, dashboards	Ops burden shifts to your team

Which platform fits your company?

If you’re an SMB or launching a product

You usually want to minimize platform work and ship value fast. Particle often wins here because OTA and device operations are part of the platform story. ThingsBoard can also fit if you need control and can operate a self-hosted stack.

If you’re an enterprise

The default is AWS or Azure because they fit enterprise cloud governance and scale. Industrial enterprises often consider ThingWorx when seeking an IIoT platform designed for industrial use cases and flexible deployment.

How to choose an IoT platform for your needs

Answer these questions to settle on which platform fits your needs best:

1. Where must the data live? If you need on-prem or EU residency by design, shortlist self-hosting or verify cloud-region constraints early.
2. How will you handle OTA updates and rollbacks? If you can’t update safely, your platform becomes a liability. Particle’s OTA model is a strong reference for what “serious OTA” looks like.
3. What’s your gateway story? If you have industrial protocols, you need a plan (field gateways, protocol translation, connectors). ThingsBoard Gateway lists OPC-UA/Modbus/BLE connectors as part of that bridge.
4. Who owns operations? If you can’t staff the operating model, deliberately choose managed components.
5. What is your exit plan? Even if you never leave, architecture choices should keep migration possible.

Why platform selection is only part of the work

Selecting the right IoT platform reduces risk and accelerates delivery. It doesn’t replace the engineering work required to turn a platform into a functioning product.

Once a platform is in place, the remaining work typically includes device onboarding flows, data normalization across heterogeneous sources, integrations with enterprise systems, dashboards and alerting logic, role-based access control, and the operating model that keeps the system running in production. The platform provides the infrastructure; the product requires everything built on top of it.

SumatoSoft has delivered more than 350 custom software solutions across 25+ countries, with a team composed of 70% senior engineers and a 98% client satisfaction rate. IoT engagements follow a consistent pattern: identify the platform that fits the project’s cloud governance requirements, industrial workflow needs, data residency obligations, and then build the product layer that makes it usable by the people who depend on it.

If your organization is evaluating platforms or has already selected one and needs a team to build on top of it, SumatoSoft can scope the engagement, define the architecture, and deliver the product. Get in touch to discuss your project.

FAQ

What is the best IoT platform for custom development in 2026?

If your enterprise is on AWS, AWS IoT Core is a standard choice for secure connectivity and rules-based routing. If you’re Azure-first, IoT Hub is a common equivalent with strong protocol support. If you need self-host control, ThingsBoard is an open-source base.

Which platform is best for industrial IoT?

ThingWorx is positioned specifically as an industrial IoT platform for manufacturing/service/engineering use cases, with deployment flexibility (on-prem/cloud/hybrid).

Which platform is best for a connected product that needs reliable OTA updates?

Particle’s documentation focuses heavily on OTA updates and fleet-wide delivery controls, including security measures for updates.

Is an open-source IoT platform a good idea for an enterprise?

It can be if you’re ready to operate it. ThingsBoard supports multi-tenancy and both cloud and on-prem deployments, but the operational responsibility is yours.