When an embedded device gets compromised, the cause is usually a pile of small problems stacked together. A TLS stack that quietly fell out of compliance. An SSH login with no rate limiting. A debug header left live on production hardware. Firmware nobody checked before it booted. Each one looks survivable on its own. Chained together, they own the device.
So you can't secure one of these devices just by saying "we use TLS" or "we sign our binaries." Code signing and transport encryption are necessary. But they cover two links in a long chain that runs from the boot ROM through the crypto subsystem, the credential store, the update mechanism, and the physical debug ports. Audit those links one at a time and you'll sign off on a device an attacker can still take over.
The examples below come from a real cybersecurity audit of an industrial embedded system based on a Microchip VSC7558, checked against the MITRE EMB3D threat model, IEC 62443-4-2, FIPS 140, and GDPR. The findings are typical of products built for function first and security second.
Why embedded cybersecurity audits need a system-level view
The common mistake is treating security controls as a checklist of independent items. In embedded systems the controls are coupled.
Look at how the VSC7558 findings interlock. No Secure Boot, so the board would load unauthorised or modified firmware. JTAG and UART left open, giving low-level access to anyone who could touch the hardware. An embedded TLS library that missed the required cryptographic standard. Keys sitting in unprotected storage. Weak password policy. And no secure update mechanism to push a fix once something broke.
On their own, each is a finding. Together they describe a device an attacker can reach over the network (weak SSH credentials), modify (no Secure Boot, open JTAG), and keep modified (no secure update path, exposed keys). Encryption does nothing once the attacker controls the firmware. So you assess all of it as one system: firmware integrity, cryptography, credentials, update process, hardware interfaces. Seven separate tickets miss the chain that connects them.
Threat modelling for embedded systems
A system-level view needs a structured way to list out attack surfaces. Two frameworks did most of that work here.
MITRE EMB3D is a threat model built for embedded devices. Generic enterprise threat catalogues assume a server, an OS and a network stack. EMB3D instead maps threats to embedded reality: boot processes, debug ports, on-chip crypto, firmware update flows. It gives auditors a shared vocabulary for what can actually go wrong on the device itself.
IEC 62443-4-2 covers the other half. It defines security requirements for components used in industrial automation and control systems. EMB3D finds the attack surface; 62443-4-2 says what a compliant component should do about it. Run them together and you get three things worth having: a map of attack surfaces, a compliance matrix showing where the device strays from the standard, and a ranked mitigation plan. That's what turns a pile of findings into a roadmap.
Firmware integrity: Secure Boot and signed updates
The first question in any embedded audit: will the device run code it shouldn't? On this board, yes. With no Secure Boot, the system would load unauthorised or modified firmware without complaint. That's unauthorised code execution, an attacker's firmware running with the device's full privileges.
Secure Boot closes that gap with a chain of trust: each stage cryptographically verifies the next stage's signature before handing over control. It's code signing applied to the boot process. And the same discipline has to reach the updates. This device had no secure update mechanism, so even a perfectly signed initial image could be swapped for an unsigned one later, and known bugs could never be reliably patched in the field. Signed firmware and signed updates are two halves of one control: verify what runs at boot, then verify whatever replaces it.
Cryptography and key storage: where TLS can still fail
For readers used to thinking about TLS, embedded systems are a good reminder: a protocol is only as strong as its implementation and the way it handles keys.
The device shipped an embedded TLS library that didn't meet the required cryptographic standard. A non-compliant stack can mean outdated cipher suites, weak or unvalidated algorithm implementations, or gaps that would fail FIPS 140 evaluation (the US government standard for cryptographic modules). FIPS 140 matters because it forces questions embedded teams skip: are the algorithms approved, are they implemented correctly, is the module's behaviour validated?
The second failure was key storage. The keys weren't held securely, so they could be extracted. This is the quiet killer of embedded crypto: you can run flawless TLS, but if the private key can be lifted off the flash or pulled over an open debug port, the encryption is theatre. Strong crypto needs both a compliant implementation and a properly secured place to keep the keys.
External and debug interfaces: JTAG, UART, SSH and HTTP
Embedded devices expose attack surfaces that pure software systems never have. This board left JTAG and UART open, which hands over low-level hardware access: read memory, extract those unprotected keys, walk straight past the software controls. Debug ports are a gift in development and a liability in production. Leave them live on shipped hardware and anyone with a minute of physical access has the keys to the device.
The network side was no better. In testing, brute-force attacks on SSH bypassed authentication outright because the credentials were weak, and dictionary attacks worked because nobody enforced password complexity. SSH brute-forcing is one of the most automated attacks on the internet; a device with weak credentials and no login throttling falls in hours. Testing also triggered denial-of-service conditions that knocked out device functionality. For industrial kit that matters a lot, since availability is often the security property that counts most. Cut down HTTP and SSH exposure, restrict access, and rate-limit login attempts. That's the baseline.
SBOM, CVE analysis and vulnerability management
Modern embedded firmware is mostly third-party code: bootloaders, crypto libraries, network stacks, OS components. A software bill of materials (SBOM) lists those components so you can check them against known CVEs. The audit included an SBOM and a dependency assessment for exactly this reason.
But an SBOM is a snapshot, and security keeps moving. New CVEs land every day against components that were clean the day the device shipped. This device had no structured vulnerability management policy: no process for watching disclosures, ranking patches, or pushing fixes. Pair that with the missing secure update mechanism and there's no realistic way to fix anything, even when a critical CVE drops.
So treat the component inventory as a living thing. The list itself is just the start. What keeps a device safe after launch is the process around it: watching new CVEs, ranking them, and patching on a schedule. Good embedded security engineering treats that lifecycle as part of the product, because the snapshot goes stale the moment you take it.
From technical vulnerabilities to business risk
Security findings get budget when you translate them into business terms. The audit framed each weakness as a chain, from technical vulnerability to security risk to business risk:
- No Secure Boot → attacker loads malicious firmware → the device gets manipulated at will, with regulatory fallout for an industrial operator.
- Weak credentials → SSH compromise by brute-force → operational disruption, right up to the DoS conditions testing triggered here.
- Insecure key storage → keys and credentials extracted → data leakage, including any personal data the device touches, which drags in obligations like GDPR.
- No secure update mechanism → software rots without patches → long-term exposure that compounds as new CVEs pile up.
For an industrial product the business end is concrete: reputational damage, regulatory trouble, financial and operational losses. Engineers act on the technical detail. The business framing is what actually gets the work funded.
Practical remediation priorities
The audit's recommendations make a sensible priority order for most embedded products:
- Enable Secure Boot so the device runs only verified firmware.
- Sign firmware and every update, and enforce cryptographic validation before anything installs.
- Restrict or protect JTAG/UART. Disable them in production, or gate them behind authentication and hardware protection.
- Swap out non-compliant TLS components for a FIPS 140-validated library where the use case needs it.
- Add secure key storage so keys can't be pulled off the device.
- Enforce strong passwords and cap login attempts to blunt brute-force and dictionary attacks.
- Restrict SSH access and cut back network-facing services.
- Turn on audit logging so security events can actually be investigated.
- Stand up vulnerability management: watch CVEs, triage, patch on a set cadence.
- Add multi-factor authentication where the device and its users can handle it.
None of this is exotic. The value of the audit is the sequencing: fix firmware integrity and credential hygiene first, before you lean on the controls that sit on top of them.
Conclusion
Embedded device security is a lifecycle discipline. It holds firmware integrity, cryptography, secure updates, interface hardening and vulnerability management together, because attackers go after the gaps between controls as much as any missing control. TLS and code signing belong in that picture, as long as they're assessed inside the whole system. On the VSC7558 device, several of the problems looked manageable on their own. What made them dangerous was how they linked up, and that's exactly what a thorough embedded security assessment is built to find.
The audit here was run by Promwad, an engineering company with 21 years behind it and 100+ in-house engineers working across embedded and industrial systems. For more details, visit https://promwad.com/
