Why Immutable Firmware Is the Safest Choice for Your Crypto

AI summary

Firmware is the foundational software embedded in a hardware wallet's chip. It governs every critical operation: how private keys are generated, stored, and used to sign transactions. Because firmware operates at the deepest level of the device, with direct access to the secure element where private keys reside, its integrity is essential. If firmware is compromised, the consequences are severe and often irreversible.

This article provides a comprehensive examination of the two competing approaches to firmware in hardware wallets: updatable and non-updatable (immutable). It explores documented vulnerabilities, analyses emerging attack methods, and directly responds to recent industry claims about the limitations of immutable firmware.

What is firmware in hardware wallets?

Firmware is the specialised, low-level software embedded directly into a hardware wallet's chip. It functions as the device's operating system, though it is far more constrained in scope than the software running on a computer or smartphone. Firmware controls every security-critical function: private key generation, key storage, transaction signing, and communication with companion applications.

Unlike regular applications, firmware runs directly on the hardware, giving it immediate access to the secure element, the tamper-resistant chip where private keys are kept. This special position underscores the importance of firmware integrity. If it’s compromised, an attacker could gain access to the wallet's most sensitive information.

Hardware wallet manufacturers have adopted two distinct approaches to firmware management:

• Updatable firmware: The manufacturer can release new firmware versions that users download and install on their devices. This model is used by wallets such as Ledger, Trezor, and most other major manufacturers.

• Immutable (non-updatable) firmware: The firmware is written to the chip once during manufacturing and cannot be altered afterward by the manufacturer, external actors, or any other means. This is the model used by Tangem.

On the surface, updatable firmware offers clear advantages: the ability to patch vulnerabilities, introduce new features, and adapt to threats. However, the update mechanism itself introduces substantial security risks that outweigh its advantages.

What immutable firmware is designed to protect against

Every security architecture begins with a threat model: a formal assessment of which attacks the system is designed to prevent, which risks it accepts, and where responsibility is allocated across different layers.
 

Updatable firmware creates a persistent channel for delivering code to a device after it has been sold. While this channel is intended for legitimate improvements, it also represents an attack surface that remains accessible to malicious actors throughout the device's lifespan.

Non-updatable firmware is the only commonly accepted approach for secure devices operated by end users. There are NO bank cards or e-passports that allow over-the-air firmware updates in the field. YubiKey, a hardware security key that provides two-factor and multi-factor authentication, also has immutable firmware. This is because security risks are always too high.

Let's discuss these threats:

1. Insider threats

Any organisation capable of pushing firmware updates necessarily employs individuals who can modify the code controlling users' private keys. A malicious insider, whether motivated by financial gain, ideological reasons, or external coercion, could embed a backdoor or vulnerability into an update.

The broader cybersecurity industry has documented a consistent increase in insider-driven incidents over the past decade. In hardware wallets, where a single compromised code path could affect millions of dollars in user funds, this risk is particularly consequential.

2. Social engineering

The existence of a firmware update pipeline creates a high-value target for social engineering attacks. Adversaries may attempt to manipulate employees into modifying code, sharing access credentials, or approving malicious changes through phishing, impersonation, or fabricated emergency scenarios.

The threat has escalated substantially: deepfake voice phishing attacks increased by over 1,600% in the first quarter of 2025. Any company that maintains an update mechanism must continuously defend against these evolving tactics.

3. Government coercion and regulatory pressure

In certain jurisdictions, legislation permits government agencies to compel technology companies to implement remote access or surveillance capabilities.

If a hardware wallet supports firmware updates, a government could require the manufacturer to distribute an update that grants backdoor access to user funds.

Employees may also face direct pressure from state actors, criminal organisations, or regulatory bodies. The update mechanism is the enabling vector for such coercion. Without it, the demand cannot be fulfilled.

4. Insufficient quality assurance

Not all firmware vulnerabilities are introduced maliciously. Rushed development cycles, incomplete code reviews, and inadequate testing can result in updates that inadvertently introduce new security flaws.

When a manufacturer releases updates frequently, whether for minor patches, feature additions, or interface changes, the probability of introducing an unintended vulnerability increases with each release.

5. Audit gaps

