Azure IoT Hub vs IoT Central: When to Pick Each

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.

Quick orientation

Azure IoT Hub is the engine — message broker, device registry, and twin store — with the application layer (UI, dashboards, business logic) built by you. Best when the product needs a custom application UI, the team has capacity to build it, or long-term cost optimisation at scale matters more than speed.

Azure IoT Central is the car built on top of Hub — UI, device management, dashboards, rules, and data export included out of the box. Best when the product is conventional (telemetry, commands, threshold alerts), the team is small, time-to-market outweighs long-term cost tuning, and Power BI/Synapse export covers the BI need.

Platform	What you build	Pricing model	Best-fit team size	Standout feature
Azure IoT Hub	Full application layer (UI, dashboards, logic) yourself	Cheaper at scale — no per-device app-layer fee	Larger teams with engineering capacity to build the app layer	Full control — no platform ceiling on custom features
Azure IoT Central	Nothing extra — UI, dashboards, rules, data export included	Per-device pricing, competitive under ~10,000 devices	Small teams, fast time-to-market	Native Power BI / Synapse data export

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.