SEGGER emMQTT for AWS IoT Mumbai, Azure IoT Central India, and Private Brokers

Every Indian connected product built in the last five years has to answer the same uplink question sooner or later: which broker are we publishing telemetry to, which protocol are we using, and which client library on the device produces a binary footprint and a support relationship that survives the first customer escalation at production scale? In the overwhelming majority of cases the protocol answer is MQTT 3.1.1 (or, increasingly, MQTT 5) over TLS, and the broker answer is one of three: AWS IoT Core running out of Mumbai (ap-south-1), Azure IoT Hub or Azure IoT Central in centralindia, or a self-hosted broker (Eclipse Mosquitto, EMQX, HiveMQ) running inside an India-resident data centre under the customer’s own operational control. This post walks through SEGGER emMQTT, the commercial MQTT client that runs on top of emNet for TCP and emSSL for TLS, and how Indian product teams use it to talk to each of these broker destinations. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we support emMQTT licensing, silicon bring-up, TLS profile tuning for each broker, and Flasher Secure device-cert provisioning from our offices across India.

The Indian cloud-uplink problem in one paragraph

An Indian IoT product, a Bengaluru smart-home controller, a Pune solar inverter gateway, a Chennai industrial edge node, a Hyderabad asset tracker, a Mumbai energy meter, lives on a Cortex-M class device with 256 KB to 2 MB of flash and 64 KB to 512 KB of RAM. It needs to publish telemetry, subscribe to command topics, and handle the connection lifecycle (keep-alive pings, reconnection with backoff, session resumption on flaky cellular links). The security baseline is TLS 1.2 or 1.3 with mutual authentication using a device certificate the CM cannot exfiltrate. The commercial baseline is a library that a procurement team can put under contract and a support team can escalate to when something misbehaves at 23:00 on a Friday. That is the slot emMQTT fills.

What emMQTT provides

emMQTT is SEGGER’s commercial MQTT client library. The capability list matters for the procurement conversation:

• MQTT protocol versions. Full MQTT 3.1.1 and MQTT 5 support. MQTT 5 adds structured reason codes, per-message user properties, request/response correlation, and per-session expiry intervals. Indian teams starting new projects in 2026 typically target MQTT 5 where the cloud broker supports it, and fall back to MQTT 3.1.1 for self-hosted brokers on older revisions.
• TLS underneath. emMQTT runs on top of emNet for the TCP transport and emSSL for the TLS layer. Mutual TLS with a device certificate and private key is the standard configuration for all three public clouds.
• QoS 0, 1, and 2. All three MQTT quality-of-service levels are supported. QoS 1 is the most common choice for Indian telemetry use cases; QoS 0 is used for disposable high-rate sensor streams.
• Retained messages, last-will-and-testament, persistent sessions. LWT is particularly important for Indian field devices on unreliable cellular networks, it lets the broker publish a “device offline” message the moment the TCP connection drops.
• Keep-alive and automatic reconnection handled inside the library, not in application code.
• Royalty-free commercial licence: one contract with SEGGER, integrated support alongside embOS, emNet, emSSL, and emFile.

Why commercial instead of Paho or mosquitto-client

Indian IoT teams starting a new project usually encounter the same library comparison. The open-source Eclipse Paho C client and libmosquitto are competent, they will compile, they will connect to AWS IoT Core and Azure IoT Hub, and they will publish telemetry. For a prototype or a pilot of 500 units, Paho is fine.

The situations where Indian teams reach for a commercial MQTT client are the same ones that drive the emSSL conversation:

