Why Software-Only Device Trust Fails

The case for hardware-rooted identity in field-deployed devices is not "hardware is more secure than software". The case is sharper. The threat model that field-deployed devices actually face — physical access, indefinite attacker dwell time, fleet-scale cloning — rules out software-only key storage as a defensible architecture. This piece walks the four failure modes that make this the case, why each one is structural rather than implementation-defect, and what changes when the keys move into a tamper-resistant boundary.

A persistent pattern in deployment reviews: an engineering team builds a connected device with cryptographic identity stored in firmware, ships it, and only learns about the threat model when a security researcher publishes a teardown. By that point the deployment is in the field. This piece is the threat-model walkthrough that should precede the build, not follow the disclosure.

The environment, not the algorithm

The first observation is the one that gets argued against most. Software-only key storage is not insecure because the cryptography is weak. The cryptography is fine; ECDSA-P256 over SHA-256 is well-studied, well-implemented, and resistant to every published attack. The problem is not the algorithm. The problem is where the key lives.

A laptop’s threat model assumes the device is under the user’s control, the OS is patched, and the attacker is on the network. A datacentre server’s threat model assumes physical access is controlled by the operator. Both environments leave the cryptographic-key-storage problem easy enough that software-only solutions work in practice.

A connected-vehicle OBU, a smart-meter endpoint, an industrial sensor node on a factory floor, a roadside unit on a pole — none of these environments share the laptop’s or the server’s assumptions. The device is physically reachable by parties who are not the operator. The attacker has time. The mitigations that work in controlled environments do not transpose. This is the environmental gap the threat model traces.

The four failure modes

Software-only identity in field-deployed devices fails in four predictable, well-documented ways. Each one has produced shipped-and-recalled deployments at multiple companies in the last decade. None of them are theoretical.

1. Flash extraction

The most direct attack. The device’s firmware and flash contents are read out by an attacker with bench equipment. Three vectors recur.

• Debug interface left exposed. JTAG, SWD, or vendor-specific debug pins that were used during development and never permanently locked. The attacker connects a debug probe and reads the flash through it. Lock bits help; they are not always set correctly, and several MCU families have published vulnerabilities in their lock-bit enforcement.
• External SPI flash. Many cost-sensitive designs put the firmware in an external SPI flash chip rather than the MCU’s internal flash. An attacker with a SOIC clip and a logic analyser reads the flash in-situ. If the firmware is encrypted, the decryption key is in the MCU; if the MCU is also extractable, both halves of the puzzle are available.
• Decapsulation. The advanced case. An attacker with a chemical-etch workbench exposes the MCU die and reads the on-die flash directly through optical or electrical probing. Expensive, but a one-time cost that yields fleet-wide cryptographic material if the keys are software-stored and shared.

A private key stored as bytes in flash — even encrypted under a flash-resident key — is bytes in an attacker’s possession after a successful extraction. The mitigations available in software (key derivation from a fused root, encryption-at-rest, anti-rollback counters) all assume the firmware is the unit of protection. If the firmware can be read, the unit of protection is wrong.

2. Firmware extraction with key reuse

The compounding failure. Extracting one device’s firmware reveals the cryptographic patterns the entire fleet uses. If the per-device key is derived from a shared master in firmware — the design pattern many cost-sensitive deployments use to avoid factory-side per-device key injection — the firmware extract yields the master. One device’s firmware now provides the cryptographic key to clone, impersonate, or sign on behalf of every other device in the deployment.

The variants of this pattern are common enough to enumerate:

• Shared master in firmware, per-device key derived from MAC address. (Master leak yields whole fleet.)
• Shared signing key for OTA update verification. (Key leak yields ability to push any firmware to any device.)
• Shared session-establishment key for cloud telemetry. (Key leak yields ability to impersonate any device to the back end.)
• Single attestation key for the entire product line. (Key leak yields ability to enrol any forged device into the fleet PKI.)

Each of these has shipped in production deployments. Each has been published. None of them are bugs that a careful firmware engineer would catch on review; they are architectural decisions made because the alternative (per-device factory injection under HSM custody) was not in the original BOM. The architecture itself is the failure.

3. Key cloning

A device with software-stored identity can be cloned: the bytes are copied to a second device, and now two devices present the same cryptographic identity. Three operational consequences follow.

• Forged participation. A cloned V2X OBU broadcasts safety messages signed under a credential the PKI accepts. The receiving fleet has no architectural way to distinguish the cloned signer from the original.
• Geographic amplification. A cloned device can sign messages in a geography the original does not occupy. A single attacker amplifies a hazard signal across regions it physically cannot reach.
• Revocation paralysis. The operator cannot revoke the cloned credential without revoking the original. If both are still doing something legitimate, revocation is destructive.

Hardware binding inverts this property. Cloning a hardware-bound identity requires copying the silicon, which is not a software-attack-class operation. The economics, not the impossibility, are the defence.

4. Fleet compromise from a single device

The compounding failure mode that turns one extraction into a deployment-ending incident. A successful extract on one device, given software-only identity with shared cryptographic structure, yields the cryptographic technique used across the fleet. The marginal cost of compromising the second device is near zero. Whether the fleet is one device or one million, the per-device attack cost is the cost of one attack.

