Skip to main content

Device Provisioning and Authentication for Industrial IoT Gateways: SAS Tokens, Certificates, and Auto-Reconnection [2026]

· 13 min read

Every industrial edge gateway faces the same fundamental challenge: prove its identity to a cloud platform, establish a secure connection, and keep that connection alive for months or years — all while running on hardware with limited memory, intermittent connectivity, and no IT staff on-site to rotate credentials.

Getting authentication wrong doesn't just mean lost telemetry. It means a factory floor device that silently stops reporting, burning through its local buffer until data is permanently lost. Or worse — an improperly secured device that becomes an entry point into an OT network.

This guide covers the practical reality of device provisioning, from the first boot through ongoing credential management, with patterns drawn from production deployments across thousands of industrial gateways.

The Authentication Landscape for Industrial IoT​

Industrial gateways typically authenticate to cloud platforms using one of three methods:

1. Shared Access Signatures (SAS Tokens)​

A SAS token is a signed URL string that grants time-limited access to a specific resource. It contains the device identity, an expiration timestamp, and an HMAC-SHA256 signature generated from a shared key.

Anatomy of an industrial SAS token:

SharedAccessSignature sr={hub-hostname}%2Fdevices%2F{device-id}
  &sig={signature-base64}
  &se={expiry-unix-timestamp}

The three critical components:

  • sr (resource): The IoT Hub hostname and device path — this scopes the token to a single device on a single hub
  • sig (signature): Base64-encoded HMAC-SHA256 of the resource URI and expiry, signed with the device's symmetric key
  • se (expiry): Unix timestamp after which the token is rejected

Why SAS tokens dominate industrial deployments:

They're stateless and computationally cheap. A gateway with 64 MB of RAM and a 400 MHz processor can generate and validate SAS tokens without a TLS certificate store, without a PKI hierarchy, and without complex key rotation ceremonies. The token is just a string that goes into the MQTT username/password fields.

The expiration problem:

SAS tokens expire. This is a feature (limits blast radius of a leaked token) and a headache (gateway must detect expiration and re-authenticate). A token with se=1709500800 is valid until March 3, 2026 at midnight UTC. One second later, the broker rejects it.

If your gateway doesn't monitor token expiration, here's what happens:

  1. Token expires at midnight
  2. Gateway's existing MQTT connection may stay alive (brokers don't always terminate active connections at token expiry)
  3. If the connection drops for any reason, the gateway tries to reconnect
  4. Reconnection fails — broker rejects the expired token
  5. Gateway enters infinite reconnect loop, buffering data locally
  6. Buffer fills up, oldest data is overwritten
  7. Nobody notices for hours or days

2. X.509 Certificates​

The gateway presents an X.509 client certificate during the TLS handshake. The broker validates the certificate chain against its trusted CA. No passwords, no tokens — identity is cryptographic.

Advantages:

  • No expiration watchdog needed (certificates have long validity periods, typically 1-2 years)
  • Mutual authentication — the gateway also validates the broker's certificate
  • Stronger security posture — no shared secrets to leak

Disadvantages for industrial:

  • Certificate provisioning requires PKI infrastructure
  • Embedded devices with limited flash storage struggle with full certificate chains
  • Certificate renewal on devices in remote locations (oil fields, rural water treatment) is operationally expensive
  • Clock drift on devices without NTP can cause valid certificates to appear expired

3. CA-Signed Certificates with Device Provisioning Service​

A middle ground: the device ships with a manufacturer CA certificate. On first boot, it contacts a provisioning service, proves possession of its private key, and receives its hub assignment and credentials. This is the "zero-touch provisioning" ideal, but requires a provisioning infrastructure that many industrial deployments lack.

Token Expiration Watchdog — A Critical Design Pattern​

The most common authentication failure in production gateways isn't a security breach — it's a silently expired token. Here's how a robust watchdog works:

Step 1: Parse the Expiration Timestamp​

When the gateway loads its cloud configuration, it must extract and store the se value:

