CWE-798, use of hard-coded credentials, remains one of the most common vulnerability classes in connected products. Secrets end up in firmware images, mobile applications, configuration files and even API responses: API keys for cloud backends, service passwords, certificates, encryption keys, tokens for third-party services.
The structural problem is not sloppiness; it is architecture under pressure. A cloud API key baked into the firmware avoids a per-device identity system. A shared service password avoids an enrollment flow. Each shortcut is individually rational, and collectively they create a credential that cannot be rotated without a firmware release, cannot be scoped to one device, and cannot be revoked without bricking the fleet.
Extraction is routine. Firmware images are public artifacts in practice: dumped from one device, pulled from an update package, or recovered from a mobile app's binary. Real-world cases in 2025 alone include administrative credentials recoverable from API responses and mobile applications. After extraction, the secret propagates to every place that accepts it as authorization.
Secret exposure depends on several technical assumptions.
- Secret inventory What credentials, keys, tokens and certificates are actually embedded in firmware, apps, configs and responses?
- Extraction resistance How much effort does each storage location require, from string extraction to reverse engineering?
- Trust scope Where is each secret accepted as authorization: device, API, backend, third-party service?
- Sharing breadth Is the secret unique per device, per batch, or global across the product line?
- Rotation capability Can the secret be replaced without a firmware release, and what breaks when you try?
- Compensation controls Is there rate limiting, anomaly detection or scoping that contains a leaked secret?
- Third-party exposure Do API responses or app binaries disclose secrets that the server treats as private?
The API key opened the cloud, and every device with it.
A backend API key is embedded in the firmware to simplify device-to-cloud communication. A researcher extracts it from a firmware image in an afternoon.
The key is valid for the production API. It grants the same access to every device in the fleet, because it is the same key. Rotation requires a firmware update, which the fleet rolls out over months. Until then, the attacker and the products share a credential.
Find the secrets, then test where they are trusted.
We extract secrets from firmware, apps and API responses using the same techniques an attacker applies, then map each credential to the systems that accept it. The assessment answers the commercial question: what does a leak actually cost, and which architectural change removes the exposure.
- New product connects to a cloud backend
- Mobile application accesses device or backend services
- Third-party services integrated with API keys
- A firmware image or app binary is publicly accessible
- A leaked credential has been observed in the wild
- Compliance review flags embedded credentials
- Preparing an SBOM or source review before release