Business Use: Managing Employee Crypto Holdings with Ledger Live

A growing number of companies now hold cryptocurrency as part of treasury operations, employee compensation programs, or client asset management. Unlike traditional securities held through established custodians, crypto requires direct management of private keys, wallet access, and transaction authorization. A single employee with unsupervised signing authority creates concentration risk; a process requiring no written record of transactions creates audit problems. The challenge for a company is not whether to adopt crypto, but how to manage it with the same institutional controls applied to bank accounts, investment portfolios, and other sensitive assets.

Ledger Live, now called Ledger Wallet, is designed primarily for individual users connecting Ledger hardware devices to manage personal accounts. Yet its underlying architecture—private keys stored on hardware rather than in software, support for multiple accounts and cryptocurrencies, transaction preparation and review before signing—aligns with several institutional requirements. The practical question is whether and how a company can use the application as part of a custody and governance framework rather than as a consumer tool, and what gaps remain between what the application provides and what responsible organizational management demands.

How institutional asset management differs from personal custody

A person with a single Ledger device and one recovery phrase controls their assets through a straightforward workflow: connect the device to a computer running Ledger Wallet, sign transactions, approve fund transfers. Responsibility is undivided and recovery is contained—if the device is lost, the recovery phrase rebuilds access. An organization managing company funds cannot operate under the same model because it must distribute signing authority, create oversight, maintain audit trails, and define what happens when an authorized signer leaves or becomes unavailable.

Multi-signature schemes address part of this requirement. Rather than one person controlling an account through a single key, the account’s balance is protected by multiple keys held by different people. A transaction requires signatures from a specified threshold—two of three, three of five, and so on—before the blockchain accepts it. This prevents any single person from unilaterally moving company assets. Bitcoin, Ethereum, and many other cryptocurrencies support multi-signature addresses through contracts or native protocols. Ledger devices can hold individual keys as part of a multi-signature setup, and Ledger Wallet can prepare and partially sign transactions, but the coordination between signers typically occurs outside the application.

The gap between application features and organizational requirements becomes immediately apparent. Ledger Wallet is not designed to enforce or track multi-signature authorization workflows. It cannot require that a second person approve a transaction before it is broadcast to the network. It cannot maintain a persistent record showing who signed, when, and what instructions they followed. It cannot prevent a prepared transaction from being modified by someone with access to the computer before the second signer reviews it. For a small company moving five million dollars, those are material limitations, not convenient shortcuts.

The correct institutional approach typically involves a dedicated custody platform that supports multi-signature coordination, maintains immutable audit logs, enforces policy rules such as spending limits or transaction timing windows, and integrates with the company’s accounting and approval processes. Ledger provides the hardware security—the private keys themselves—but the Ledger Wallet application is the consumer interface, not the institutional platform.

Hardware isolation and the responsibility distribution problem

One institutional advantage of Ledger devices is that they isolate signing from network exposure. A transaction is prepared on a computer, the computer displays it to a connected Ledger device, the device’s isolated processor reviews and signs the transaction, and the signed result returns to the computer for broadcast. The private key never leaves the device and never runs on the general-purpose computer. If the computer is compromised by malware, the attacker cannot steal the key or forge signatures. If the network connection is intercepted, only the unsigned transaction data can be read.

However, that hardware isolation also creates a coordination challenge in a multi-person organization. If three people need to sign a transaction, they cannot pass a single Ledger device around. Each person needs their own device, or they need a process for using one device at different times while ensuring that each person’s review is independent and recorded. Ledger devices support multiple users through different PIN codes and passphrases, but switching between users on a shared device requires physical access and time, which is inconvenient and auditable only if documented separately.

A more practical institutional arrangement involves hardware wallets held by different people—perhaps in different physical locations or access-controlled rooms. Each person holds a Ledger device and one key of the multi-signature wallet. When a transaction needs approval, the person with the computer prepares it in Ledger Wallet, connects their device, signs it, and the partially signed transaction is transferred to the next person. This requires secure transfer of the unsigned transaction between locations and a clear record of who received it and when.

The responsibility distribution challenge is deepest when an employee leaves the company. If that person held one of three keys in a multi-signature wallet, the company must recover or recreate the key, change the wallet configuration, or migrate funds to a new arrangement. A hardware wallet containing a single key is useless to the company if the key is lost; a hardware wallet in the employee’s possession cannot be transferred without risking exposure of the recovery phrase. The institutional solution is usually a cold storage facility, a formal key recovery process, or the use of a third-party custody provider that holds keys on behalf of the organization and enforces its policies centrally.