Configuration string:
  HostName=hub.azure-devices.net;DeviceId=22091017;
  SharedAccessSignature=...&se=1919084885

Parsed expiration: 1919084885 (Unix timestamp)

The gateway stores this timestamp in its runtime context and checks it against the system clock on every connection attempt.

Step 2: Compare Against System Time​

Before initiating or renewing an MQTT connection:

current_time = time(NULL)  // e.g., 1709500800

if (current_time > token_expiration) {
    log_warning("AZURE token might be outdated!")
    log_warning("  se: %llu (%s)", token_expiration, ctime(token_expiration))
    log_warning("  now: %llu (%s)", current_time, ctime(current_time))
} else {
    log_notice("AZURE token ok: %llu (%s)", token_expiration, ctime(token_expiration))
}

This check runs every time the configuration is loaded or the MQTT client is restarted. The warning is unmistakable in the system log.

Step 3: Handle Clock Uncertainty​

Industrial gateways often run without reliable NTP. A cellular gateway in a remote factory might boot with its hardware clock months behind. Your watchdog must account for this:

  • If system time is before the token creation date, the clock is probably wrong — proceed with caution but allow connection
  • If system time is significantly past expiration (weeks, not seconds), log an error and alert
  • Consider embedding the token creation timestamp alongside the expiry to establish a validity window

Step 4: Proactive Renewal​

Don't wait for the token to expire. Set a renewal threshold — if the token expires within 7 days, begin the renewal process:

  1. Generate a new SAS token with an updated expiry
  2. Write the new configuration file
  3. The gateway detects the file modification (comparing stat.st_mtime)
  4. MQTT client is gracefully restarted with new credentials
  5. No data loss — the buffer holds telemetry during the brief reconnection

The Configuration File Watchdog​

A production-grade gateway continuously monitors its configuration files for changes. This enables credential rotation without restarting the entire daemon:

File modification detection:

// On each main loop iteration:
stat(azure_config_path, &current_stat)
stat(pem_certificate_path, &current_pem_stat)

if (current_stat.st_mtime != cached_stat.st_mtime ||
    current_pem_stat.st_mtime != cached_pem_stat.st_mtime) {
    // Configuration changed — restart MQTT client
    log_warning("Restart Azure connection")
    restart_mqtt_client()
    cached_stat = current_stat
    cached_pem_stat = current_pem_stat
}

This pattern means you can rotate credentials by simply writing a new configuration file — the gateway picks it up automatically. No SSH required. No reboot. For fleet deployments, you push new configs via a side channel (cloud-to-device message, local API) and the gateway self-heals.

MQTT Client Restart — Without Losing Data​

Restarting the MQTT client for credential rotation must be seamless. Here's the critical sequence:

1. Signal the Buffer​

Before disconnecting, notify the store-and-forward buffer that the connection is going away:

buffer_process_disconnect(output_buffer)
// Buffer stops attempting to send, continues accepting new data

The buffer transitions to "disconnected" mode — it continues accepting telemetry from the PLC reading loop (which never stops) but doesn't attempt to publish. This prevents MQTT errors from cascading into buffer corruption.

2. Gracefully Shut Down MQTT​

mosquitto_loop_stop(client, force=true)  // Stop the network loop
mosquitto_disconnect(client)              // Send DISCONNECT packet
mosquitto_destroy(client)                 // Free resources
mosquitto_lib_cleanup()                   // Clean up library state

The order matters. Stopping the loop before disconnecting prevents callbacks from firing on a partially destroyed client. Force-stopping the loop (rather than waiting for it to finish) prevents hanging if the broker is unresponsive.

3. Re-initialize with New Credentials​

// Parse new config file
new_token = parse_sas_token(config_file)

// Create new MQTT client
client = mosquitto_new(device_id, clean_session=false)
mosquitto_username_pw_set(client, username, new_token)
mosquitto_tls_set(client, ca_cert_path)
mosquitto_opts_set(client, MQTT_PROTOCOL_V311)

