The "leaked AWS root key on GitHub" story has been told. The 2026 version of that story is "leaked Azure IoT Hub Device SAS in a firmware mirror," and the AppSec scanners most teams already pay for don't catch it. This post walks through the ten patterns we added to the SF365 SecretScanner in May 2026 specifically for IoT firmware codebases — what each one looks like, what an attacker can do with it, and where it tends to leak.
Why generic regexes miss these. Most secret scanners are tuned for cloud control-plane keys with high-entropy randomness (AKIA[A-Z0-9]{16}). IoT cloud credentials follow different shapes — SAS tokens with named host fields, MQTT URIs with embedded passwords, GCP IoT JWTs scoped to projects/…/registries/…. They don't match a "high-entropy 40-char string" rule because they aren't.
1. Azure IoT Hub Device SAS
Why it matters
An Azure IoT Hub Device SAS grants telemetry-publish and command-receive rights for a single device. With it, an attacker can impersonate the device, send fake telemetry into your analytics pipeline, and accept commands intended for it. Exposed in firmware = the entire fleet's device identities are in the wild.
What the regex catches
HostName=*.azure-devices.net;[…]SharedAccessKey=<base64>
Where it leaks
Provisioning headers, "connection_string.h" includes, integration-test fixtures committed without the .gitignore.
2. Azure IoT Hub connection strings (named)
Why it matters
Same as above, but matched by the named variable form (IotHubConnectionString = "...") which is common in C# firmware-companion code, Azure Function workers and edge runtimes.
What the regex catches
(?i)IotHubConnectionString['"\s:=]+HostName=[^;"']+\.azure-devices\.net
3. AWS IoT MQTT endpoints
Why it matters
AWS IoT endpoints are tenant-specific and uniquely identify a customer's IoT footprint. By itself the endpoint isn't a credential, but it tells an attacker exactly where to point a stolen Device Certificate or X.509 key to start impersonating a device. And the endpoint travels in source far more often than the cert.
What the regex catches
[a-z0-9]{14}-ats.iot.<region>.amazonaws.com
4. GCP IoT device JWTs
Why it matters
Google Cloud IoT Core devices authenticate to mqtt.googleapis.com with a short-lived JWT signed by a per-device key. The audience and registry path show up explicitly in the token. Source code that hardcodes the URL plus the registry path makes it easy for an attacker to learn the project layout, even before they steal a private key.
What the regex catches
mqtt.googleapis.com.*projects/<proj>/locations/<loc>/registries/<reg>
5. Particle.io access tokens
Why it matters
Particle.io is a hobbyist-friendly cloud platform whose access tokens are 40-char hex strings — and tokens grant device-control authority. Exactly the wrong combination for a high-entropy generic rule (the format isn't unusual) plus high-impact leaks.
What the regex catches
(?i)particle[._-]?(access[._-]?)?token['"\s:=]+[a-f0-9]{40}
6. Tuya cloud client secrets
Why it matters
Tuya powers a huge fraction of low-cost smart-home devices. Client / access secrets in firmware that talks to Tuya's cloud routinely leak in mass-produced controllers. The shape is a 32-char hex string adjacent to the literal "tuya" keyword.
What the regex catches
(?i)tuya[._-]?(client[._-]?secret|access[._-]?key|secret[._-]?key)['"\s:=]+[a-f0-9]{32}
7. SmartThings Personal Access Tokens (PATs)
Why it matters
Samsung SmartThings PATs are GUID-shaped, which is exactly why they slip past generic GUID-blocking rules. The detection requires the literal smartthings keyword adjacent to the GUID.
What the regex catches
(?i)smartthings[._-]?(api[._-]?)?(token|key|pat)['"\s:=]+<UUID>
8. MQTT URLs with embedded credentials
Why it matters
The single most common IoT secrets pattern in source. mqtt://user:pass@broker:1883 hardcoded in a connector, an IoT bridge, a Home Assistant integration. Two findings in one: credential leakage and plaintext MQTT.
What the regex catches
mqtts?://[^:@/\s"']+:[^@/\s"']+@[A-Za-z0-9.-]+
9. ESP-IDF Wi-Fi credentials
Why it matters
sdkconfig defines for SSID and PSK end up in builds and product binaries. CONFIG_ESP_WIFI_SSID and CONFIG_ESP_WIFI_PASSWORD in particular, but also the older CONFIG_WIFI_SSID / CONFIG_WIFI_PASS / CONFIG_WIFI_PSK variants.
What the regex catches
CONFIG_(ESP_)?WIFI_(SSID|PASSWORD|PASS|PSK)\s*=\s*"<value>"
10. HomeKit pairing setup codes
Why it matters
HomeKit setup codes are deliberately simple (NNN-NN-NNN). When they appear in source — rather than printed on a label and provisioned during pairing — the device's HomeKit identity is recoverable. Lower severity than the cloud-credential cases but still worth flagging.
What the regex catches
(?i)homekit[._-]?(pairing[._-]?)?(setup[._-]?)?code['"\s:=]+\d{3}-\d{2}-\d{3}
What an exposure actually looks like
// firmware/src/cloud/azure_iot.h
#define IOTHUB_CONN \
"HostName=acme-prod.azure-devices.net;" \
"DeviceId=device-0042;" \
"SharedAccessKey=Y2FmZWJhYmVjYWZlYmFiZWNhZmViYWJlY2FmZQ=="
// firmware/src/cloud/aws_iot.c
static const char* AWS_IOT_ENDPOINT =
"a1b2c3d4e5f6g7-ats.iot.us-east-1.amazonaws.com";
// firmware/sdkconfig
CONFIG_ESP_WIFI_SSID="AcmeFactoryAP"
CONFIG_ESP_WIFI_PASSWORD="acme1234"
// firmware/integrations/mqtt_bridge.py
MQTT_URL = "mqtt://acme:s3cr3t@iot.acme-internal.io:1883"
Four files, four findings, three of them Critical. None of them require AI to detect — just patterns that look for what's actually there.
The fix pattern
For all ten cases, the structural fix is the same: provision, do not embed.
- Cloud credentials should land on the device through a one-time provisioning flow (BLE-based, QR-code, OTP) or via a hardware secure element / TPM. They should never be a build constant.
- MQTT brokers should authenticate with client certificates over TLS, not username/password over plaintext.
- Wi-Fi credentials should be entered by the end user during commissioning. SmartConfig, ESP-IDF's
esp_wifi_provisioning, BLE-basedWiFiProvisioner, or a captive portal — any of these is preferable tosdkconfig. - HomeKit setup codes should be on the box, not in source.
How SF365 ships these
All ten patterns ship as part of the SF365 SecretScanner catalog, bringing the total to 91 high-signal patterns. They are pre-compiled at static init like the rest, vendor-tagged for clean attribution, and severity-ranked (most are Critical / High; HomeKit is Medium). Because they live in the same scanner as the cloud and AI-API patterns, a firmware codebase that also contains an OpenAI key or an AWS key gets a single unified report rather than two scans stitched together.
Run the scan once and you'll typically see findings you didn't expect. That's the value of patterns tuned to your codebase shape: they catch what was always there but invisible to a generic rule.
91 secret patterns. 10 of them aimed at your firmware repo.
SF365's SecretScanner is the only AppSec catalog that ships dedicated detections for Azure IoT, AWS IoT, Particle, Tuya, ESP-IDF and MQTT. Run it on your firmware monorepo and tell us what we missed.
Scan My Firmware Repo