Hardware-bound identity has the opposite property. Every device requires its own attack, against its own silicon, with no scaling discount. The aggregate cost of compromising N devices is N times the cost of one attack, indefinitely. This is the single most important architectural property hardware binding provides — it is the property that takes deployment-scale risk from "unbounded" to "bounded by per-device attack economics".

// Software-only vs hardware-bound: attack cost vs fleet size

  Cumulative attack cost
       │
   $$$ │            ┌── hardware-bound:
       │            │   linear in fleet size
       │            │   (each device its own attack)
       │           ╱
       │          ╱
       │         ╱
       │        ╱
       │       ╱
       │      ╱
       │     ╱
       │    ╱─── software-only:
       │   ╱     near-flat after first extract
       │  ╱      (one attack → fleet)
       │ ╱
       │╱
       └────────────────────────────────────► Fleet size

      The slopes are the architecture.

Where software-only trust does survive

Worth saying explicitly: software-only key storage is not always wrong. Three environments where it is the right architectural choice.

• Server-side keys in a datacentre with controlled physical access. The physical-access assumption holds; the threat model is network-side; software-only TLS keys are fine for the application server tier. (The CA underneath them usually still sits behind an HSM.)
• Ephemeral session keys generated and consumed entirely within one runtime. A TLS session key derived for a single connection lives a few seconds and is wiped when the connection closes. Hardware backing adds nothing.
• Devices in physically-secure operational contexts. A networking appliance in a locked cabinet on premises has a different threat model from a meter on a customer’s wall. Software-only identity may be defensible in the first case.

The unifying property of "where software-only works" is that the physical-access assumption holds. In V2X, industrial IoT, smart metering, and edge infrastructure, it does not. That is where the architectural conclusion changes.

Software-only vs TPM vs secure element

The three architectural options for "where does the key live", scored against the four threats above.

For server-class and PC-class devices, TPMs are the dominant deployed answer. For embedded V2X, IoT, smart-meter, and edge devices, the secure element is the dominant answer because of applet ecosystem, form factor, and power envelope. Secure element vs TPM vs HSM goes deeper into the device-class boundaries.

Three deployment domains where the threat is concrete

V2X / connected mobility

An OBU broadcasts position, speed, and signed safety messages at 10 Hz on PC5 sidelink. Software-only identity in this context produces every failure mode at once: cloned OBUs amplify hazard signals across geographies they don’t occupy; extracted firmware yields the cryptographic technique for the entire fleet; the PKI’s revocation channel cannot tell the cloned OBU from the original. The V2X PKI architecture described in how V2X PKI works was designed against this threat model and assumes hardware binding as a baseline; software-only deployment of V2X identity defeats the architecture it sits inside.

Industrial IoT

A sensor node on a factory floor, a vibration monitor on a turbine, a level sensor on a tank farm. The device is reachable by anyone with maintenance access. The fleet is in the thousands or tens of thousands. The credentials authenticate the device to a cloud telemetry endpoint and authorise it to actuate (open a valve, change a setpoint). A single extracted credential authorises any forged device to issue commands. The mitigations from cloud-side (rate limiting, anomaly detection) help; they do not replace the hardware boundary that should have held the key.

Edge infrastructure

Smart-meter endpoints, electric-vehicle chargers, transit validators, kiosk hardware. Devices owned by infrastructure operators but sited on customer premises or in public locations. Threat actors include both opportunistic local attackers and sophisticated supply-chain or insider threats. The credential authenticates the device to the operator’s back end and (in many cases) authorises a financial transaction. Software-only credentials in this domain are the recurring root cause of "merchant terminals cloned and used to steal customer credentials" incidents that periodically make security news.

Replay and downgrade

Two specific attack patterns worth calling out because they are often confused with "the cryptography failed" when in fact they are pure environmental failures.

Replay

An attacker captures a valid signed message and replays it later, in a different context, where it looks valid again. In software-only systems with no anti-replay state (or with anti-replay state stored in attacker-rewriteable flash), replay is a one-line attack. In hardware-bound systems with anti-replay counters held inside the secure element, replay requires defeating the counter, which is a tamper-attack-class operation.

Downgrade

An attacker convinces the device to accept an old firmware version (or an old protocol version) with known vulnerabilities. In software-only systems, the rollback counter is in attacker-rewriteable flash. In hardware-bound systems, the monotonic counter is inside the secure element. The downgrade still has to convince the SE to accept a lower version; the SE checks against its internal counter and refuses.

Both replay and downgrade are "the cryptography is fine; the storage of the anti-replay or version state is the wrong place". Hardware binding fixes them by putting the state in the right place.

The economic argument

Engineers tend to argue this on technical grounds. The procurement-facing version is shorter: hardware-rooted identity makes fleet compromise expensive in a way the deployment’s threat model can absorb.

Consider two parallel deployments of a million devices each, one with software-only identity and one with hardware-bound identity. An attacker decides to compromise the fleet.

