Top 5 .NET Use Cases in IoT Applications

IoT in 2026 has split into two halves: the device side (sensors, gateways, edge compute on ARM) and the cloud side (ingestion APIs, real-time dashboards, time-series storage, alerting). The .NET ecosystem covers both halves better than most teams realize — and most production IoT systems we audit run their cloud-side .NET workloads on traditional managed hosting alongside a separate edge stack.

This is the IoT use-case map we work from when architecting .NET-based connected-device systems. Five patterns, each with the cloud-side architecture that runs on Adaptive's ASP.NET Core hosting and an honest line on where the device-side / broker-side infrastructure has to live.

.NET 10LTS — current for

MQTTPrimary broker protocol

$9.49+Starting plan

The IoT stack, layered

Ingestion API, dashboard, alerts

ASP.NET Core APIs receiving device messages, Blazor admin dashboards, alerting workflows. Runs on managed Windows hosting.

🟡 Broker (separate)

MQTT / AMQP message broker

EMQX Cloud, HiveMQ, AWS IoT Core, Azure IoT Hub. Sits between devices and your ingestion API. Managed elsewhere.

📡 Edge (devices)

Sensors + gateways on ARM

.NET on Raspberry Pi / industrial gateways. Runs on the physical device. Not in AWH's scope.

Most production IoT systems we audit deploy these three layers independently — and that's the right architecture. Your Adaptive plan handles the cloud layer; the broker is a managed service; the edge runs on whatever hardware ships with the product.

Quick reference: five .NET IoT patterns

Sensor Telemetry Ingestion

Every IoT system needs a place for device data to land. The .NET cloud pattern: devices publish to an MQTT broker, your ASP.NET Core service subscribes, validates each message, and persists to SQL Server. Backpressure-safe, horizontally scalable.

// MQTTnet — the .NET MQTT client of choice in 2026

public class TelemetryIngestionWorker(IDeviceRepository devices, ILogger<TelemetryIngestionWorker> log)

: BackgroundService

