Ledger Live Windows 10: Hardware and Version Checks
Ledger Live Windows 10: Which PCs Qualify Before You Install
Research Notice: This page explains general custody and verification practice for desktop wallet software. It is not affiliated with any hardware manufacturer, it does not distribute files, and it never asks for a recovery phrase. Chain support, minimum system builds and package formats change between releases, so confirm current details on the vendor’s own release notes.
Ledger Live Windows 10 Install Guide Tool starts from one rule: fetch the desktop companion from the vendor’s own domain and confirm what you downloaded before opening it. That program talks to a hardware wallet over a cable or a short-range radio link, reads public account data, and hands every spend to the device for approval. What follows maps which access route suits which user, what breaks a first setup, and how to tell a genuine file from a lookalike.
What the desktop companion application does on a Microsoft desktop system
It is a locally executed program that talks to a hardware wallet over a cable or a short-range radio link, reads public account data, and assembles transfers that the device itself must approve. The program is a display and a relay; the secrets that authorise spending never leave the device’s secure chip.
How the program reaches the device
The connection runs over a physical data cable or a short-range radio link, and the device has to be unlocked with its own PIN before the program sees anything. A charge-only cable carries power but no data, which is why a device that lights up can still stay invisible to the program. On a desktop, plugging the device into a rear port rather than an unpowered hub removes most detection failures. The program then asks the device to open the relevant chain-specific app, and no account data appears until that app is running.
Where the private keys actually live
The seed and the derived private keys stay inside the device’s secure element; the desktop program stores only public account identifiers, labels, settings and cached balance figures in an encrypted local database. That split is why a stolen computer exposes your balance history and nothing spendable. Every outgoing transfer must be confirmed on the device screen, and the address shown there is the one that counts. If a window ever asks you to type the recovery phrase, that window is not the vendor’s program, and closing it is the correct response.
Which parts need an internet connection
Balance figures, fee estimates, price data and the catalogue of chain-specific apps arrive over the network from the vendor’s indexers, so an offline machine shows stale or empty data even though signing still works. The signing step itself is local and needs no connection, which is why a transfer built offline can be broadcast later from another machine. Users who want to remove the vendor’s servers from the path run their own node and point the program at it; that arrangement is published on the official source rather than explained inside the app itself.
Who actually needs the desktop client instead of a phone?
Anyone holding more than a handful of accounts, running a node-backed setup, or reviewing transfers on a large screen gets more from the desktop build. The phone build covers the same core actions, but it exposes fewer chains, fewer account types and less transaction detail per screen.
Portfolios spread across many chains
Each chain the program supports appears as its own account, and a portfolio that touches a dozen networks becomes a long list that a phone screen renders poorly. Desktop layouts put every account into one scrollable table with sortable columns, which makes reconciliation against an exchange statement far quicker. The same account set is readable on a phone, but filtering and searching take more taps. Where a chain is supported only in the desktop build, the phone will not show it at all, and that difference is published per release on the official source.
Reading a transfer before it is signed
A large monitor shows the destination address, the amount and the network fee at once, so a substituted character in an address is easier to catch before the device asks for confirmation. On a phone the same fields arrive stacked, and long addresses wrap across several lines. The device screen remains the final authority either way, and matching the first and last four characters of the address on both screens is the check that actually matters. Anyone moving large sums should treat the desktop layout as a reading aid, not as a second opinion.
Cases where the phone build fits better
Travel, quick balance checks and short-range radio pairing with newer devices are the phone build’s strengths, because it needs no cable and no desktop session. It also updates itself through the platform store, which some users find simpler than a manual package replacement. The trade-off is fewer settings, no node configuration and a smaller review surface. A user who only receives funds and checks balances loses nothing by staying on a phone; a user who manages dozens of accounts will keep returning to a desktop.
Desktop client measured against mobile and third-party routes
The desktop client is the widest route for account management, the phone build is the most portable, and a third-party interface adds chain-specific features the vendor’s own program does not ship. Which one fits depends on how many chains you touch, whether you need node access, and how much extra contract risk you are willing to accept.
The comparison below sets four access routes side by side against the same three criteria: what each route suits, where it stops, and how a user confirms that what they are running is genuine. Every route pairs with the same hardware device, so the device is not the variable – the interface is. Current chain lists, package formats and minimum builds for each route are published on the official source, including the vendor’s release page.
Access routes for a hardware wallet on a desktop or a phone
| Route |
Best for |
Main limit |
How to confirm authenticity |
| Vendor desktop client on Microsoft’s 64-bit system |
Large portfolios, node setup, detailed review |
Needs a 64-bit build; current requirement published on the official source |
Hash and publisher name published on the official source |
| Vendor desktop client on macOS or Linux |
Same feature set away from Microsoft systems |
Package format differs; distribution rules published on the official source |
Same verification path, from the same official source |
| Vendor mobile app on Android or iOS |
Travel, quick balance checks, radio-paired devices |
Fewer chains and settings than the desktop build |
Store listing must point to the vendor’s own developer account |
| Third-party interface paired with the same device |
Lending, swapping, chain-specific contract features |
Extra contract risk; the interface code is not the vendor’s |
Check the site address and read the on-device approval prompt |
Choose the vendor’s desktop build when you need the full account list, node configuration or the largest review surface; choose the phone build when portability outweighs settings, and reach for a third-party interface only when a specific chain or contract interaction is unavailable elsewhere. Exceptions exist: some chains reach mobile before desktop, and some third-party interfaces are published by the same vendor. Anything that moves between releases – chain lists, minimum builds, package formats – is published on the official source rather than fixed here.
Where the desktop build and the phone build diverge
Both builds sign with the same device and neither holds keys, so the difference sits in coverage and in how much information reaches the screen at once. Chain lists, account types, node settings and export options are wider on desktop; portability, store-managed updates and radio pairing belong to the phone. A user can run both against one device, and the account list stays consistent because accounts derive from the same seed. The one thing that never transfers between them is the recovery phrase, which should never be typed into either.
What pairing a third-party interface changes
A third-party interface lets the same device sign transactions for contracts the vendor’s program does not display natively, which is useful for lending, swapping and chain-specific features. The trade-off is that the interface, not the vendor, decides what the device is asked to approve, and a malicious or compromised page can request an approval that drains an allowance. Users should read the on-device prompt, confirm the site address character by character, and treat any unexpected approval request as a stop signal. The device still enforces confirmation; it cannot judge intent.
What goes wrong most often during a first setup?
The recurring failures are physical rather than cryptographic: a charge-only cable, a device left locked, the wrong chain-specific app open, or a hub that cannot supply enough current. Behind those sit two slower mistakes – restoring from a phrase that was stored digitally, and letting firmware fall several versions behind.
Cables, ports and locked devices
A cable that charges a phone may carry no data lines at all, so the device powers on and still never appears in the program. Plugging directly into a machine port, avoiding unpowered hubs and swapping the cable are the three fastest tests. The device must also be unlocked with its PIN and have the matching chain-specific app open before an account becomes visible. If the program reports no device after all three checks, the port or the cable is the remaining suspect, not the seed.
Recovery-phrase handling that cannot be reversed
Typing the phrase into a web page, a chat window or a note-taking app hands full control of the funds to whoever reads it, and network transfers cannot be recalled. Photographs of the written phrase are equally exposed once a phone syncs to a cloud backup. The device asks for the phrase only during a restore, never during ordinary use, so a prompt for it inside a running program is a sign of tampering. Paper or stamped metal stored offline, in a second location, is the pattern that survives fire, flood and disk failure.
Version drift between the program and the device
Chain-specific apps on the device and the desktop program are released separately, and an old pair can refuse to work together – an account may fail to open or a transfer may stall at signing. Updating the program first and the device apps second, one at a time, keeps a single variable moving. Some releases raise the minimum firmware a device must run, and those floors are published per release on the official source. Skipping several versions at once is where most stuck updates originate.
How do you check that a desktop wallet download is authentic?
You verify the file before it runs, not after. Have the device and its PIN, a data cable, and a browser ready; the check takes a few minutes and needs only the vendor’s own domain, any checksum published for that release, and whatever security scanner already ships with your operating system.
Step 1: Reach the vendor by typing the address
Open the vendor’s domain by typing its address into the browser bar. Search results and links inside messages can point at lookalike pages that differ by a single character, and typing the address removes that route entirely.
Step 2: Confirm the certificate and the domain spelling
Confirm the page’s certificate and the exact spelling of the domain before clicking anything. A padlock alone proves only that a connection is encrypted, not that the site belongs to the vendor, so the address itself is the evidence.
Step 3: Take the build that matches your architecture
Download only the build listed for your machine’s architecture from that page. A file built for a different architecture will either refuse to open or leave components missing.
Step 4: Match the file hash against the published value
Compare the file’s hash with any checksum the vendor publishes beside the release. A matching hash shows the bytes arrived unchanged, while a mismatch means the file was altered or corrupted and should be deleted rather than opened.
Step 5: Read the file properties and scan locally
Inspect the file’s properties for a publisher signature and run your own security scan before opening it. Where a signature is present it names the legal entity that produced the file, and a local scan catches what a download page’s own reputation check cannot.
What changes between releases and what people get wrong
Supported chains, minimum system builds, package formats and firmware floors move with every release, so any figure copied from a tutorial older than a few months is unreliable. The parts that do not move are the custody model and the phrase handling – those have stayed constant across versions.
Chain coverage and minimum system builds
The set of networks the program can read and sign for grows and occasionally shrinks, and each release notes which chains were added or retired. Minimum system builds rise as underlying libraries drop support for older versions, which is why a machine that ran an older release can refuse a newer one. Users on long-term-support systems should check the current requirement before downloading rather than assuming last year’s build will run. The authoritative list sits with the release notes on the official source.
The belief that the program stores your coins
Nothing of value sits in the program’s folder: the coins are recorded on their own networks, the keys sit in the device, and the program holds a cache of public data. Deleting the program and starting over changes nothing about ownership, as long as the device and its phrase survive. That is also why copying the program’s data folder to a new machine restores convenience, not access. The confusion costs users time, not funds, but it drives unnecessary repeat setups and misplaced worry.
Where third-party instructions go stale
Video walkthroughs and forum posts describe menu labels that a later release renames, and a viewer following an old path concludes the feature was removed. Screenshots also hide the parts that matter, such as which app must be open on the device. The safe rule is to use such material for concepts and the vendor’s own release notes for current labels. Anything that contradicts the release notes – chain lists, firmware floors, download addresses – should be treated as out of date.
Research Notice: This is an independent technical overview; verify current minimum requirements at the vendor’s own site before changing anything on your machine.
Ledger Live Windows 10 Install Guide Tool compatibility rests on four values you can read from the machine itself before a single file is fetched. Three of them cannot be changed by any setting, and one of them decides whether the cable handshake succeeds at all. The sections below separate what the hardware enforces from what a policy or a bad transfer merely appears to enforce.
Windows 10 Version and Hardware Checks Before Installing Ledger Live
Confirm the build is a 64-bit edition of the tenth release, at or above the minimum build the publisher lists, with enough free space and a working USB port, before running any setup file. A 32-bit system or an outdated build fails silently or blocks the launch, and no later step repairs that.
Build Number Sets the Floor, Not the Ceiling
The build number recorded by the operating system determines whether the application’s runtime libraries are present. Microsoft ships servicing updates that change the build while leaving the edition name untouched, so two machines both reading “Pro” can sit on builds years apart. Open the Run dialog, type winver, and read the four-digit value after “OS Build”. Compare it against the floor the publisher publishes on its download page; that floor moves as older servicing branches are retired, and it is the only number that matters for compatibility.
Processor Architecture Cannot Be Patched Later
64-bit x64 silicon is the hard requirement, because the desktop application ships as a 64-bit binary and no 32-bit build exists to fall back on. A machine running the x86 edition reports “32-bit operating system, x64-based processor” in Settings, which means the hardware could run the software but the current system cannot. Replacing the operating system is a clean rebuild, not an update, and it wipes the drive unless files are copied off first. Check Settings, System, About, and read the system type line before anything else.
Storage, Memory, and the USB Path
Free space on the system drive, not on a secondary volume, decides whether the package can unpack and later store its database of account and chain data. A drive with little headroom causes a failed extraction that leaves partial files behind. Memory pressure shows up as a frozen sync rather than an error message. The hardware wallet connects over a cabled USB data port; charge-only ports, unpowered hubs, and virtual machine pass-through are the three places that connection breaks. Confirm at least one free USB-A or USB-C port that carries data.
Who Runs These Checks, and When Does the Tenth Release Still Qualify?
Anyone running the desktop wallet on a personal or work PC performs these checks before the first launch, and again after a major servicing update. The tenth release still qualifies while the publisher lists it as supported; once that list changes, the same machine may keep working without updates. Machines kept offline need a fresh look at the build.
Work Machines and Managed Policies
Corporate images often run older servicing branches and enforce application control rules that block unsigned executables. The check that matters there is not only the build but whether local policy permits the binary to run: AppLocker and device guard rules can stop a signed package from launching, and the error appears as a policy block rather than a compatibility failure. Ask the administrator for the approved path before spending time on driver or cable troubleshooting, because nothing on the device side can override that decision.
Users on the Phone Companion Application
Phones and tablets run a separate application that talks to the same hardware wallet, and none of the desktop checks apply there: build numbers, disk space, and USB ports are irrelevant on Android or iOS. Account records stay tied to the device, so a phone can act as a fallback when a PC fails a requirement. This route does not replace the desktop program for firmware updates on older device revisions, which historically required a cabled connection; confirm current behavior on the publisher’s support pages, since device support shifts between releases.
Second-Hand and Refurbished Hardware
Machines bought refurbished frequently arrive with a fresh image that hides the original edition, or with a disabled TPM and Secure Boot configuration carried over from an enterprise fleet. Those two security features belong to the operating system’s own upgrade requirements and are not what the wallet application checks, so their absence proves nothing either way. What does matter is that the image is genuine and activated: a modified copy can carry removed components that the application’s runtime needs. Verify activation status in Settings before drawing conclusions about compatibility.
Four Ways to Read the Same Machine’s Specifications
Four built-in utilities report the values that decide compatibility, and each exposes a different slice: the build number, the architecture, the memory total, and the storage layout. Running one answers a quick question; running two resolves contradictions that appear on upgraded machines. None requires a separate download.
The comparison below weighs five inspection routes on what they reveal, how they are launched, and where they stop short. Every one of them ships with the operating system, so the effort is limited to typing a command or opening a settings page.
Inspection routes compared on what they surface, how they launch, and where each stops short
| Route |
Values it surfaces |
How to launch |
Main limitation |
| winver dialog |
Build number, edition, service branch |
Run dialog, then type winver |
Omits architecture, memory, and storage |
| Settings, System, About |
Edition, version, system type, memory total |
Start menu, then Settings |
Hides the full build string on some revisions |
| System Information (msinfo32) |
Firmware mode, architecture, memory, partition style |
Run dialog, then msinfo32 |
Slow to load and dense for one answer |
| PowerShell Get-ComputerInfo |
Aggregated system and hardware fields in text |
Shell window, then run the cmdlet |
Needs a script-capable shell policy |
| DirectX Diagnostic (dxdiag) |
Processor model, memory, display and audio drivers |
Run dialog, then dxdiag |
Ignores disk and USB controller detail |
Use the dialog for a single build number, the Settings page for architecture and memory together, and the information utility when firmware mode or partition style is in question. The shell cmdlet suits scripted audits across several machines; the diagnostic utility fits when display or audio drivers are suspects. None of the five reports USB controller state, so cable and port behavior still needs a physical test.
Where the Build String Hides
The four-digit build value is not printed on the main Settings screen on every revision, which is why the dialog remains the fastest source. Version 22H2 and its servicing updates share an edition label while carrying different builds, so an edition name alone tells you nothing about the floor. When you copy the number down, include the update build revision in parentheses if the dialog shows one; support staff ask for it first, and it distinguishes two machines with the same headline build.
Reading Architecture on Upgraded Machines
A machine that migrated from an older 32-bit release can report a 64-bit processor alongside a 32-bit system type, and that combination is the one that ends the process early. The Settings page states it in a single line under system type; the information utility states it under system type as well, spelled out as “x64-based PC” or “x86-based PC”. Neither value changes when memory is added or a drive is swapped, so this is a one-time read rather than something to re-check after every upgrade.
Faults That Halt the Setup Before It Begins
The blockers that stop a setup are a 32-bit edition, a build below the published floor, an S-mode configuration that refuses outside packages, and a charge-only cable. Each produces a distinct symptom and each is verifiable beforehand. Quarantine by security software and a truncated download complete the list.
S Mode and Package Restrictions
S-mode configurations accept programs only from the Microsoft Store, so a downloaded executable is refused with a message about its source rather than about compatibility. Leaving S mode is a one-way switch: reverting requires a clean rebuild. Confirm the mode under Activation in Settings, because the toggle stays hidden until you look for it. On managed machines the switch may be unavailable by policy, and the administrator has to release it.
Corrupted Transfers and Interrupted Writes
An incomplete transfer produces an executable that opens and then fails partway, or a checksum mismatch that looks like a hardware fault. Fetch the file over a stable connection, compare its hash against the value the publisher publishes, and store it on the system drive rather than an external volume that may disconnect mid-write. Delete failed partial files before retrying; the extraction step can resume from a damaged cache and reproduce the same failure.
Security Software That Blocks Quietly
Real-time scanners can quarantine a signed binary minutes after it lands, and the resulting error points at a missing file rather than at the scanner. Check the quarantine log before reinstalling anything. Some suites also intercept traffic from HID-class devices, which breaks the cable handshake while leaving the application interface intact, so the window opens and nothing connects. Add the publisher’s folder to the exclusion list only as a temporary diagnostic step, then restore protection.
How Do You Verify a Machine Meets the Requirements Before Setup?
Verification takes five checks and roughly ten minutes, using utilities already present on the machine: the build dialog, the Settings pages, a folder’s properties, a physical port inspection, and a hash comparison on the downloaded file. Have the publisher’s requirement page open in a browser and a working USB cable within reach.
Step 1: Record the build number
Run winver and record the four-digit build number. That number is the single value the publisher’s support matrix is written against, and it changes with servicing updates that leave the edition name alone.
Step 2: Confirm architecture and memory
Confirm the system type reads 64-bit and note the memory total. A 32-bit entry here ends the process, because no 32-bit binary exists to bridge the gap.
Step 3: Measure free space on the system drive
Check free space on the system drive, not on a secondary volume. The package unpacks to that drive and later stores chain data there, so headroom on another disk does not help.
Step 4: Test the port and the cable
Inspect a USB port and test it with the cable you intend to use. Charge-only cables and unpowered hubs fail the handshake while still lighting the device, which makes the fault hard to see.
Step 5: Compare the file hash
Compare the downloaded file’s hash against the value on the publisher’s page. A mismatch means the transfer was altered or truncated, and the file must be fetched again.
What Changes Over Time, and What Do People Get Wrong?
The supported build floor rises as older servicing branches are retired, so a machine that passed last year can fall out of scope with no local change. Memory and disk figures also move between major releases. Two errors dominate: assuming a newer operating system guarantees support, and reading a policy block as a hardware fault.
The Published Floor Moves Without Notice
Compatibility is defined against a threshold the vendor publishes, not against a fixed number, and that threshold shifts between releases as runtimes and signing requirements change. A machine that has sat unpatched for eighteen months may still run an older version while refusing any current one. Record the build you have and the date you checked; re-reading it after each servicing update is the only way to keep the picture accurate. The authoritative text sits on the publisher’s official download page, and it is revised without an announcement.
Newer Is Not Automatically Supported
The eleventh release can run the same binary, but the vendor does not promise it, and faults that surface there receive different handling. Conversely, an old machine that meets every listed requirement works regardless of its age. Edition names, from Home to Enterprise, do not alter the requirement set; the build and the architecture do. Treat the support matrix as the authority and the marketing name of the system as irrelevant.
Feature Updates That Reset the Baseline
An in-place feature update can change the build, re-enable S mode on some managed devices, and restore default policy that had been relaxed. After such an update the values worth re-reading are the build again, the activation state, and the USB driver stack, which the update may have replaced. Re-run the short verification rather than assuming the previous state survived; a two-minute confirmation prevents a failed launch later.
Q&A:
Do I need to remove my current Ledger Live install before putting the Windows 10 version on my PC?
Usually no. The Windows 10 installer can update an older desktop version. Close Ledger Live, download the newest installer from ledger.com, and run it. It will replace the old files and keep your accounts and settings. If you have a very old version or a damaged install, uninstall it from Settings > Apps > Apps and features, restart, then install again. Your crypto stays on the hardware wallet; app removal does not affect funds. You can restore accounts by connecting the device and adding them again. Keep your recovery phrase offline.
Windows 10 warns me about the Ledger Live setup file. Is that normal, and what should I do?
Yes, this can happen with new downloads. SmartScreen may show a warning because the file is not yet widely downloaded or because Microsoft has not built reputation for that exact build. Check the file came from ledger.com. Do not use links from email, chat, or ads. Compare the SHA-256 hash if the site lists one. In the SmartScreen window, choose More info, then Run anyway only after you trust the source. If Windows Defender blocks it, open Windows Security > Virus and threat protection > Protection history, allow the file, or add an exclusion for the installer, then run it again. After install, remove the exclusion if you added one. If the warning appears for a file from another site, delete it and download again from ledger.com.
Should I get Ledger Live from the Microsoft Store or from Ledger’s website on Windows 10?
Ledger’s own site is the main source. The Microsoft Store listing may not be available in all regions, and it can lag behind the newest release. Download the Windows installer from ledger.com/ledger-live. That page gives the current desktop build and links to checksums. The Store version, if present, can auto-update through Microsoft, but you should still confirm the publisher is Ledger. For either source, never enter your recovery phrase into the app or on a website. The app does not ask for it.
Ledger Live installed on Windows 10, but it cannot find my Ledger Nano. How do I fix that?
First, enter your PIN to open the device. Open the Ledger Live app. Connect the Nano with the cable that came with it, not a charge-only cable. Try a different USB port, preferably one on the back of a desktop. On Windows 10, open Device Manager and look for the device under USB devices or Universal Serial Bus controllers. If it shows an error, update or reinstall the USB driver. Close other wallet apps, browser extensions, and crypto programs that may hold the USB connection. In Ledger Live, go to Settings > Help > Troubleshoot USB. Follow the steps for your Windows version. If the device still does not appear, restart the PC, try another cable, and test the Nano on another computer. The article’s guide tool section may list a repair option for USB rules.
Can I set up Ledger Live on Windows 10 without administrator rights?
You can sometimes run the app as a standard user, but the installer often needs admin rights to write to Program Files, create shortcuts, and add USB drivers. If the PC is managed by a workplace or school, ask the IT team to allow the signed Ledger Live installer. If you cannot get admin access, you can try the portable version if Ledger offers one, or use another computer you control. Do not ask someone else to install it while your recovery phrase is visible. The phrase should stay offline.
Do I need a separate install tool for Ledger Live on Windows 10, or is the official installer enough?
The official installer is enough. Go to ledger.com, open the Ledger Live download page, choose Windows, and save the .exe file. Windows 10 will run that installer directly. A separate “install guide tool” is not required. Avoid download portals, ads, or emailed links. After downloading, right-click the file, open Properties, and check the digital signature or publisher if Windows shows it. Then double-click the installer and follow the prompts. You may need to approve an administrator prompt. Once installed, open Ledger Live, connect your Ledger device with the cable, and follow the on-screen steps.
Ledger Live keeps failing on Windows 10 with “Windows protected your PC” or “This app can’t run on your PC.” How do I fix it?
Those two messages point to different issues. “Windows protected your PC” is usually Microsoft Defender SmartScreen blocking a new or unsigned-looking file. Click More info, then Run anyway only if you downloaded the file from ledger.com. If that option is missing, right-click the .exe, choose Properties, check Unblock, and apply. “This app can’t run on your PC” often means you downloaded a 32-bit build on a 64-bit PC or the file is incomplete. Confirm your Windows 10 version in Settings > System > About. Download the current Windows installer again. Clear the old file. If antivirus or firewall software blocks the install, allow Ledger Live through it or pause that software for a few minutes. Then run the installer as administrator. If the error remains, update Windows 10, restart, and try a different USB port for the Ledger device after installation. Contact Ledger support with the exact error text and your Windows version if nothing changes.
I bought a new Windows 10 laptop. Can I install Ledger Live and keep my accounts, or will I lose my crypto?
Your crypto does not live inside Ledger Live. It stays on the blockchain and is controlled by the private keys inside your Ledger hardware wallet. Ledger Live is only the app you use to view balances, send, receive, buy, sell, swap, and manage accounts. On the new laptop, download Ledger Live from ledger.com, install it, connect your Ledger device, enter your PIN on the device, and add your accounts again. If you set up a passphrase on the device, enter the same passphrase when prompted. Do not type your recovery phrase into Ledger Live or any website. Do not use a “restore” option that asks for your 24-word phrase on the computer. If you had custom settings, account names, or watch-only accounts, you may need to recreate them. Your funds should appear after the accounts sync. If they do not, check that you are using the same Ledger device, the same passphrase, and the correct blockchain apps. Keep your recovery phrase offline. If you still see missing balances, contact Ledger support from the official site.