A firmware audit is a comprehensive review of source code, architecture, and development practices conducted by an independent, third-party security firm. Its purpose is to verify the absence of backdoors, assess the quality of cryptographic implementations, and evaluate compliance with industry security standards.

Thorough audits are expensive and time-intensive, often costing hundreds of thousands of dollars and requiring several months to complete. Conducting an independent audit for every firmware release is economically and logistically impractical for most manufacturers.

6. Supply chain exposure

The firmware update process constitutes a complex supply chain: code is written, reviewed, compiled, cryptographically signed, distributed through servers, and installed on the user's device.

Each stage represents a potential point of compromise. Attackers may target the build environment, intercept the distribution channel, or compromise the signing keys used to validate update authenticity. With insider involvement, an attacker could modify the update during transit, delivering compromised firmware that passes all standard verification checks.

7. Pressure on users

Manufacturers of updatable wallets often require updates to maintain compatibility with companion software. Users who decline may experience degraded functionality or loss of access to certain features.

This dynamic compels users to accept updates on trust, regardless of whether they have been independently verified. Immutable firmware removes this dependency. The device operates as delivered for its entire lifespan, without reliance on future code changes

How update mechanisms create an attack surface

The mechanism that enables patching firmware issues is itself an attack surface that persists throughout the device's lifespan.

To accept a firmware update, a device must: 

• Receive external code over a communication channel (USB, Bluetooth),
   
• Validate the code's authenticity using cryptographic signatures;
   
• Write the new code to the secure element's memory, and overwrite or replace the existing firmware. 

If the update protocol is sketchy, the communication channel between the companion app and the device's bootloader could be intercepted or spoofed through man-in-the-middle attacks at the USB or Bluetooth transport layer.

Signature verification can be bypassed if signing keys are exfiltrated or if the verification routine is circumvented via fault injection, such as voltage glitching, during verification. 

The write operation itself is vulnerable to time-of-check-to-time-of-use (TOCTOU) attacks, in which validated firmware is replaced with malicious code between the verification step and the actual flash write.

A device that lacks these capabilities presents no such attack surfaces.  

Documented risks of updatable firmware

Several well-documented incidents have demonstrated how firmware vulnerabilities can compromise hardware wallets.

1. Ledger Nano S MCU firmware replacement vulnerability (2018). 
   Security researcher Saleem Rashid demonstrated that an attacker could replace the Ledger Nano S firmware with a malicious version that would exfiltrate private keys. He managed to upload modified firmware to the wallet, which would reveal the user's private keys the next time the device was used. 
   He also claimed it was possible to upload the firmware remotely by installing malware on the victim's computer that would prompt them to update their "faulty" wallet firmware. Ledger released firmware update 1.4.1 to mitigate the issue.
    
2. Ledger Recover controversy (2023). 
   Ledger's firmware version 2.2.1 introduced a new recovery feature that enabled it to extract seed phrase data from the Secure Element and transmit it to external parties. The service launch revealed that Ledger firmware has the technical ability to extract and transmit seed phrase material. 
   
   This capability exists on every device running the updated firmware, regardless of whether the user subscribes to the service. Users pointed out that this directly contradicted Ledger's prior statement that firmware updates cannot extract private keys from the Secure Element.
    
3. Blockstream Jade firmware phishing campaign (2025). 
   Blockstream issued an urgent security alert warning about a phishing campaign targeting Jade hardware wallet owners through fake firmware update emails. The fraudulent emails masqueraded as legitimate Blockstream communications, instructing users to download firmware updates by clicking on malicious links. The fake firmware likely redirected funds to attacker-controlled addresses once installed.
    
4. Supply chain attacks against Ledger Nano X wallets. 
   Kraken Security Labs identified attacks that could allow malicious actors to take control of computers connected to theLedger Nano X wallets and install malware, potentially resulting in the loss or theft of funds stored. In this scenario, the firmware of the non-secure processor is modified using a debugging protocol to act as an input device, like a keyboard, that can then send malicious keystrokes to the user’s host computer. 
   
   The Ledger Nano X ships with the debugging functionality enabled on its non-secure processor, a feature that is disabled as soon as the first ‘app’, such as the Bitcoin app, is installed on the device. However, before any apps are installed, the device can be reflashed with malicious firmware 
   that can compromise the host computer, similar to the “BadUSB” and “Rubber Ducky” attacks.