• Footprint. Paho + mbedTLS + lwIP on a constrained Cortex-M4 with 256 KB of flash eats a measurable fraction of the code budget. The commercial SEGGER stack typically lands smaller in the same configuration, which matters when the silicon BOM cost is half the total BOM.
• Integrated support. emMQTT, emSSL, emNet, emSecure for the cert-provisioning story, and emCrypt for the underlying primitives are all shipped and supported by one vendor. When a TLS handshake fails against AWS IoT Core and the symptoms sit at the boundary between the MQTT client, the TLS stack, and the TCP layer, the support case goes to one engineer at SEGGER rather than three different mailing lists.
• Broker interop testing. emMQTT is continuously tested against AWS IoT Core, Azure IoT Hub, and representative self-hosted brokers (Mosquitto, EMQX, HiveMQ). Broker-specific quirks that trip up open-source clients, AWS’s requirement for SNI, Azure’s 4 KB system property limit, self-hosted broker certificate-chain handling, are handled inside the library rather than discovered by the product team during UAT.
• Commercial accountability. A commercial contract with a named vendor is a defensible line in the product’s security-review package and in the customer’s vendor-management review.

AWS IoT Core (ap-south-1): the Bengaluru smart-home pattern

AWS IoT Core runs in the Mumbai region under the ap-south-1 AWS identifier. An Indian product team publishing from a Cortex-M device configures emMQTT roughly as follows:

• Broker endpoint. The account-specific <account>-ats.iot.ap-south-1.amazonaws.com on port 8883 (Amazon Trust Services CA chain).
• TLS configuration. Mutual TLS with Amazon’s root CA as the trust anchor, the device’s X.509 certificate as the client identity, and the private key loaded from a write-protected flash region. SNI must be set to the broker hostname, AWS IoT Core rejects connections that omit it.
• MQTT client ID. The AWS Thing name, typically the device serial number. AWS enforces one connection per client ID.
• Topics. Device telemetry publishes to application-defined topics; the device shadow update is always $aws/things/<thingName>/shadow/update.

An Indian smart-home product team under their own AWS account uses exactly this pattern: the device certificate is provisioned at the factory via Flasher Secure (see the Flasher Secure encrypted-firmware post), the device boots, emMQTT establishes a mutually-authenticated TLS connection to the Mumbai endpoint, and telemetry flows into the team’s AWS IoT rules engine.

Azure IoT Hub and Azure IoT Central: the Pune solar inverter pattern

Azure IoT Hub in the centralindia region (Pune) is the dominant Azure destination for Indian industrial IoT workloads that need data residency inside India. Azure IoT Central is the managed SaaS layer on top of IoT Hub, same protocol, same broker semantics, easier on-boarding for teams that want the portal-driven experience rather than the raw SDK.

emMQTT talks to Azure IoT Hub with two authentication models:

• SAS token authentication. The device computes a shared-access-signature token from a symmetric key and includes it as the MQTT password on connect. This is the simplest model and the one Azure IoT Central defaults to.
• Certificate-based mutual TLS. The device presents an X.509 client certificate registered against its Azure IoT Hub device identity. This is the model Indian industrial teams usually prefer, the certificate is provisioned at the factory via Flasher Secure the same way the AWS device cert is, and there is no symmetric key sitting in the device’s flash.

Azure’s topic structure is fixed, devices publish to devices/<deviceId>/messages/events/ and subscribe to devices/<deviceId>/messages/devicebound/#. A typical Pune-area solar inverter OEM publishing inverter health data to Azure IoT Central for fleet monitoring follows this pattern: emMQTT on a Cortex-M7 inverter controller connects to the centralindia IoT Hub endpoint, authenticates with the factory-provisioned X.509 cert, publishes JSON payloads with inverter voltage, current, temperature, and fault flags, and receives command messages, “enter reduced-output mode”, “push firmware update”, “reset fault latch”, on the devicebound topic.

A note on Google Cloud IoT Core

Google Cloud IoT Core, once a natural third entry in this list, was retired by Google in August 2023. Indian teams that had designed against the Google IoT Core managed service migrated either to AWS IoT Core on ap-south-1, to Azure IoT Hub on centralindia, or, increasingly, to a self-hosted MQTT broker stack running on Google Compute Engine, AWS EC2, or on-premises inside an India-resident data centre. emMQTT talks to all of those destinations with exactly the same client code; only the broker endpoint, the TLS trust anchor, and the authentication method change. The retirement of Google IoT Core is a cautionary tale about managed-IoT SKUs and the reason Indian industrial teams now prefer self-hosted brokers whenever possible: the managed service can be withdrawn, but a Mosquitto or EMQX broker the team controls cannot.

