How to fix hard-coded credentials in embedded firmware

Last updated: 2026-10-29

Hard-coded credentials (MITRE CWE-798, and the password-specific CWE-259, both read 2026-10-29) are passwords, API keys or cryptographic keys embedded directly in firmware code, configuration or a binary — either a default admin login every unit of a product shares (the inbound case), or a secret the firmware itself uses to authenticate to a backend, update server or companion app (the outbound case). MITRE is direct about the blast radius: because the value is identical across every shipped unit, "malicious users will almost certainly be able to gain... access," and the risk scales with how widely the product is distributed — the exact pattern behind most default-credential IoT botnets.

1. Detect

Extract firmware images (filesystem, bootloader, any OTA package) and search binaries and configuration files for plaintext passwords, API tokens, private keys, and common vendor-default strings (admin, password, root, device-model-based defaults).
Check source code and build scripts for credentials embedded in constants, environment defaults baked into the image, or test/debug accounts left enabled in release builds.
Audit every outbound connection the firmware makes (update servers, cloud APIs, companion-app pairing) for a fixed, shared API key or client secret rather than a per-device provisioned one.
Review the first-boot/provisioning flow: does every unit ship reachable over the network with the same default login active, or is a unique credential required before the device accepts remote connections?

2. Fix

Move outbound credentials out of the code entirely. MITRE's mitigation for the outbound case: store the credential "outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders," provisioned uniquely per device during manufacturing or first boot — not baked identically into every firmware image.
Replace default inbound accounts with mandatory first-login provisioning. Require each unit to set a unique, strong password or key before any network-facing admin function becomes reachable, instead of shipping with a fixed default that works out of the box.
Scope access to the credential-gated feature. Where a hard-coded value cannot be removed immediately (for example, a manufacturing-test backdoor), restrict it to a local, physically-present interface — a serial console or JTAG header — rather than leaving it reachable over the network, and plan its removal.
Hash stored passwords with a per-installation salt. If a password must be stored at all (rather than a key), use a strong one-way hash with a randomly assigned salt per device, so that extracting the configuration store does not directly yield a usable credential.
Treat this as a class, not a one-off. If one product line has a default-credential issue, check every other product line and firmware branch built from the same SDK or reference design for the same pattern before declaring the fix complete.

3. Verify

Re-flash the patched firmware to a test unit, confirm the device refuses to operate (or operates in a restricted provisioning-only mode) until a unique credential is set, and confirm the old default no longer authenticates.
Re-extract the new firmware image and confirm no plaintext credential remains in the filesystem, configuration or binary.
Confirm outbound connections now use a per-device credential by provisioning two test units and checking they use different values against the backend.

4. Ship an update

Hard-coded-credential fixes usually require a provisioning-flow change, not just a firmware flash, so coordinate the update with manufacturing and any existing fleet: units already in the field need a forced password-rotation path (and, if remotely reachable, a remediation notice), not just a silent binary swap. Confirm affected models and versions with your firmware SBOM before scoping the rollout.

5. Disclose via PSIRT

Default and hard-coded credentials are routinely included in CISA's Known Exploited Vulnerabilities catalog once scanners find them at scale, so treat disclosure as time-sensitive; see KEV + EPSS prioritization. Publish the advisory and remediation guidance through your coordinated disclosure process (CVD process explained; PSIRT setup for a hardware company if you don't have one yet), and check the Cyber Resilience Act's reporting duty for EU-market products if the credential was being actively exploited (CRA 24h/72h reporting).

SoftWSP's firmware scanning extracts and checks images for exactly this pattern — default and hard-coded credentials — before they reach the field: see device & firmware security.

This guide summarises public MITRE CWE and CISA guidance; it is not a substitute for a full firmware extraction and review, and does not constitute legal advice.

Frequently asked questions

What is a hard-coded credential, exactly?

MITRE's CWE-798 (Use of Hard-coded Credentials) defines it as a product that "contains hard-coded credentials, such as a password or cryptographic key." CWE-259 (Use of Hard-coded Password) is the narrower password-only case. MITRE describes two variations: inbound, where the product's own authentication mechanism checks a login against a fixed value — a default admin account with the same password on every unit — and outbound, where the firmware itself authenticates to another system (a backend API, an update server, a companion device) using a credential embedded in its code or binary, which MITRE notes is "typically simple" to extract, especially from client-side systems.

Why is this specifically dangerous at device-fleet scale?

MITRE's Common Consequences for CWE-798 are blunt: because every unit of a product shares the same hard-coded value, "malicious users will almost certainly be able to gain access," and "this type of vulnerability can be especially dangerous... if the software is distributed" — a single extracted credential compromises every deployed device at once, which is the exact mechanism behind large IoT botnets built from default-credential devices.

What is MITRE's recommended fix for outbound credentials (firmware calling another system)?

CWE-798's architecture-and-design mitigation for the outbound case: "store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders," provisioned per-device at manufacturing or first boot rather than baked into every firmware image.

What is the fix for inbound credentials (a device's own login/admin account)?

Rather than shipping a fixed default admin password, MITRE recommends a "first login" mode that forces each unit to be provisioned with a unique, strong password or key before it becomes reachable — the same goal CISA's Secure by Design Pledge sets as one of its seven measurable commitments: "measurable progress reducing default passwords; unique per-device credentials rather than shared defaults." See our [CISA Secure by Design guide](/guides/cisa-secure-by-design-pledge/).

What if we can't fully remove the credential — is there a fallback mitigation?

MITRE lists two partial mitigations: limit which entities can reach the feature that needs the hard-coded credential (for example, restrict it to a local serial console rather than the network), and, where a password must be stored at all, hash it with a strong one-way function and a per-installation random salt rather than keeping it in plaintext — this does not remove the underlying design flaw, but it raises the cost of exploiting it if the storage is later exposed.