How to fix weak cryptography in embedded firmware

CISA's Product Security Bad Practices guidance is direct about the risk: "Information technology products used in service of critical infrastructure or NCFs and that use known insecure or deprecated cryptographic algorithms or lack encryption for the transit or storage of sensitive information are dangerous," specifically naming continued use of TLS 1.0/1.1, MD5, SHA-1 and DES as examples still found in the field. In firmware specifically, this is rarely a deliberate current-day choice — a weak algorithm or key length is usually inherited from an SoC vendor's old reference SDK that nobody has revisited since the product's first revision, or it was a genuinely reasonable call on resource-constrained hardware years ago that has since been replaced by a chip capable of running something stronger, without the firmware's crypto choices being updated to match.

They sound similar but call for different fixes, and a single device can carry more than one at once. CWE-327 (broken/risky algorithm) is an algorithm-choice problem — the cipher itself is weak or deprecated, no matter how it's keyed. CWE-326 (inadequate encryption strength) assumes the algorithm is fine but the parameters aren't — a 64-bit key with AES is still AES, but it isn't adequate anymore. CWE-321 (hard-coded key) is a provisioning problem, not an algorithm problem — even a perfectly strong, modern cipher is defeated the moment every unit of a product shares the same embedded key, since extracting one unit's firmware compromises the entire fleet. CWE-330 (insufficient randomness) undermines whichever algorithm and key length were chosen, because a predictable PRNG seed makes supposedly-random session keys, nonces or tokens guessable regardless of how strong the cipher downstream is. Treating all four as "the crypto is bad" obscures that the actual fixes — swap an algorithm, lengthen a key, change provisioning, change entropy sourcing — are different engineering changes.

For CWE-327, MITRE's architecture-and-design mitigation is to "use strong, up-to-date cryptographic algorithms," picking "a well-vetted algorithm that is currently considered to be strong by experts in the field" rather than designing one in-house — a custom cipher "will likely be exposed to attacks that are well-understood by cryptographers" that its designer never anticipated. MITRE also flags that strength is not a one-time decision: "periodically ensure that the cryptography has not become obsolete," and design the system so one algorithm can be swapped for another in a future update rather than hard-wiring a single cipher choice a field device can never revise. For CWE-326, the matching fix is sizing keys and algorithm parameters to the protection actually required today, not to what was adequate when the product was first designed — the same algorithm with longer keys is often a smaller firmware change than a full cipher migration.

For CWE-321, MITRE states the fix directly: "prevention schemes mirror that of hard-coded password storage" — provision each unit with its own key at manufacturing or first boot, ideally derived from a hardware root of trust, instead of compiling one fixed key into every firmware image; our secure boot and hardware root of trust guide covers where that unique key material should actually be anchored in silicon. For CWE-330, MITRE is specific about scale and source: "a 256-bit seed is a good starting point for producing a 'random enough' number," a PRNG "not advertised as being cryptographically secure ... should not be used in security-sensitive contexts," and implementations should "re-seed ... from high quality ... sources, such as hardware devices" — a true hardware random number generator where the silicon has one, rather than a software PRNG seeded from something predictable like an uptime counter or boot timestamp.

A changelog entry saying "upgraded cryptography" is not evidence by itself. Confirm an algorithm or key-length change by extracting the shipped firmware binary and checking which crypto library calls, constants and key sizes it actually contains, not what the release notes claim. Confirm a hard-coded key is really gone by comparing binary strings or key material across multiple units from different manufacturing batches — if every sampled unit still produces an identical key or device certificate, per-device provisioning isn't actually happening yet regardless of what the design doc says. Confirm randomness quality by sampling generated tokens, nonces or session keys across many boots — including immediately after first flashing, a common point where a PRNG hasn't gathered real entropy yet — rather than trusting that calling a function named "secure_random" makes the output secure.

SoftWSP's device and firmware security work extracts the actual binary and checks what cryptography it really runs — algorithm choice, key length, whether keys are unique per device, and whether randomness sources are hardware-backed — rather than relying on vendor documentation. See device & firmware security services for how that scope covers CWE-327/326/321/330 alongside other CWE Top 25 classes like the ones in our memory corruption and hard-coded credentials guides.

This guide is based on MITRE's CWE-327, CWE-326, CWE-321 and CWE-330 definitions and CISA's Product Security Bad Practices guidance, read directly 2026-11-02.