Dark Skippy: a case study in firmware-based attacks

Disclosed in August 2024, the Dark Skippy attack represents one of the most technically sophisticated firmware-based threats identified to date. It demonstrates the severity of the risk posed by compromised firmware to hardware wallet users.

Technical overview

Dark Skippy targets the nonce generation process used during cryptographic transaction signing. Under regular operation, a hardware wallet generates a random number (nonce) each time it signs a transaction. This randomness is essential to the security of the signature scheme. The attack proceeds in four stages:

1. Firmware compromise: Malicious firmware is installed on the hardware wallet via a tampered update, a supply-chain attack, or physical access.

2. Nonce manipulation: Rather than generating random nonces, the compromised firmware produces weak, deterministic nonces derived from portions of the user's seed phrase.

3. Data exfiltration: When the user signs a transaction, fragments of the seed phrase are embedded within the transaction signature and broadcast to the blockchain.

4. Seed reconstruction: The attacker monitors the blockchain for affected signatures and applies Pollard's Kangaroo algorithm to compute the original seed phrase from the public nonce data.

Implications

Earlier variants of nonce-based exfiltration attacks required dozens of signed transactions to extract sufficient data. Dark Skippy can extract the complete seed phrase from as few as 2 transactions. A single use of a compromised device is enough to drain the wallet entirely.
 

The attack is also exceptionally difficult to detect. Compromised signatures are indistinguishable from legitimate ones to the user. No error messages, no visual anomalies, and no behavioural indicators alert the user to the breach. The extraction occurs silently, and victims may not discover the compromise until their funds have been transferred.
 

The researchers responsible for the disclosure (Lloyd Fournier and Nick Farrow of Frostsnap, and Robin Linus of ZeroSync) privately notified over 15 hardware wallet vendors in March 2024 before publishing their findings. As of this writing, Dark Skippy has not been observed in the wild, but the proof-of-concept is fully functional, and the demonstration code has been made publicly available.

The case against open-source firmware

Open-source disclosure makes source code publicly available, enabling more eyes to find bugs. This has led to security benefits in operating systems, cryptographic libraries, and network protocols.

However, open-source review is voluntary, unstructured, and offers no guaranteed coverage. There is no requirement that any specific reviewer examine any specific code path. 
 

High-profile open-source projects have harboured critical vulnerabilities for years (Heartbleed in OpenSSL persisted for over two years in widely reviewed code). The mere availability of source code does not ensure that it has been competently reviewed, nor does it ensure that reviewers have the specialised expertise required for secure element firmware.

Additionally, publishing the source code for hardware wallet firmware introduces its own risks. It provides adversaries with a detailed map of the system's internals, potentially enabling targeted attacks against implementation-specific behaviours. 

This is why Tangem employs a security-through-depth approach: the firmware is closed-source but formally evaluated by accredited experts, while the companion app and SDK are fully open-source on GitHub.

Tangem's immutable firmware architecture

With Tangem, the firmware is loaded onto the secure element during manufacturing and cannot be modified or replaced afterward. There is no update mechanism, no USB interface for firmware flashing, and no wireless channel for over-the-air updates. The secure element is architecturally designed to reject any attempt to write new code after the initial installation.

Addressing Ledger’s claims

Ledger has publicly commented on Tangem several times, and its own security research team has conducted extensive research on us. That context is worth keeping in mind as we address claims circulating about Tangem.
 

Claim: "Freezing the system doesn't protect users, it protects the attacker."

This statement suggests that immutability is merely inaction, making it sound as if a static system might be less safe; in fact, it is the common approach. As we mentioned earlier, your credit cards, passports, and YubiKeys all carry immutable firmware. An immutable system cuts off the attacker's most powerful remote tool: injecting malicious code through updates. 

Ledger's approach is rather uncommon and risky; each firmware update issued provides an attacker with a new opportunity.
 

Claim: “Tangem's audit gaps leave multi-year periods without external scrutiny.”

Ledger argued that Tangem's two audits (2018 by Kudelski and 2023 by Riscure) leave gaps where external scrutiny is absent. This audit gap argument has less force against immutable firmware than against updatable firmware. When firmware changes between audits, the unaudited period involves running new, unreviewed code. When firmware is immutable, the unaudited period involves running the same code that was previously reviewed.
 

