Skip to main content
Part of: IoT Platforms & Cloud
Cloud · 6 min read

Azure IoT Hub vs IoT Central: When to Pick Each

A practical comparison of Azure IoT Hub and Azure IoT Central in 2026 — when the managed Central experience wins, when raw Hub is the right call.

Microsoft offers two flavours of managed IoT platform: IoT Hub (the lower-level building block) and IoT Central (the application platform built on top of Hub). They look like a choice; in practice, the right one depends on how much of the application you want to operate yourself.

The shape of each

Azure IoT Hub is the message broker, device registry, and twin store. It does the protocol heavy lifting — MQTT, AMQP, HTTPS — and exposes them via SDKs in every common language. Everything around it (UI, dashboards, business logic, alerting) you build yourself.

Azure IoT Central is a full-stack IoT application platform. UI, device management dashboard, dashboards, rules, data export — all included. Behind the scenes it runs on IoT Hub, but you don’t see Hub directly.

A useful framing: IoT Hub is the engine, IoT Central is the car.

Pick IoT Central when

  • The product is conventional — sensor telemetry, device commands, threshold alerts, fleet dashboards — and the customer doesn’t need a custom UI
  • The team is small and operating a custom IoT application is more burden than benefit
  • Time-to-market matters more than long-term cost optimisation
  • The customer is comfortable with Microsoft’s UX patterns and doesn’t need bespoke styling
  • Data export to Power BI or Synapse is the BI integration story (Central makes this seamless)

Common applications: industrial monitoring with standard dashboards, B2B IoT products where the customer-facing UI is secondary, internal-tool IoT products.

Pick IoT Hub when

  • The product needs a custom application UI (your branded customer experience, complex workflows, integrations beyond what Central offers)
  • The team has the engineering capacity to build the application layer
  • Long-term cost optimisation matters (Hub is cheaper at scale than Central’s per-device pricing)
  • You need protocols, integrations, or features Central does not expose
  • You want the option to build features Central is opinionated against

Common applications: white-label IoT platforms, products where the UI is the differentiator, large fleets where Central’s per-device pricing becomes uneconomic.

The cost crossover

A rough rule:

  • Under 10,000 devices: Central is competitive. Per-device pricing is reasonable; included features cover most needs.
  • 10,000 – 100,000 devices: crossover zone. Central’s per-device fees start to add up, but the engineering cost of building Hub-based custom equivalents is real.
  • Above 100,000 devices: Hub almost always wins on cost, even with the additional engineering investment.

Check the current Azure IoT Central pricing — Microsoft adjusts it periodically and the crossover point moves.

DPS — the under-appreciated ingredient

Both Hub and Central rely on Azure Device Provisioning Service (DPS) for zero-touch onboarding. DPS is excellent and worth understanding regardless of which platform you pick:

  • Devices come pre-loaded with a bootstrap certificate (or TPM-attested identity)
  • On first power-on, devices contact DPS, which authenticates them and assigns them to a target IoT Hub
  • Multi-Hub assignment rules allow load balancing, regional steering, customer-specific Hub selection
  • Re-provisioning supported via custom allocation policies

DPS is the right answer for any production IoT deployment on Azure with more than ~1,000 devices. Skipping it and writing your own provisioning is rarely worth it.

For broader provisioning patterns see our IoT provisioning post.

IoT Edge — the optional but powerful piece

Azure IoT Edge runs on Linux gateways (or Windows IoT Enterprise) and lets you push container-based workloads to devices. Comparable to AWS Greengrass; arguably cleaner in some respects.

Pick IoT Edge when:

  • You have a Linux gateway with meaningful compute (NUC-class or above)
  • Workloads include ML inference, video analytics, or local rule processing
  • Component-based deployment via Microsoft Container Registry fits your CI/CD

Skip IoT Edge when:

  • Devices are tiny (microcontrollers — IoT Edge needs Linux)
  • Connectivity is reliable and edge logic is minimal

The integration story

Azure’s IoT integration story shines when you’re already on the Microsoft enterprise stack:

  • Power BI for dashboards (Central exports here natively; Hub via Stream Analytics or Synapse)
  • Synapse Analytics / Fabric for data warehouse / lakehouse
  • Sentinel for security monitoring
  • Defender for IoT for fleet-wide threat detection (see our IoT security platforms post)
  • Logic Apps / Power Automate for low-code workflows
  • Dynamics 365 for service-management integration (work orders from IoT events)

If the customer is already buying these — particularly E5-tier M365 — the Azure IoT integration cost is small relative to the rest of the stack.

What we typically recommend

For a startup or first-IoT-product team in 2026: start on IoT Central. Ship in weeks, not quarters. Migrate to Hub later if and when scale or custom-UI needs justify it.

For an enterprise customer already on the Microsoft stack: IoT Hub if there’s a custom application; IoT Central if a standard dashboard is sufficient.

For a team committed to building a long-running IoT product platform with a branded UI: IoT Hub from the start. The migration cost from Central to Hub at scale is real; building on Hub first avoids it.

What we hand over

For an Azure IoT engagement we ship:

  • The Hub vs Central decision documented with rationale
  • Bicep or Terraform for the chosen architecture
  • DPS configuration and bootstrap-cert lifecycle
  • Application architecture (Functions, Container Apps, App Service) sized to fleet
  • Cost projection at 1k, 10k, and 100k devices
  • Migration playbook for any future Central → Hub transition

If you are weighing Hub vs Central — or running into Central’s limits and wondering if it’s time to migrate — we have shipped both architectures.

By Diglogic Engineering · May 9, 2026

Share

Ready to ship

Let's get started.

Tell us about the problem. We come back within one business day with a clear path, a timeline you can plan around, and a fixed-scope first milestone.