Self-hosted brokers: the Mumbai energy-meter and Hyderabad asset-tracker pattern

Not every Indian IoT workload goes to a public cloud. A typical Mumbai-area energy-metering company deploying on a large utility’s private network publishes meter readings to a self-hosted Eclipse Mosquitto or EMQX broker running inside the utility’s own data centre. A typical Hyderabad-area cellular-IoT asset-tracker team publishing GPS and inertial data to a self-hosted HiveMQ cluster in a Mumbai-region data centre does the same thing over public cellular with TLS. The authentication model is typically MQTT-username-and-password with TLS, or mutual TLS with an internal CA, or X.509 client certs against a Mosquitto auth-opt-use-identity-as-username configuration. emMQTT handles all of these configurations identically, the difference from the public-cloud patterns is just the broker endpoint and the trust-anchor certificate.

Self-hosted brokers also come up in Indian defence-electronics and industrial-automation scenarios where the customer’s security posture forbids any public-cloud uplink at all. The same emMQTT code path works; only the configuration changes. For Indian teams operating under the DPDP Act, a self-hosted broker inside an India-resident data centre is often the cleanest data-residency answer, one less cross-border question for the legal review.

Indian cloud-uplink patterns we support

The GSAS engineering team has helped Indian product teams bring emMQTT up against all three public clouds and against self-hosted brokers. The patterns that matter:

• Bengaluru smart-home product publishing to AWS IoT Core in ap-south-1 under the OEM’s own AWS account, with device certs provisioned via Flasher Secure at the Indian CM
• Pune solar inverter OEM publishing fleet telemetry to Azure IoT Central in centralindia for data-residency compliance under the DPDP Act, with mutual TLS and X.509 device certs
• Chennai industrial gateway publishing factory-floor sensor data to AWS IoT Mumbai for an India-resident analytics pipeline, pairing emMQTT with embOS for the RTOS layer and SystemView for the runtime observation
• Hyderabad asset-tracker team publishing cellular-connected GPS data to a self-hosted HiveMQ cluster in a Mumbai-region data centre with mutual TLS and aggressive reconnection logic
• Mumbai energy-metering company publishing to a self-hosted Mosquitto broker on the customer’s premises under the customer’s internal CA

Further reading

• SEGGER emMQTT product page at segger.com
• SEGGER emNet product page at segger.com
• SEGGER emMQTT at GSAS
• SEGGER emNet at GSAS
• SEGGER emSSL at GSAS
• SEGGER emSecure at GSAS
• SEGGER embOS at GSAS
• SEGGER emNet and emSSL for TLS from Indian IoT devices to AWS IoT Mumbai and Azure IoT Central India
• SEGGER Flasher Secure for encrypted firmware delivery to Indian EMS
• SEGGER emSecure-RSA and emSecure-ECDSA for Indian secure boot on Cortex-M
• SEGGER at GSAS

Why GSAS for the Indian rollout

MQTT to any broker is the kind of code path that looks simple in a tutorial and surprises a product team in production, SNI hostnames, certificate chain ordering, keep-alive intervals that fight the cellular modem’s power-save mode, and broker-specific topic quirks all show up the week before launch. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we support emMQTT end-to-end for Indian product teams: commercial licensing in INR, silicon bring-up on STM32, i.MX RT, nRF52/nRF53, and Renesas RA, TLS profile tuning for AWS IoT Core, Azure IoT Hub, and self-hosted Mosquitto/EMQX/HiveMQ brokers, device-cert provisioning via Flasher Secure at the Indian CM, and on-site debugging support when the broker misbehaves. Teams across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, and Pune reach the GSAS engineering desk for emMQTT architecture reviews and commercial proposals. When your product ships to 50,000 homes or 5,000 inverter sites and the uplink has to keep working for a decade, the MQTT client on the device has to be a library you can put under contract, not a weekend port of a hobby project.