Donjon | 01/27/2026
Enforcing BIP32 Hardened Derivation Prefixes for Enhanced Security
To significantly improve the security posture and implement a robust defense-in-depth strategy, we will soon be enforcing strict prefixes of BIP32 derivation paths for our Bitcoin application, as well as its clones.
Before You Dive In:
- Ledger will soon be implementing strict prefixes of BIP32 derivation paths for our Bitcoin application and its related clones
- This improvement eliminates a theoretical cross-application key leakage risk.
- This is a proactive, defense-in-depth security enhancement, not a fix for an active or potential vulnerability. Your current funds are not at risk.
- The threat landscape is evolving, and this upgrade ensures future cryptographic isolation and strengthens our security posture.
Rationale: Enhancing Security Isolation of Bitcoin Application & Related Bitcoin Clones
To significantly improve the security posture and implement a robust defense-in-depth strategy, we will soon be enforcing strict prefixes of BIP32 derivation paths for our Bitcoin application, as well as its clones (Dogecoin, Bitcoin Cash, etc.). This mandatory change is a critical step toward ensuring cryptographic isolation between applications, protecting your seed from application-level vulnerabilities, and limiting the “blast radius” of any potential compromise.
The Problem: Cross-Application Key Extraction
The BIP32 (Hierarchical Deterministic Wallets) standard allows a single master seed to generate an infinite tree of private keys. While incredibly convenient, sharing this seed across multiple applications (e.g., Bitcoin, Ethereum, various altcoins) introduces a fundamental security risk if one application is malicious or compromised.
The Solution: Hardened BIP32 Prefixes
Setting application-specific BIP32 hardened prefixes is the most effective defense against this scenario. By enforcing a unique set of hardened derivation prefixes per application, each app is confined to its own isolated cryptographic namespace, even when sharing the same master seed.
Compared to most of the applications, the Bitcoin application and its clones were not enforcing any BIP32 prefix, meaning that the app could derive any key, even the ones used by other apps.
Key mechanisms of this enforcement:
- Cryptographic Isolation: Each application has to be restricted to a unique set of BIP32 prefixes. This isolation mechanism is provided by Ledger’s Operating System running on the Secure Element.
- Hardening Requirement: At least one component of each prefix is required to be hardened. Fully non-hardened derivation steps are explicitly forbidden as they enable master key recovery.
By enforcing hardened prefixes, even a fully compromised or malicious application can only derive keys within its assigned, isolated subtree. It is cryptographically infeasible to move upward in the derivation hierarchy (to recover a parent key) or laterally into another application’s subtree (e.g., from the Ethereum path to the Bitcoin path).
In effect, application-specific hardened BIP32 prefixes act as a strict isolation boundary at the key-derivation layer, preventing master key leakage and ensuring that a single vulnerable application cannot escalate its access to other applications’ private keys.
Timeline
We’ll be implementing this restriction on authorized BIP32 paths within the Bitcoin app on February 26th. Following this date, any attempt to use the Bitcoin app with a non-hardened or unapproved path will result in key derivation failure.
A similar restriction will be extended to Bitcoin clones, such as Dogecoin and Bitcoin Cash, on March 26th.
We’ll introduce a method that allows users to retain access to the funds linked to newly unauthorized paths.
Impacts
For Bitcoin users who utilize common paths with their wallet, this security enhancement will be completely seamless, as those paths will remain authorized.
If you used non-standard paths or fully non-hardened ones, you can still access all your funds using the Bitcoin Recovery application and then migrate them to the currently supported paths.
A comparable method will be implemented for Bitcoin clones.
Detailed information can be found on our dedicated support page.
Enforced prefixes
The Bitcoin application will now only be able to derive BIP32 paths starting with one of the following prefixes:
- m / * / 0’ / …-> all purposes on bitcoin mainnet (0’)
- m / 45’ / … -> Multisig related keys (BIP45)
- m / 4541509′ / … -> Electrum specific prefix
For other paths, it is possible to use the Bitcoin Recovery application so users’ funds remain accessible at any time. However, we strongly recommend migrating to the new application to benefit from this security enhancement.
Bitcoin Recovery Application
To assist users during and after the enforcement period, we will be providing a dedicated Bitcoin Recovery Application starting from the enforcement date. This app can be used to access any funds associated with your seed for recovery or migration purposes.
It is designed to be highly permissive and can access keys derived from any path associated with your master seed, bypassing the strict hardened prefix enforcement of the enhanced Bitcoin application.
Use Cases:
- Fund Recovery: Accessing funds stored on legacy or non-standard derivation paths that may have been in use before this security upgrade.
- Migration: Migrating funds from older, non-standard addresses to new addresses that adhere to the BIP32 prefixes set within the official Bitcoin application.
We strongly advise using this recovery application only for necessary migration or recovery tasks, as its permissive nature means it operates outside the new, enhanced security isolation enforced by the standard Bitcoin application.
By the Ledger Donjon