Hard-coded credentials are passwords or cryptographic keys written into the product itself. CWE-798 defines them that way, and ETSI EN 303 645 says hard-coded critical security parameters shall not be used in device software source code. Anyone who gets the firmware image can try to extract them.
Why they are found
ETSI's explanation is direct: reverse engineering of devices and applications can easily discover hard-coded usernames and passwords, and also API keys or private keys. It adds that simple obfuscation or encryption of such values can be trivially broken. A string that has to be used by the code can be recovered from the image.
The impact grows with reuse. If every unit of a product ships with the same credential, one extracted secret opens the whole product line. ETSI notes that disclosure of global critical security parameters can enable wide scale attacks, such as creating botnets.
What MITRE suggests
CWE-798 lists mitigations for design time:
- Outbound authentication. Keep credentials out of the code. Store them in protected configuration and protect the encryption key.
- Inbound authentication. Do not ship default usernames, passwords or keys. Use a first login mode that requires a unique, strong credential.
- Access control. If you cannot remove the credential, limit which entities can reach the feature that uses it, for example the console only rather than the network.
- Password hashing. Store passwords as salted one-way hashes.
A practical plan for a firmware team
- Search source and build artifacts for passwords, tokens and private keys, and add a scanner for secrets to CI so new ones are caught on the pull request.
- Provision unique credentials per device during manufacturing, or force a first login choice.
- Keep service credentials for cloud back ends out of the image. Use per device identity and short lived tokens where you can.
- Treat the update verification key carefully. ETSI provision 5.4-4 says critical security parameters for update integrity checks and communications shall be unique per device. Its example of an acceptable global value is the manufacturer's public key, which is not a critical security parameter.
- Test the shipped image, not only the source. Unpack a production image and look for strings.
Existing products
If a product already ships with a shared credential, you need a fix delivered by update, a disclosure, and a plan for units that cannot update. Our post on unique per device passwords covers what good looks like.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding points to a file and line you can fix.
Quick check
Does encrypting a hard-coded password make it safe?
ETSI says simple obfuscation or encryption of hard-coded values can be trivially broken, since the code must be able to recover the secret.
Is a manufacturer public key a hard-coded secret?
ETSI gives it as an example that is not a critical security parameter and need not be unique per device.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, policies and gates, and compliance evidence automation. Feed it the SBOMs and manifests your build produces and use gates to hold a release that fails your rules. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