{

private IMqttClient _mqtt = null!;

protected override async Task ExecuteAsync(CancellationToken stoppingToken)

{

_mqtt = new MqttClientFactory().CreateMqttClient();

var opts = new MqttClientOptionsBuilder()

.WithTcpServer("mqtt.emqxcloud.com", 8883)

.WithTlsOptions(new MqttClientTlsOptionsBuilder().UseTls().Build())

.WithCredentials(Env.MqttUser, Env.MqttPass)

.WithClientId($"awh-ingestor-{Environment.MachineName}")

.Build();

_mqtt.ApplicationMessageReceivedAsync += OnMessage;

await _mqtt.ConnectAsync(opts, stoppingToken);

await _mqtt.SubscribeAsync("devices/+/telemetry", MqttQualityOfServiceLevel.AtLeastOnce);

// Keep alive — the broker handles dispatch

await Task.Delay(Timeout.Infinite, stoppingToken);

}

private async Task OnMessage(MqttApplicationMessageReceivedEventArgs e)

{

try

{

var deviceId = e.ApplicationMessage.Topic.Split('/')[1];

var payload = JsonSerializer.Deserialize<TelemetryPayload>(e.ApplicationMessage.Payload);

if (payload is null) return;

await devices.RecordTelemetryAsync(deviceId, payload);

await e.AcknowledgeAsync(CancellationToken.None);

}

catch (Exception ex) { log.LogError(ex, "Ingest failed for topic {Topic}", e.ApplicationMessage.Topic); }

}

A single Adaptive ASP.NET Business plan ($17.49) with a 2 GB dedicated app pool comfortably ingests ~5,000 messages/second from MQTT — well above what most B2B IoT fleets generate. For larger fleets (10,000+ devices reporting per second), ASP.NET Professional ($27.49) with 4 GB headroom is the right starting point.

Real-Time Fleet Dashboards

Operations teams watching live device status — temperature, battery, last-seen, alert flags. Blazor Server's stateful circuit + SignalR backplane is purpose-built for this. Server pushes data as it arrives; the browser updates without a refresh.

@page "/fleet"

@inject IFleetService Fleet

@inject IHubContext<TelemetryHub> Hub

@implements IAsyncDisposable

<h1>Fleet status — @_devices.Count devices</h1>

@foreach (var d in _devices)

{

<p>Last seen: @d.LastSeen.ToShortTimeString()</p>

<p>Temp: @d.Temperature°C · Battery: @d.BatteryPercent%</p>

</div>

}

</div>

@code {

private List<DeviceState> _devices = new();

private IDisposable? _sub;

protected override async Task OnInitializedAsync()

{

_devices = await Fleet.GetAllDevicesAsync();

_sub = Fleet.OnDeviceUpdate.Subscribe(async u =>

{

var idx = _devices.FindIndex(d => d.Id == u.Id);

if (idx >= 0) { _devices[idx] = u; await InvokeAsync(StateHasChanged); }

});

}

public ValueTask DisposeAsync() { _sub?.Dispose(); return ValueTask.CompletedTask; }

}

The combination of Blazor Server's stateful circuit + SignalR's automatic reconnection + a Reactive observable on the server side produces a real-time UI with no custom WebSocket code, no polling, and no client-side state management library. For the broader Blazor enterprise pattern, see our enterprise Blazor use cases article (pattern #4 specifically covers real-time operations dashboards).

Edge Gateway Processing (Not on AWH)

.NET runs on ARM — Raspberry Pi, NVIDIA Jetson, industrial gateways like Moxa or Advantech. For latency-sensitive or bandwidth-constrained scenarios, pre-aggregating data at the edge before sending to cloud is the right answer. AWH doesn't host the edge devices themselves, but the cloud-side API receiving the aggregated rollups runs perfectly on managed Windows hosting.

// Edge gateway service on a Raspberry Pi running Ubuntu Server / .NET 10 LTS

public class EdgeAggregator(IMqttClient broker) : BackgroundService

{

private readonly Channel<Reading> _buffer =

Channel.CreateBounded<Reading>(new BoundedChannelOptions(10_000));

protected override async Task ExecuteAsync(CancellationToken ct)

{

// Aggregate to 1-minute windows before forwarding to cloud

var window = new List<Reading>();

var windowStart = DateTime.UtcNow;

await foreach (var reading in _buffer.Reader.ReadAllAsync(ct))

{

window.Add(reading);

if (DateTime.UtcNow - windowStart > TimeSpan.FromMinutes(1))

{

var rollup = new Rollup

{

DeviceId = window[0].DeviceId,

StartUtc = windowStart,

Min = window.Min(r => r.Value),

Max = window.Max(r => r.Value),

Avg = window.Average(r => r.Value),

SampleCount = window.Count

};

await broker.PublishAsync(BuildMessage("edge/rollups", rollup), ct);

window.Clear(); windowStart = DateTime.UtcNow;

}

The edge service publishes summary rollups to the same broker your AWH-hosted ingestion API subscribes to (strategy #1). Bandwidth at the edge drops by 60-100×; the cloud API processes thousands fewer messages while keeping full statistical fidelity.

Time-Series Storage + Anomaly Detection

Raw sensor telemetry hits a time-series database (InfluxDB, TimescaleDB, AWS Timestream). A periodic .NET background service runs anomaly-detection models against the recent window and writes alerts back to SQL Server for the dashboard:

public class AnomalyDetectionWorker(

ITimeSeriesClient ts, IAlertRepository alerts, MLContext ml) : BackgroundService

{

private ITransformer _model = null!;

protected override async Task ExecuteAsync(CancellationToken ct)

{

// ML.NET Spike detection — built-in time-series anomaly transformer

var pipeline = ml.Transforms.DetectIidSpike(

outputColumnName: "Prediction",

inputColumnName: "Value",

confidence: 95,

pvalueHistoryLength: 30);

_model = pipeline.Fit(ml.Data.LoadFromEnumerable(Array.Empty<TimePoint>()));

while (!ct.IsCancellationRequested)

{

foreach (var device in await alerts.GetMonitoredDevicesAsync(ct))

{

var window = await ts.QueryAsync(device.Id, DateTime.UtcNow.AddHours(-1), DateTime.UtcNow);

var preds = _model.Transform(ml.Data.LoadFromEnumerable(window));

var anomalies = ml.Data.CreateEnumerable<SpikeOutput>(preds, reuseRowObject: false)

.Where(p => p.Prediction[0] == 1).ToList();

foreach (var a in anomalies)

await alerts.CreateAsync(new Alert { DeviceId = device.Id, Detected = DateTime.UtcNow, Severity = "Anomaly" });

}

await Task.Delay(TimeSpan.FromMinutes(1), ct);

}

Anomaly detection runs inside your existing .NET service — no separate Python ML container, no inter-service auth, no extra deployment complexity. Single-millisecond inference on tabular sensor data; runs on any ASP.NET Core hosting tier with sufficient RAM headroom. We cover the broader ML.NET picture in our .NET cloud-native use cases article.

Over-the-Air Firmware Updates

OTA updates are the most-attacked surface in any IoT system. A compromised update channel = persistent attacker code on every device. Sign every firmware image, authenticate every device pulling the update, and version-pin to prevent downgrade attacks.

The cloud-side update orchestration runs as an authenticated ASP.NET Core API:

app.MapGet("/api/devices/{id}/firmware/check", async (

string id, IDeviceRepo devices, IFirmwareRepo fw, HttpContext ctx) =>

{

// 1. Device certificate auth at the TLS layer (mTLS preferred)

var deviceCert = await ctx.Connection.GetClientCertificateAsync();

if (deviceCert is null) return Results.Unauthorized();

// 2. Look up device, verify cert thumbprint matches

var device = await devices.GetByCertAsync(deviceCert.Thumbprint);

if (device is null || device.Id != id) return Results.Forbid();

// 3. Check current vs available firmware

var available = await fw.GetLatestForChannelAsync(device.UpdateChannel, device.HardwareRev);

if (available is null || available.Version <= device.CurrentFirmwareVersion)

return Results.NoContent();

// 4. Return a SHORT-LIVED, signed download URL — not the binary itself

var signedUrl = fw.SignDownloadUrl(available.BlobPath, TimeSpan.FromMinutes(15));

return Results.Ok(new {

version = available.Version,

sha256 = available.Sha256,

signature = available.Ed25519Signature,

downloadUrl = signedUrl

});

})

.RequireAuthorization()

.RequireRateLimiting("perDevice");

The firmware blob lives in object storage; the API only returns a signed download URL with a short TTL. The device verifies the Ed25519 signature against the public key it shipped with — supply-chain compromise of your build server alone is insufficient to push malicious firmware. Pair with the broader supply-chain controls covered in our API security strategies article (strategy #10).

Reference architecture

Production readiness checklist

✅ Ingestion Pipeline

MQTT QoS 1 (AtLeastOnce) for telemetry

Dead-letter queue for poison messages

Backpressure handling — bounded channels

Idempotency via device-side sequence numbers

✅ Time-Series Storage

Hot data (24h) in fast store

Warm data (30d) in time-series DB

Cold data (1y+) in object storage

Retention policy automated, not manual

✅ OTA Firmware

Ed25519 signatures on every binary

Staged rollout: 1% → 10% → 100%

Rollback path verified before release

Telemetry-driven health checks before promoting

Hosting-Layer Capabilities Adaptive Provides

NeedWhat's Included

ASP.NET Core runtime.NET 8 LTS, .NET 10 LTS for modern features

DatabaseReal SQL Server 2022 — Always Encrypted, ledger tables, Query Store

Background workersIHostedService support + Plesk scheduled tasks for cron-style triggers

NetworkFREE SSL, TLS 1.3, WAF + DDoS protection on every plan

IsolationDedicated IIS Application Pools per site (1–4 GB by tier)

What you bringMQTT broker (EMQX, HiveMQ, AWS IoT Core), object storage (S3, Azure Blob), edge device fleet

InfrastructureAWS US-East data center, 99.99% uptime SLA, 30-day money-back guarantee

Choose a plan

$9.49/mo

Pilot deployments + dev environments. ~1,000 devices reporting per minute. Real SQL Server, 1 GB app pool.

View Developer plan →

Popular

ASP.NET Business

$17.49/mo

Production fleets up to ~5,000 messages/sec. 2 GB app pool, WAF, SQL Server 2022 with Always Encrypted.

View Business plan →

ASP.NET Professional

$27.49/mo

Multi-tenant device fleets, agencies with multiple IoT products. 4 GB app pool, 10 sites, 200 GB storage.

View Professional plan →

Frequently Asked Questions

Can I host an MQTT broker on Adaptive's Windows hosting?

Not directly — Adaptive's managed Windows hosting is optimized for IIS + ASP.NET Core, not for custom long-lived broker daemons. Use a managed broker (EMQX Cloud, HiveMQ Cloud, AWS IoT Core, Azure IoT Hub) and connect to it from your AWH-hosted ASP.NET Core service. This is the standard production IoT pattern in 2026 — the broker is a managed dependency, not infrastructure you operate.

What's the right .NET runtime for IoT edge devices?

.NET 10 LTS with Native AOT for ARM. A typical edge service compiles to a 15-25 MB self-contained binary with sub-100 ms cold start — fits comfortably on Raspberry Pi 4, NVIDIA Jetson Nano, and most industrial gateways. For longer support windows, .NET 8 LTS is still maintained through November 2026.

How does Blazor Server compare to a separate SPA + API for IoT dashboards?

For internal ops teams (bounded user count, auth-walled, data-heavy), Blazor Server is the lower-friction choice — same C# end to end, real-time updates via SignalR, no separate JS build pipeline. For public-facing customer dashboards, a Blazor Auto setup (covered in our enterprise Blazor patterns article) handles the SEO-aware public surface plus the authenticated dashboard in one project.

How do I handle 100,000+ devices reporting per minute?

Three things: (1) push aggregation to the edge — devices report raw at high frequency, edge gateways aggregate to 1-minute rollups before forwarding cloud-ward; (2) use a managed broker designed for scale (EMQX Cloud, AWS IoT Core both handle millions of devices); (3) partition your ingestion service by device-ID prefix so each instance owns a slice. At that scale, also consider Azure Stream Analytics or AWS Kinesis for the windowed-aggregation step.

What anomaly-detection libraries work with .NET?

ML.NET ships time-series anomaly detection (Spike + Change Point detectors) for the common cases. For richer scenarios — multivariate, deep-learning-based, custom loss functions — train in PyTorch / TensorFlow and export ONNX; load and infer in .NET via the ONNX runtime. We cover the broader ML.NET picture in our .NET cloud-native use cases article.

Are there compliance requirements specific to IoT in 2026?

For consumer IoT in the EU: the Cyber Resilience Act starts enforcing across 2026 — requires secure-by-default device shipping, vulnerability disclosure programs, and update lifecycle commitments. For industrial IoT: IEC 62443 still the dominant framework. Our API security article covers the API-layer baseline; for device-side compliance, the device vendor / OS publisher is your starting point.

How do I migrate an older "ASP.NET Web Forms IoT dashboard" to modern .NET?

The shortest path: rewrite the dashboard as Blazor Server, keep the database schema, swap the data-access layer to EF Core. For the broader .NET Framework → .NET 10 LTS migration, our migration guide walks through the compatibility audit, code changes, and deployment side-by-side approach.

What about industrial protocols beyond MQTT — Modbus, OPC UA?

.NET has mature libraries for both: NModbus for Modbus TCP/RTU, the OPC Foundation OPC UA .NET Standard library for OPC UA client/server. Edge gateways typically translate from these industrial protocols to MQTT for the cloud handoff; the cloud-side .NET service speaks MQTT only.

Bottom line

The cloud side of every successful .NET IoT system in 2026 looks remarkably similar: an MQTT-fronted ingestion API, a SQL Server / time-series storage split, real-time Blazor dashboards, ML.NET anomaly detection, and a hardened OTA update service. Four of the five patterns above run cleanly on managed Windows hosting; only the edge devices live on different infrastructure (where they should — they're physical hardware running near the sensors).

On Adaptive Web Hosting, the cloud-tier IoT primitives — modern .NET runtimes, real SQL Server 2022 with Always Encrypted, dedicated IIS Application Pools, WAF + DDoS, FREE SSL, and post-quantum-ready TLS on .NET 10 LTS — are included on every tier. ASP.NET Developer ($9.49/mo) for pilots, ASP.NET Business ($17.49/mo) for typical production fleets, ASP.NET Professional ($27.49/mo) for multi-product or agency deployments. Every plan ships with a 30-day money-back guarantee.

If you're building the dashboard layer in Blazor, our enterprise Blazor patterns covers the patterns. If you're securing the cloud API, the ASP.NET Core API security strategies applies directly. View all plans or talk to an IoT engineer about a specific architecture.