• Software-only fleet. Attacker buys one device, extracts firmware (assume $50K of equipment plus a few weeks of researcher time). The extraction yields cryptographic material that authorises forged participation across the fleet. Cost to compromise one device: ~$50K. Cost to compromise the millionth: also ~$50K, because the first attack’s output is reusable.
• Hardware-bound fleet. Attacker buys one device, extracts the host firmware (same $50K), and discovers the keys are not in firmware. Per-device silicon attack against the SE: typically $200K–$500K of equipment plus months of dedicated researcher time, per device, no scaling discount. Cost to compromise one device: ~$300K+. Cost to compromise the millionth: ~$300 trillion+ — uneconomical at any meaningful attacker scale.

The exact dollar figures vary by silicon class and attacker capability. The structural point does not. Hardware binding moves the deployment from "attacker economics scale with N=1" to "attacker economics scale with N=fleet size". This is the single most important property a fleet operator buys when paying for hardware-rooted identity.

OTA trust as the second domain

The argument extends naturally to firmware-update trust. A software-only deployment cannot defensibly verify firmware updates: the verification key lives in flash that the firmware itself can rewrite. The chicken-and-egg problem is well-known; the practical resolution is to put the verification key inside the secure element and have the boot ROM ask the SE whether a candidate firmware image’s signature verifies before installing it.

Secure elements in connected vehicles covers the SE role in secure boot and OTA verification. The architectural point: OTA trust is the second area where the boundary between software and hardware decides whether the deployment’s long-term integrity story holds together.

Counterarguments worth addressing

"Modern MCUs have secure enclaves"

Many do — ARM TrustZone-M, Cortex-A TrustZone, Espressif’s Secure Boot V2 with HMAC keys in eFuses. These are real improvements over flat-firmware designs. They are also typically not certified at chip level for tamper resistance, do not have the applet ecosystem to host V2X / FIDO / PIV identity logic, and integrate the secure boundary into the same silicon that runs the application firmware. They raise the bar; they do not match the discrete-SE bar. For some deployments, that’s enough. For V2X OBUs and other high-assurance contexts, it usually is not.

"We will encrypt the firmware"

Encrypting the firmware at rest moves the problem rather than solving it. The decryption key is in the MCU; if the MCU is extractable, both halves are recoverable. Firmware encryption raises the cost of casual extraction; it does not change the architectural failure mode against a determined attacker.

"We will use obfuscation"

Obfuscation raises the cost of static analysis. It does not move the key out of the firmware. Once the key is in an attacker’s memory, the obfuscation is bypassed (the attacker runs the firmware in an emulator and lets it deobfuscate itself). Defence-in-depth has value; defence by obfuscation alone is not a substitute for hardware binding.

"Our threat model doesn’t include physical access"

For some deployments — locked-cabinet networking appliances, badged-access-only datacentre hardware — this is genuinely true. For V2X, IoT, smart metering, payment terminals, and edge infrastructure, the threat model that excludes physical access is the threat model that is wrong, not the threat model that is correct. The deployment’s actual environment is the constraint.

Implication: architecture before implementation

The conclusion this piece converges on is not "use a secure element because secure elements are better". The conclusion is sharper: software-only device identity is an architectural choice that does not survive the threat model field-deployed devices actually face. The choice is not between "harder software" and "easier hardware"; the choice is between "an architecture that fails predictably" and "an architecture that bounds the attacker’s economics".

The architectural alternative — hardware-rooted identity in a discrete tamper-resistant secure element, per-device unique keys injected at factory under HSM-backed custody, OTA credential lifecycle layered on top — is documented across this site. It is not exotic. It is the settled engineering answer to a settled engineering question. The cost is the SE silicon, the personalisation line, and the applet engineering. The cost of getting it wrong is a fleet whose identity story does not survive a single laboratory attack.

What AmbiSecure ships against this threat model

• IoT Security Co-Processor — discrete tamper-resistant secure-element silicon class. Underlying secure-element silicon CC EAL5+ at chip level. The boundary that holds keys out of host firmware.
• HSM-backed personalisation lines — per-device unique key injection under split-knowledge custody. The factory-side defence against shared-key fleet leak.
• JavaCard applets — applet ecosystem for V2X EC/PC management, FIDO, PIV, OpenPGP, eUICC identity. Multi-applet co-residence under GlobalPlatform 2.3.1.
• JavaCard development services — custom-applet engineering for deployments whose credential-management logic does not fit a standard applet.

The explicit boundary, also on the trust page: AmbiSecure provides hardware-rooted identity primitives. AmbiSecure does not operate V2X PKI authorities, does not ship turnkey OBU / RSU products, and does not claim ISO 26262 or ASPICE certification of the integrated AmbiSEC Module.

Related reading

• Secure elements in connected vehicles — the hardware side of the alternative architecture.
• How V2X PKI works — an architecture explicitly designed against this threat model.
• Device identity at manufacturing scale — the factory provisioning side.
• Secure element vs TPM vs HSM — the device-class comparison.
• Why hardware-backed identity matters — the user-identity case for the same architectural point.
• Secure elements technology page · Solution: device identity at scale.