Claim: “Tangem cannot adapt to new cryptographic curves or blockchain protocols.”

Previously, Ledger has argued that immutable firmware cannot support new cryptographic curves, potentially leading to obsolescence. However, this conflates two architectural layers.

Tangem's firmware implements core cryptographic primitives (ECDSA and EdDSA) used by the overwhelming majority of blockchain networks. 

Support for new blockchains, token standards, and protocols is implemented in the companion app at the application layer, not in the firmware. Tangem currently supports over 85 blockchains and more than 16,000 tokens, and continues to add new networks through app updates without modifying the card's firmware. 

Claim: “Any issue found in the Tangem Firmware cannot be fixed.”

The risk posed by an unpatched vulnerability in immutable firmware must be weighed against the risks introduced by the update mechanism itself. As demonstrated throughout this article, the update pipeline introduces persistent threats.
The relevant question is not whether immutable firmware is free of tradeoffs, but whether the net security position is superior. The evidence strongly supports that conclusion.

Independent audit timeline

Transparency about security evaluation is essential for user trust. Tangem's complete independent audit history proves our commitment to future evaluations.
 

Frequently asked questions

What happens if a vulnerability is discovered in Tangem's immutable firmware?

It’s a very unlikely scenario. Tangem's firmware has been independently audited by two leading security firms (Kudelski Security and Riscure), significantly reducing the probability of an undetected critical flaw.

Can an attacker install malicious firmware on a Tangem card?

No. The secure element chip is architecturally designed to reject any firmware write operation after the initial factory installation. There is no interface or mechanism for delivering new code. Even with physical possession of the card, an attacker cannot modify the firmware.

What is Dark Skippy, and does it affect Tangem?

Dark Skippy is a firmware-based attack method disclosed in 2024 that can extract a wallet's complete seed phrase from as few as two signed transactions. It operates by replacing random nonces in the signing process with deterministic values derived from the seed.
Dark Skippy requires malicious firmware to be present on the device. Tangem's firmware is immutable and cannot be altered after manufacturing, so this attack vector does not apply.

Is immutable firmware simply a way to avoid the complexity of updates?

No. It is a deliberate security architecture decision that eliminates entire categories of risk: insider threats, social engineering, regulatory coercion, supply chain attacks, and the audit gap inherent in frequent firmware releases.

Are there limitations to immutable firmware?

The primary tradeoff is that new functionality cannot be added to the firmware post-production. However, the majority of feature improvements, new blockchain support, and user experience enhancements are delivered through Tangem's companion mobile app, which is regularly updated and fully open source.

What does EAL6+ certification mean?

EAL6+ (Evaluation Assurance Level 6, augmented) is one of the highest security certifications available under the Common Criteria international standard (ISO/IEC 15408). 
It signifies that the chip has been semi-formally verified and rigorously tested against sophisticated physical and side-channel attacks. The same certification level is required for international passports, national identity documents, and high-security government payment systems. A detailed overview of Tangem's security architecture is available in the security features documentation.

Why is Tangem's firmware closed-source if the app is open-source?

The firmware runs inside a certified secure element and performs a narrow set of cryptographic operations. The companion app, which handles user-facing functionality and interacts with blockchains, benefits from broad community scrutiny and is fully open-source on GitHub. This layered approach matches the verification method to each component's risk profile.

References

• Dark Skippy Official Disclosure — The original research paper and technical FAQ from the security researchers who identified the attack. darkskippy.com
   
• Merkle Science: Dark Skippy Threat Analysis — Detailed technical analysis of the Dark Skippy attack vector and its implications for hardware wallet security. www.merklescience.com
   
• Common Criteria Portal (ISO/IEC 15408) — The international standard governing EAL security certification for hardware components, including secure elements. www.commoncriteriaportal.org
   
• Cointelegraph: The Hidden Risk of Updatable Firmware — Industry reporting on the security implications of firmware update mechanisms in hardware wallets. cointelegraph.com
   
• CryptoSlate: Dark Skippy Technical Coverage — Technical reporting on the Dark Skippy proof of concept and its disclosure timeline. cryptoslate.com
   
• Saleem Rashid: Breaking the Ledger Security Model — Original 2018 research demonstrating MCU firmware replacement on the Ledger Nano S. saleemrashid.com