Multi-signature coordination and transaction auditing

Ledger Wallet can prepare transactions for multiple accounts, display destination addresses, and show estimated fees. When a hardware device is connected, it allows signing. For a two-of-three multi-signature arrangement, the signed output from one person can be shared with the next person, who connects their own Ledger device and adds a second signature. The transaction can then be broadcast. This workflow is feasible for occasional transactions but becomes burdensome at scale and lacks the audit integration a company typically needs.

An institutional custody provider or multi-signature coordination platform solves this by creating a persistent record: who viewed the transaction, when, what comments or approvals they left, and whether they signed. The record integrates with accounting systems, enables reporting to auditors, and provides evidence in case of dispute or investigation. Ledger Wallet, by design, does not maintain that record. Each person using their own computer can see their own transaction history in the application, but there is no central ledger showing the company’s complete signing activity.

The absence of this record is not a flaw in the application—it is a design choice reflecting that Ledger Wallet is meant for individual asset managers, not organizations. However, a company using Ledger devices in a multi-signature arrangement must create its own transaction auditing process outside the application. A spreadsheet, a dedicated database, or a workflow platform must track each multi-signature transaction request, who received it, when they signed, and the final on-chain result. This additional layer is the company’s responsibility, not the application’s feature.

Policy enforcement and spending controls

Institutional asset management typically includes policies defining who can sign transactions, what transaction limits apply, and what approval sequences are required. An employee might be authorized to approve a $10,000 payment without additional review, while a $100,000 payment requires two approvals, and a $1 million payment requires three approvals plus review by the CFO. These rules should be enforced by the custody system itself, not left to human judgment during transaction signing.

Ledger Wallet does not enforce policies. It displays transaction details, allows signing by anyone with access to a connected device, and broadcasts whatever the user approves. The company must enforce policies through process: the person preparing the transaction must verify that it complies with policy before it is signed, and the signers must confirm compliance before signing. This works for a small organization where financial controls are tight and trust is high, but it scales poorly and leaves room for error.

Some multi-signature coordination platforms and cold storage providers do enforce policies at the system level. They require that a transaction match policy rules before allowing any signature. A $1 million Ethereum transfer might be rejected by the system even if three authorized people attempt to sign it, because the policy specifies a daily limit of $500,000. This is stronger than process-based control because it is enforced by the software infrastructure rather than by human review.

For a company using Ledger devices and Ledger Wallet as the signing layer, the policy enforcement must exist in the transaction preparation step or in a separate approval system. The person using Ledger Wallet to prepare the transaction is responsible for ensuring it complies with policy. A workflow system outside Ledger Wallet might require a manager’s approval before the transaction is even prepared. The responsibility for policy compliance rests with the organization’s process, not with the application.

Integration with accounting, compliance, and reporting

Finance teams need to account for cryptocurrency holdings, compute cost basis for tax purposes, track realized gains and losses, and report to auditors. Ledger Wallet provides portfolio views showing balances in multiple cryptocurrencies, historical transaction records for accounts connected to the application, and estimated portfolio values. This information is useful for personal portfolio tracking but insufficient for institutional accounting and compliance.

An institutional setup requires exporting transaction data in formats that accounting software can import, maintaining records of cost basis at the time of acquisition, reconciling on-chain blockchain records with internal accounting records, and tracking off-chain events such as hard forks, airdrops, or staking rewards. Many of these records must be retained for tax and audit purposes. Ledger Wallet can provide transaction history exports, but the data is limited to what occurred within the application on that computer—transactions signed elsewhere or prepared by other people would not appear.

Institutional custody providers and dedicated crypto accounting platforms integrate with blockchain explorers, exchange APIs, and staking services to provide comprehensive transaction records. They allow tagging transactions for accounting purposes, assigning them to cost centers or projects, and exporting reports in formats that auditors and tax professionals expect. Using Ledger devices for signing but relying on another system for accounting and compliance is feasible but creates reconciliation work and potential for error. A company considering this guide to implementing Ledger Wallet in an institutional setting should budget for additional accounting and compliance infrastructure beyond the application itself.

Cold storage, key rotation, and disaster recovery

An organization holding significant cryptocurrency should store keys in cold storage—meaning offline, isolated from network-connected computers and not exposed to internet-facing systems. Ledger devices are designed to support cold storage: a device can be used offline, recovered from a recovery phrase if lost, and store multiple accounts. However, the practical implementation of institutional cold storage involves additional steps that Ledger Wallet does not directly address.

