If all derivation were hardened, HD wallets would lose the ability to generate receiving addresses using only a public key — and that is exactly the feature modern wallets rely on most. Hardened derivation is designed to isolate risk, not to replace non-hardened derivation. In BIP32, each type has its own role: hardened derivation is used at the account level and above, while non-hardened derivation is used inside an account, for the change chain and address index. This is the standard structure followed by mainstream wallets like Trezor.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
What problem does non-hardened derivation solve?
A core selling point of BIP32 hierarchical deterministic wallets is that you only need to back up your seed once, and all keys can then be derived from it. But there are two ways to derive keys, depending on how much the public key and private key are involved.
Non-hardened derivation allows you to calculate child public keys using only the parent extended public key, or xpub, without any private key. This means a device or server that only holds an xpub can generate an unlimited number of receiving addresses, monitor balances, and display address lists, while the private key stays offline. The watch-only mode of a hardware wallet, address generation services at exchanges, and multisig custody services like Casa all depend on this ability.
If everything were hardened, every address generation would require the private key to be present. For a hardware wallet, that means every time you want to see a new address, you would need to plug in the device and confirm. For services that need to generate addresses in bulk, hardened derivation would make the architecture cumbersome, because the private key cannot leave the secure environment, while public key derivation can be safely outsourced to an internet-connected server.
What does hardened derivation protect against?
Non-hardened derivation has a clear security trade-off: if someone knows the parent xpub and any one child private key, they can work out the parent private key, which then compromises all sibling keys under that xpub. This risk is not theoretical; it is built into the mathematical structure of BIP32.
Hardened derivation cuts off this reverse path. Because hardened derivation uses the parent private key in the hash calculation instead of the parent public key, you cannot derive the parent private key from a child private key, and you also cannot derive a hardened child public key from the parent public key. The cost is what we mentioned above: without the private key, you cannot even calculate the child public key.
Standards like BIP44 use hardened derivation at the account level of the path, such as m/44'/0'/0', and use non-hardened derivation for the change and address index levels below the account. This is exactly how they balance security and usability. Accounts are isolated from each other: if a child private key from one account leaks, it does not endanger the master seed or other accounts. But within the same account, you can freely generate addresses with an xpub, making it easy to receive payments and monitor activity. This is also why Ledger has pushed for hardened path migration: if a user manages multiple coins with the same seed, a single leaked private key under a non-hardened path could affect other assets. Hardened isolation reduces this cross-account risk.
A concrete example
Suppose you have a hardware wallet with the path m/84'/0'/0'/0/0, which is BIP84 for native SegWit. The first three levels, 84'/0'/0', are hardened, and the last part, 0/0, is non-hardened.
If you connect the hardware wallet to watch-only software, the software receives the account-level xpub, which is the extended public key for m/84'/0'/0'. The software can then derive 0/0, 0/1, 0/2, and all other addresses on its own, so it can display receiving addresses and monitor balances. The private key stays inside the hardware device. The software cannot sign transactions, and it cannot reverse-engineer the account private key.
If the account level were also non-hardened, then once one of your change address private keys leaked on an internet-connected device, for example if the software were compromised, an attacker could use that child private key and the account xpub to recover the account private key, and then control all funds under that account. Hardening at the account level cuts off that chain.
When should you care about this difference?
You do not need to choose the derivation method manually. Wallet software already configures it according to the standard when generating keys. But there are two situations where you should pay attention.
When restoring a wallet, if the software asks for a derivation path or address type, it is really asking which hardened and non-hardened combination to use to derive your keys. If you choose the wrong path, you will see a zero balance, because the software derives a different set of addresses than the ones you originally used to receive funds. Your coins are not lost; the derivation route is simply wrong. When restoring the same seed in different wallets, it is much easier to confirm in advance that both sides support the same path standard, such as both recognizing the BIP84 structure m/84'/0'/0', than to troubleshoot afterward.
When using watch-only mode or connecting to a third-party service, the path level of the xpub you provide determines how much the other party can see and what they can generate. Providing an account-level xpub is common practice, because it only exposes the address tree for that account. Providing a higher-level xpub exposes more. The position of the hardened levels determines how far your xpub can reach, and also how wide the risk spreads if it leaks.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- Trezor·What are BIPs and SLIPs?，2026-10-26
- Casa·Ledger and Hardened Derivation Paths: what's changing and what It means for your vault，2026-10-26
- IACR ePrint·Hierarchical Deterministic wallets (BIP32 security analysis)，2026-10-26
- IACR ePrint·Lattice HD Wallets: Post-Quantum BIP32 Hierarchical Deterministic Wallets，2026-10-26
- GitHub·Chaincode (BIP32 non-hardened leak mechanism)，2026-10-26
