TLS 1.3 from Indian IoT Devices to AWS IoT Mumbai and Azure IoT Central India with SEGGER emNet and emSSL

Every Indian IoT product shipping today needs a secure uplink to a cloud broker. AWS IoT running out of the Mumbai region (ap-south-1), Azure IoT Central India (centralindia), or an enterprise customer’s on-premises MQTT broker inside an Indian industrial network, in every case, the security requirement is the same: TLS 1.2 or 1.3, mutual authentication with device certificates, and a cryptographic identity that the factory contract manufacturer cannot clone or exfiltrate.

Most Indian IoT teams default to mbedTLS (the open-source TLS library Arm maintains) paired with lwIP (the open-source TCP/IP stack) because both are free, widely documented, and ship as reference implementations in every silicon vendor’s SDK. mbedTLS works. It has served Indian IoT startups well for years. And for a non-trivial fraction of Indian commercial products it is the wrong choice, for reasons that only surface after the product is already shipping: footprint, performance under load, long-term support, and commercial accountability when something breaks at 23:00 on a Friday.

This post walks through the commercial alternative, SEGGER emNet as the TCP/IP stack and SEGGER emSSL as the TLS stack, focused specifically on Indian IoT workloads connecting to AWS IoT Mumbai, Azure IoT Central India, and Indian on-premises brokers. It also covers the secure-provisioning piece that matters for Indian contract manufacturing: using Flasher Secure to inject device certificates and private keys at the factory line without ever exposing plaintext to the CM operator. GSAS Micro Systems is India’s authorized SEGGER partner, every product mentioned here is available with INR invoicing and local engineering support across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, and Pune.

Why mbedTLS is a reasonable default: and when to replace it

mbedTLS is a competent TLS library. It supports TLS 1.2 and TLS 1.3, AES-GCM, ECDSA, ChaCha20-Poly1305, and the cipher suites AWS IoT and Azure IoT Hub require. It is actively maintained. Its documentation is thorough. For a prototype, for a startup shipping 500 units, for any product where the BOM headroom is not the deciding constraint, mbedTLS does the job.

The situations where Indian IoT product teams hit the limit of mbedTLS and need to consider a commercial alternative:

• Code size. mbedTLS with TLS 1.2 + AES-GCM + ECDSA P-256 typically lands at 80-120 KB of flash. On an STM32L4R5 with 2 MB of flash this is fine. On an STM32L412 with 128 KB of flash, the kind of cost-optimized part an Indian consumer IoT company picks for a sensor node, it is half the application’s code budget. emSSL typically saves 30-40% of footprint in the same configuration, which is often the difference between “fits” and “does not fit.”
• RAM at connection time. TLS handshake buffers can demand 25-40 KB of RAM for the duration of the connection. On a 64 KB RAM part this is painful. emSSL’s memory profile is tighter.
• Handshake latency. TLS handshake time on a Cortex-M4 at 64 MHz is dominated by the ECDSA signature verification and ECDHE key agreement, and this matters for battery-powered nodes that wake, connect, publish, and sleep. A 2.5 s handshake burns measurable battery. emSSL’s tighter implementation is typically 15-30 % faster on the same silicon.
• Long-term support. mbedTLS is maintained by a community and a sponsor (Arm / Trusted Firmware). The project has had end-of-life and version-fork events in its history that have surprised product teams shipping on it. Commercial TLS stacks like emSSL come with a contractual long-term support commitment, a line your procurement team can reference.
• Accountability. When something breaks in production and the field team cannot reproduce it, the difference between a community forum and a commercial support line with an engineer on the other end matters. For Indian consumer and industrial IoT shipping in the tens of thousands of units, the support line is worth the commercial licence.

None of this is an argument to replace mbedTLS everywhere. It is an argument to consider emNet + emSSL when any of the above constraints becomes the deciding factor on a specific Indian product programme.

The emNet + emSSL integration model

emNet is SEGGER’s TCP/IP stack, historically named embOS/IP, renamed to emNet in 2022. It implements the standard socket API (BSD sockets, same call names as lwIP and every other TCP/IP stack), which means the transition from lwIP to emNet is largely a matter of replacing the init code and the socket buffer configuration rather than rewriting application-level networking logic.

emSSL is SEGGER’s TLS implementation, built to slot into emNet (or any other stack that exposes a transport abstraction) as a layer above raw sockets. From the application’s perspective, you replace calls like:

int s = socket(AF_INET, SOCK_STREAM, 0);
connect(s, &server_addr, sizeof(server_addr));
send(s, mqtt_connect_packet, len, 0);

with the emSSL equivalents:

SSL_SESSION * ssl = SSL_SESSION_Prepare(...);
SSL_SESSION_Connect(ssl, server_hostname, 8883);
SSL_SESSION_Send(ssl, mqtt_connect_packet, len);

emSSL handles the handshake, the certificate validation (against the trusted CA bundle you provision at manufacturing time), the cipher negotiation, and the symmetric encryption of the application data stream. Your MQTT client above does not need to know whether it is running on plain sockets or TLS sockets, which is the property that makes the migration from a prototype-on-lwIP to production-on-emNet+emSSL manageable.

AWS IoT Mumbai (ap-south-1) integration: concrete setup

AWS IoT Core in the Mumbai region uses the endpoint pattern *.iot.ap-south-1.amazonaws.com, and every device that connects must present:

1. A device certificate signed by a CA registered with AWS IoT.
2. A private key matching the certificate.
3. A trust store containing the AWS root CA (Amazon Trust Services).

In an emNet + emSSL deployment:

• CA certificate: install the AWS root CA (typically AmazonRootCA1.pem) into the device’s trust store at manufacturing time. This is a publicly-available certificate and does not need secure provisioning.
• Device certificate + private key: generated per device, unique per device, signed by a CA registered with AWS IoT. Must be provisioned securely so the contract manufacturer cannot see the plaintext private key. This is where Flasher Secure earns its keep.
• Thing name and MQTT topic structure: application-level configuration, typically stored in the device’s non-volatile memory at first boot from a provisioning service.

The emSSL API for AWS IoT is the standard TLS client API with the AWS root CA as the pinned trust anchor. The only AWS-specific consideration is the cipher suite preference, AWS IoT supports a specific set of cipher suites, and emSSL needs to negotiate one of them. Default configurations work out of the box on current emSSL versions.

Azure IoT Central India: same approach, different endpoints

Azure IoT Hub and Azure IoT Central deployed in the centralindia region use the endpoint pattern *.azure-devices.net (for generic IoT Hub deployments) or *.azureiotcentral.com (for IoT Central). The authentication model is similar to AWS IoT, device certificate, private key, trusted CA, but Azure also supports SAS token authentication as an alternative for simpler deployments.

For Indian enterprise customers with compliance requirements around data residency, the fact that both AWS IoT and Azure IoT now operate out of Indian-territory data centres (Mumbai for AWS, Central India for Azure) matters materially. Data never leaves Indian soil for the cloud uplink, which simplifies compliance under CERT-In’s IoT security guidelines and the Indian data protection regime.

emSSL works identically against Azure IoT Hub as it does against AWS IoT Mumbai, the same client-side code path, the same X.509 certificate model, just a different root CA (Microsoft’s Baltimore CyberTrust or DigiCert Global Root CA depending on the specific Azure region configuration) in the trust store.

Secure provisioning: pairing emSSL with Flasher Secure

The device certificate and private key are where IoT security either works or fails in production. If the private key is stored in plaintext in the firmware image, the contract manufacturer has access to every device’s identity during programming, and the whole identity model breaks. If the private key is generated on-device at first boot and never leaves the device, you have to either accept that the certificate is unsigned (useless for mutual TLS to AWS IoT / Azure) or run an online provisioning step that the device is not in a position to authenticate.

The clean solution: generate the device certificate and private key at the OEM’s premises, sign it with a CA registered with AWS IoT or Azure, and inject it into the device’s secure storage at the contract manufacturing line using Flasher Secure and Flasher Secure Server. The flow:

1. OEM’s provisioning service generates a unique keypair per device, signs the certificate with the AWS IoT / Azure CA, and uploads the package to Flasher Secure Server at the OEM’s Bengaluru or Pune R&D centre.
2. FSS issues a signed authorization batch to the Flasher Secure on the contract manufacturer’s floor, say, 10,000 device identities valid for the next 30 days.
3. For each board programmed, Flasher Secure decrypts the next device identity internally and injects it directly into the target MCU’s secure element (on STM32 U5 / H5 with STSafe or onboard secure memory, on NXP i.MX RT with HAB fuses, on Nordic nRF53/nRF54 with KMU, on Microchip SAM L11 with TrustZone secure region).
4. The plaintext private key is never exposed to the CM operator. The OEM retains cryptographic evidence that exactly 10,000 device identities were issued and that each one maps to a specific programmed unit.

The result is an Indian IoT product that runs TLS 1.3 to AWS IoT Mumbai, with a cryptographically unclonable device identity, whose factory provisioning path is auditable and whose runtime TLS library is emSSL running on emNet, a full commercial-supported stack from identity issuance through production to field operation.

When to pick this stack vs staying on open-source

The practical decision framework for Indian IoT product teams:

Stay on lwIP + mbedTLS when:

• Your product ships in low volumes (under a few thousand units total).
• Flash and RAM budgets are comfortable (the cost-optimized silicon is not on your BOM).
• Your team has the engineering bandwidth to triage TLS issues when they arise.
• There is no commercial accountability requirement from your customer.

Move to emNet + emSSL when:

• Your product ships in volumes that make the commercial licence cost per unit small relative to the per-device support savings.
• Flash or RAM budget pressure forces the 30-40 % footprint savings.
• Your OEM customer or enterprise customer requires a commercial accountability trail for security-relevant components.
• Your programme has a long support horizon (5+ years) and you need a contractual commitment that the TLS library will still be patched in year 5.

Pair emSSL with Flasher Secure when:

• The device identity is cryptographically significant and cannot be exposed to the contract manufacturer.
• The programme operates at production volumes where per-unit authorization and audit are required.
• The product is in a regulated category (medical, automotive, defence, industrial control).

Further reading

• SEGGER emNet product page at segger.com
• SEGGER emSSL product page at segger.com
• SEGGER emNet at GSAS
• SEGGER emSSL at GSAS
• SEGGER Flasher Secure for encrypted provisioning, companion post on secure factory provisioning
• SystemView V4 for RTOS latency analysis during TLS handshake
• SEGGER at GSAS
• AWS IoT documentation
• Azure IoT documentation