// Set callbacks
mosquitto_connect_callback_set(client, on_connect)
mosquitto_disconnect_callback_set(client, on_disconnect)
mosquitto_publish_callback_set(client, on_publish)

// Start network loop and connect asynchronously
mosquitto_loop_start(client)
mosquitto_reconnect_delay_set(client, 5, 5, false)
mosquitto_connect_async(client, hostname, port, keepalive=60)

4. Resume Buffer Delivery​

When the on_connect callback fires (CONNACK received with status 0), the buffer is notified:

void on_connect(status) {
    if (status == 0) {
        // Subscribe to command topics
        mosquitto_subscribe(client, command_topic, qos=1)
        // Signal buffer to start sending
        buffer_process_connect(output_buffer)
    }
}

The buffer begins draining its queued pages, publishing and tracking acknowledgments as normal. Zero telemetry was lost during the credential rotation — it was all safely buffered.

Asynchronous Connection — Why It Matters​

Industrial gateways must never block their main loop on a network operation. DNS resolution, TCP handshake, and TLS negotiation can each take 5-30 seconds on a slow cellular link. If the main loop blocks, PLC reads stop, alarms go undetected, and the watchdog timer might reboot the entire device.

The solution: async connection in a dedicated thread.

The main loop signals "connect now" via a semaphore. A background thread handles the blocking connect_async() call. The main loop continues reading PLCs, processing alarms, and buffering data.

// Main thread:
if (need_to_reconnect && connection_thread_is_idle) {
    prepare_connection_params(hostname, port)
    signal_connection_thread()  // sem_post(&job_semaphore)
}
// Main thread immediately returns to PLC reading loop

// Connection thread (runs independently):
while (true) {
    wait_for_signal()  // sem_wait(&job_semaphore)
    log("MQTT ASYNC start")
    result = mosquitto_connect_async(client, host, port, 60)
    if (result != SUCCESS)
        log_error("connect_async error: %d", result)
    log("MQTT ASYNC stop")
    signal_idle()  // sem_post(&idle_semaphore)
}

The semaphore pair ensures:

  • Only one connection attempt runs at a time
  • The main thread never blocks
  • Failed connections don't trigger immediate retries (the main loop checks idle status before signaling again)

Certificate Pinning for Industrial TLS​

When a gateway connects to Azure IoT Hub (or any cloud MQTT broker) over TLS, it must validate the server's certificate. In industrial deployments, this typically means pinning a specific CA certificate rather than trusting the entire OS certificate store:

mosquitto_tls_set(client, 
    "/etc/IoTHub_AzureCombinedCert.pem",  // CA cert file
    NULL,                                   // No CA directory
    NULL,                                   // No client cert
    NULL,                                   // No client key
    NULL)                                   // No passphrase