Key rotation—replacing old keys with new ones—is an institutional security practice. If a key has been stored offline for five years, an organization might replace it with a new key, migrate funds to a new address, and retire the old key. This prevents an old backup or a key holder from becoming a single point of future vulnerability. Ledger devices support creating new accounts and receiving at new addresses, but key rotation in a multi-signature arrangement is more complex. All signers must create new keys, a new multi-signature contract must be deployed, funds must be migrated, and the transaction must be coordinated and audited.

Disaster recovery planning is equally important. What happens if a key holder becomes unavailable? What happens if a Ledger device is lost or fails? What happens if a recovery phrase is lost or corrupted? A company should have tested procedures for recovering access to funds using recovery phrases, replacing a compromised device, or reconstituting a multi-signature wallet if one of several keys is lost. These procedures should be documented, practiced, and separate from normal operations. Ledger Wallet supports recovery from a recovery phrase, but a company’s broader disaster recovery plan should be defined outside the application.

Cold storage also implies that devices and backups are stored in secure locations—perhaps a safe-deposit box, a vault, or a secure facility—and access is logged. Ledger Wallet runs on computers that may be internet-connected, which is appropriate for transaction preparation but not for storing the only copy of critical backups or recovery information. The organization’s security policy must define where devices, recovery phrases, and backups are physically located, who has access, and how access is monitored and logged.

Practical implementation: Layers of institutional custody

A realistic institutional approach to managing employee or company crypto holdings using Ledger devices typically involves multiple layers. The first layer is the hardware security itself: private keys are stored on Ledger devices, not in software wallets or on internet-connected servers. The second layer is key distribution: if multi-signature is required, different keys are held by different people or in different physical locations. The third layer is transaction preparation and review: the person preparing a transaction uses Ledger Wallet to create it, and authorized signers review and sign using their own Ledger devices. The fourth layer is external auditing and compliance: a separate system or process records which transactions were signed, by whom, and when, and integrates with accounting and tax procedures.

The company might also use a dedicated multi-signature coordination platform on top of Ledger. Services such as Casa, Unchained, or Fireblocks add the institutional features that Ledger Wallet does not provide—policy enforcement, centralized audit logging, and integration with accounting systems. The Ledger devices still hold the keys and perform the actual signing; the coordination platform manages the workflow and maintains the records.

Alternatively, a company with smaller holdings might use Ledger devices for cold storage and a more traditional infrastructure for custody. A single employee with a Ledger device holds the company’s cryptocurrency address and guards the recovery phrase in a safe-deposit box. A qualified custodian, such as an institutional crypto service provider, holds additional funds and handles day-to-day transactions under the company’s instruction. This hybrid model reduces the friction of managing Ledger devices while limiting exposure to any single entity or person.

The hardware isolation of Ledger remains valuable in every scenario. The private key itself cannot be stolen from a computer because it never leaves the device. Malware cannot forge transactions because signature operations occur in the isolated processor. The crypto portfolio manager function in Ledger Wallet—showing balances, transaction history, and account details—helps the organization track what it holds, but does not replace the need for separate institutional controls.

Limitations to acknowledge upfront

Ledger Wallet is powerful for individual asset managers but not designed as an institutional custody platform. The application cannot enforce spending policies, maintain audit trails of who approved what, coordinate multi-signature signing workflows, or report transaction data in formats required by institutional finance and tax systems. These limitations are not failures of the product; they reflect that the product was built for personal finance, not for corporate treasury management.

A company considering Ledger devices for institutional crypto custody should understand that the devices themselves provide genuine security—private keys remain isolated and protected. However, the full institutional custody function requires additional infrastructure outside Ledger Wallet. That infrastructure might be a dedicated multi-signature coordination platform, a custody provider, a cold storage facility, an accounting system, or a combination of the above. The company’s security and compliance officers should define this infrastructure before assets are moved, not after. Implementing institutional controls after the fact is more difficult and more expensive than planning the structure upfront.

The other honest limitation is that Ledger Wallet is a consumer application in active development. Interfaces, features, and integrations change regularly. An institutional setup built around the current capabilities of Ledger Wallet may not work the same way in six months or a year. A company should not depend on features or workflows that are likely to change, and should design processes that would still work if Ledger Wallet changed materially or became unavailable. The hardware is stable and open-standard; the software is not.