Why pinning matters on the factory floor:

  • Embedded Linux gateways often ship with incomplete or outdated CA bundles
  • The gateway only talks to one broker — it doesn't need to trust the entire internet
  • A compromised CA (e.g., DigiNorak, Let's Encrypt cross-sign changes) won't affect a pinned deployment
  • Smaller attack surface — if someone manages to install a rogue CA cert on the gateway, pinned connections still reject it

The risk: When the cloud provider rotates their server certificate to a new CA, your pinned gateways stop connecting. Mitigation: include both the current and next CA certificate in your combined PEM file, and monitor cloud provider announcements for CA transitions.

Fleet Provisioning Patterns​

Pattern 1: Pre-Provisioned (Build-Time)​

Each gateway ships with a unique SAS token or certificate baked into its firmware image. Simple, secure, but operationally expensive — every device needs a unique build.

Best for: Small fleets (<100 devices), high-security environments.

Pattern 2: First-Boot Provisioning​

The gateway ships with a bootstrap credential (enrollment key or provisioning certificate). On first boot, it contacts a provisioning service, registers itself, and receives its permanent credentials.

Best for: Large fleets where manual per-device configuration is impractical.

Pattern 3: Token Server Architecture​

The gateway authenticates to a local token server (on-premises or in a DMZ) using its hardware identity (MAC address, TPM attestation, or serial number). The token server issues short-lived SAS tokens. The gateway refreshes tokens before expiry.

Best for: High-security OT environments where cloud credentials shouldn't persist on edge devices.

Pattern 4: Serial Number as Identity​

Many industrial gateways already have unique identities — PLC serial numbers, router serial numbers, or MAC addresses. Use these as the device ID for cloud registration:

// Compose device identity from hardware
device_id = compose_from_serial(
    plc_year,           // e.g., 22
    plc_month,          // e.g., 09
    plc_unit_number     // e.g., 1017
)
// Result: device_id = "22091017"

The serial number provides traceability — you can match cloud telemetry back to a specific physical machine on a specific factory floor. When a gateway is replaced, the new one registers with its own serial, and the old device's cloud identity can be revoked.

Common Failure Modes and Their Fixes​

Silent Token Expiry​

Symptom: Gateway appears online (LED green, PLC reads normal) but no data reaches the cloud for days.

Root cause: SAS token expired, MQTT reconnection loop fails silently.

Fix: Token expiration watchdog + alerting when (now - last_successful_publish) > threshold.

Clock Drift on Embedded Devices​

Symptom: Gateway rejects its own valid token because system clock is wrong.

Root cause: RTC battery dead, no NTP on isolated OT network.

Fix: Use monotonic clock for internal timers (connection watchdog, batch timing) and real-time clock only for timestamp generation. Accept tokens if the clock appears unreliable (system time < token creation time).

Certificate File Permissions​

Symptom: MQTT connection fails immediately after config push.

Root cause: New certificate file written with wrong ownership — the daemon can't read it.

Fix: Config file watcher should validate readability before attempting MQTT restart. If the file exists but can't be read, log an error and retain the current connection.

Async Connection Race Condition​

Symptom: Occasional crash during credential rotation under high load.

Root cause: Main thread destroys MQTT client while connection thread is still using it.

Fix: Semaphore-based mutual exclusion — check that the connection thread is idle (sem_trywait) before destroying the client. If the thread is busy, defer the restart.

How machineCDN Handles Provisioning​

machineCDN's edge gateway uses SAS token authentication with Azure IoT Hub, combined with a file-based configuration watchdog. The gateway monitors both the Azure config file and the TLS certificate file for changes — when either is modified, the MQTT client gracefully restarts with the new credentials while the store-and-forward buffer preserves all in-transit telemetry.

Token expiration is checked on every MQTT initialization cycle. If the SAS token's se timestamp has passed, the gateway logs a clear warning with both the token expiry time and current system time, making it immediately diagnosable from the syslog. The MQTT connection is established asynchronously in a dedicated thread, ensuring that DNS resolution and TLS negotiation on cellular links never block the PLC reading loop.

Each device's identity is derived from its PLC serial number — a combination of manufacture year, month, and unit number that provides both uniqueness and physical traceability. When a gateway comes online, its device ID maps directly to a specific machine on a specific factory floor, making fleet-wide monitoring and troubleshooting straightforward.

Key Takeaways​

  1. SAS tokens are the pragmatic choice for resource-constrained gateways — stateless, cheap to generate, and universally supported
  2. Build a token expiration watchdog — silent expiry is the #1 authentication failure mode in production
  3. Use file modification detection for credential rotation — no restart, no SSH, no downtime
  4. Never block the main loop on network operations — async connection threads prevent PLC read stalls
  5. Pin your TLS certificates — industrial gateways don't need to trust the entire internet
  6. Use hardware serial numbers as device identity — traceability from cloud data back to physical machines
  7. Buffer through credential rotation — the PLC reading loop never stops, even during MQTT client restarts

Authentication isn't a one-time setup — it's a continuous process that must survive token expirations, certificate rotations, network outages, and clock drift. Design for self-healing, and your fleet will run for years without manual intervention.