Ledger Live Mac Install: Provenance Checks, Quarantine
Ledger Live Mac Install: Safe Setup Routes Compared: Vendor Package, Store Build, Mirror
Research Notice: This page describes verification habits and distribution routes in general terms; release numbers, system requirements, and signing identities change between versions and are published on the official source. Nothing here requests a recovery phrase, a private key, or a payment.
Ledger Live Mac Install Guide Safe Use Tips begins with one hard rule: take the package only from the address the maker publishes, and confirm its signature before the first launch. The desktop companion is a local interface to a hardware signer, and it holds no private keys, so every transfer still needs approval on the device itself. What follows covers what the program does, how the routes to your machine differ, which failures repeat, and how to check a build before it touches your data.
What the Desktop Companion Does and How It Works
The desktop companion is a local dashboard that reaches a hardware signer over USB or Bluetooth and public block explorers over the network. It assembles transfers, shows balances, and relays signed payloads, yet it cannot move funds by itself because the signing key never leaves the device.
Signing Keys Never Reach the Disk
Account balances, address labels, and transaction history are stored locally in an encrypted database, while the backup words that control the funds are generated and retained on the signer. That split is the point of the pairing: the program can request a signature and display the result, but the approval happens on a screen the computer cannot rewrite. If a copy of the database leaks, an attacker learns which addresses belong to you; the funds stay put because the key material is not in the file.
Which Servers the Program Contacts
The client queries public explorer endpoints to read balances and broadcast signed transfers, and it checks the maker’s servers for release notes and device metadata. Those calls carry addresses and public keys, not the backup words. Blocking all outbound traffic keeps the interface from refreshing, so an offline arrangement means signing on the device and broadcasting from a second machine. Endpoints and their operators are listed on the publisher’s page for the desktop application and can change between releases, so treat any static list as dated.
Where Local Data Sits
On both chip families the application keeps its encrypted store under the account’s Library folder, inside an Application Support directory named after the publisher. Removing the program leaves that folder behind, and a later setup will pick it up again. Backups of the folder do not restore access to funds, because the recovery material is held by the signer device; they restore labels and history only. Confirm the path before wiping a drive and check exactly what you are deleting.
Who Runs This Software, for Which Tasks, and When It Fits
People who hold several crypto accounts and want one window for balances, staking positions, and transfers form the core audience. It also suits anyone who prefers approving every movement on a dedicated signer rather than a phone. It fits poorly when you need a fast mobile payment, share a computer with others, or cannot keep a backup of the signer.
Multi-Account Holders and Stakers
Someone tracking a dozen chains in separate setups gains the most from a single interface that lists every account and its staking status side by side. The program pulls those figures from explorer endpoints, so the numbers are only as fresh as the network allows. Delegation and reward claims still require a device confirmation, which means a batch of small operations costs as many button presses as there are transfers.
Approval-First Workflows
Readers who treat the computer as untrusted hardware get the intended experience: build a transfer, read the destination and amount on the signer’s screen, then approve. That habit neutralizes most malware, because a tampered address shown in the window will not match the address shown on the device. The trade-off is friction, since every movement needs the signer present and unlocked, and unattended automation becomes impossible by design.
Shared or Locked-Down Machines
On a family computer or a managed work laptop, local programs can be blocked, logged, or removed without warning. The library folder may sit on a synced drive that copies labels and history to a cloud account. A separate account with sync disabled keeps the data local; otherwise rely on the phone build and treat the desktop as a viewer. Employer device policies are published by the employer, not the maker.
Setup Routes Side by Side: Vendor Package, Store Build, Mirror
Take the package from the maker’s own domain and verify its signature; that route has the shortest chain of custody. Store builds and community package entries are convenient but add a third party between publisher and reader, and mirrors remove provenance outright. Judge each option by who publishes it, what it cannot guarantee, and how you confirm it.
The comparison covers four distribution routes for the same program. Rows are scored on the same three criteria: who publishes the file, the limit built into that route, and the check a reader can run before opening anything.
Distribution routes for the desktop companion
| Route |
Who publishes it |
Built-in limit |
How a reader checks it |
| Vendor package |
The maker, on its own domain |
Needs a manual signature check |
Fingerprint printed on the release page |
| Platform store build |
The maker, shipped through the store |
Narrower settings, different pairing flow |
Store listing and platform review record |
| Community package entry |
Maintainers with no link to the maker |
Often trails the current release |
Version string matched to the release page |
| File mirror or share link |
Unknown, sometimes anonymous |
No provenance at all |
Hash compared against the official value |
| Message or email attachment |
An impersonator |
Almost always hostile |
Do not open it, delete it, report it |
A vendor package suits anyone who can spare two minutes for a fingerprint check and wants the current build. A store build fits readers who value platform review over settings depth and accept a narrower feature set. Community entries help when the official route lags on older hardware, yet volunteers maintain them, so a delay is expected rather than unusual. Mirrors and message attachments have no defensible scenario; the one exception is a mirror operated by the publisher itself, which is simply the official route under another address.
What a Fingerprint Check Actually Proves
A matching signature proves the file was signed by the holder of a published key and that nothing changed after signing. It does not prove the key belongs to the maker unless you compare the fingerprint against a second, independent source: the release page, a signed note, or a printed record you kept. One source alone is circular, because an attacker who controls the page also controls the value printed on it.
Why Mirrors Fail the Provenance Test
A mirror is a copy, and a copy carries no evidence about its origin. The file name, icon, and version string can be reproduced exactly while the binary differs by a few bytes that redirect a device confirmation or log an address. Hashing the mirror file and comparing it to the official value catches this, but only if you already hold the official value from a source you trust, which is the step mirrors were meant to skip.
Where Setup Breaks and What It Costs You
Most failures are not exploits: they are quarantine prompts, stale builds, and support scams. A blocked first launch is usually the operating system refusing an unidentified download, while a version gap between the program and the signer causes pairing loops. The costly mistakes are social, since anyone who requests a recovery phrase is stealing, without exception.
Quarantine Prompts and What They Mean
When a browser download is flagged, the operating system is saying it cannot tie the file to a known developer, not that the file is malicious. The prompt appears for unsigned builds and for signed builds whose signature was stripped in transit. Resolve it by checking the signature and the hash; a common shortcut is to clear the quarantine flag with a terminal command, which suppresses the warning without answering the underlying question. Treat the warning as a question, not an obstacle.
Recovery Phrase Requests Are Never Legitimate
No support agent, update notice, or verification page needs the backup words, because that material exists to sign transfers and to restore a device, and both actions happen on your side of the screen. Anyone requesting it already holds your addresses and is asking for the key that moves the funds. Typing it into a website, chat window, or form is irreversible once a transfer confirms.
Version Gaps Between Application and Device
The program and the signer exchange a version handshake during pairing, and a mismatch can leave the connection in a loop or hide newer account types. The remedy is to update whichever side reports the older build, using the maker’s own updater inside the program. Device software steps are one-way in practice, so read the release notes before starting and keep the signer connected until the process reports completion.
How Do You Verify a Package Before Opening It?
The check takes about three minutes and needs the official release page, a terminal window, and the file you saved. It answers one question: did the file the maker signed arrive on your disk unchanged? Everything afterwards is judged on evidence rather than on the look of the download page.
Step 1: Save the file from the publisher’s own page
Save the file from the publisher’s own page. Every later check compares your copy against values printed on that page, so file and page must share one origin.
Step 2: Compare the published hash with your copy
Run a hash command on the saved file and compare the output character by character with the value printed on the release page. A hash is a fixed-length fingerprint of the bytes, so a single altered byte changes it completely.
Step 3: Read the signature attached to the package
Open the package’s signature details in a terminal and confirm the signing identity matches the one named on the release page. A signature proves the file came from the key holder and was not modified afterwards.
Step 4: Confirm the program asks for approval on the device
Connect the signer, unlock it, and confirm that the program requests approval on the device screen instead of accepting a password typed on the keyboard. That handshake shows the computer is talking to your hardware rather than to a local imitation.
Step 5: Record the version and hash you approved
Write the version number and hash into a note you keep offline, together with the date. The next release will be compared against this record, so an unexpected change becomes visible instead of passing unnoticed.
Which Details Keep Changing After a Release?
Release numbers, minimum system requirements, signing identities, and the endpoints the program contacts all shift between versions, and none of them move on a fixed schedule. Assume that anything memorized last year is stale. Check the official release page for current values instead of relying on a cached copy or a forum post.
Release Numbers and Minimum Requirements
Each release names the oldest operating system version it supports, and that floor rises over time as frameworks drop older interfaces. A machine below the stated minimum may run the program for weeks and then fail after an update, which looks like corruption but is really an unsupported configuration. The supported range is printed on the release page for each version; nothing in the interface reports it reliably.
Signing Identities and Published Fingerprints
Key rotation happens rarely, and when it does the fingerprint printed on the release page changes with it. That single moment is when lookalike packages have the best chance, because readers who memorized the old value see a mismatch and may assume the software is broken. The rule that survives rotation is procedural: trust the page only after reaching it by a route you chose, and compare the new value against two independent statements before accepting it.
Regional Availability and Store Policies
Store listings, phone builds, and some on-ramp partners are limited by country, and the list is maintained by the platform, the vendor, and local regulators rather than by any single page. A feature that works in one region may be hidden elsewhere without any error message, which readers often misread as a fault. Availability is published on the official source and shifts with licensing, so treat screenshots in older walkthroughs as unreliable.
Research Notice: This page is independent editorial material with no affiliation to any wallet vendor or to Apple; confirm every file name, digest and supported system release on the publisher’s own domain before running anything.
Check Your Mac Version and Download Ledger Live from the Official Site in that sequence, because the second action depends on the first. A system release and a processor family decide which package runs natively, while the source domain decides whether the file you receive is the one the publisher signed. Two minutes of checking removes both failure modes before they cost anything.
Check Your Mac Version and Download Ledger Live from the Official Site
Approach it as two gates rather than one task: first read the processor family and system release your computer reports, then fetch the desktop companion application from the manufacturer’s own domain. Each gate catches a different error – a wrong-architecture package opens and misbehaves, while a lookalike file arrives already compromised.
Where the System Reports Its Version and Chip Line
Two labels describe the same computer and only one of them settles compatibility. The Apple menu’s “About This Computer” panel reports the operating system’s version number alongside a chip line that names either an Apple silicon part or an Intel part. The build string behind that version number is what support tables and release notes cite, and typing sw_vers into Terminal prints the product version and build together, which lets you match the hardware against a published requirement instead of guessing from a product name.
Why the Processor Family Changes Which Package Fits
A single release page often offers one file built for Apple silicon and another built for Intel chips, and the two are not interchangeable in performance terms. A translated binary can run through the compatibility layer the platform ships, yet translation adds overhead and depends on that layer remaining present in future system releases. Native builds avoid that dependency on newer hardware, and the publisher labels which file targets which family, so the chip line you read first determines the file you take second.
Confirming Support Before You Fetch Anything
Support thresholds age quietly: publishers raise the minimum system release over time and stop signing older builds, and the figures change with each product update, so read the current requirement on the vendor’s own page rather than in a forum post. If your release sits below that threshold, the correct action is to update the operating system first, or to keep managing balances through a supported device, not to grab an archived file whose signing status nobody can confirm.
Who Needs This Setup, and When Does It Apply to You?
It applies to anyone holding the manufacturer’s hardware wallet who wants portfolio tracking and firmware handling on a desktop rather than a phone. It matters most for people on company-managed laptops, where the software catalogue is filtered and administrator rights are limited, while it is irrelevant for those who only trade on an exchange.
Holders Who Keep Keys on Their Own Device
A hardware wallet only helps if the companion software stops short of asking for recovery words, and the desktop client is built around that split: the device signs, the computer displays. People in this group open the application to review balances, approve transfers and push firmware updates, pairing it with the device over a cable or a short-range connection. Anyone who never holds keys personally gains little from the desktop route and adds one more screen where a fake prompt can appear.
Company-Managed Laptops and Restricted Rights
On a managed computer, the ability to move a new application into the system-wide Applications folder may be blocked, and the software catalogue may show only titles the employer approved. Before starting, confirm whether your account carries administrative rights, because the package has to sit in a system-wide location and the operating system will request an administrator password. Where that permission is absent, request the title through the internal catalogue or keep wallet work on a personal computer instead.
When a Phone App Already Covers the Same Job
The mobile companion handles the same balance and transfer tasks on a smaller screen, so the desktop route suits people who prefer a keyboard, a larger transaction review, or a computer that stays offline more often than a phone does. Desktops also fit people who keep several accounts and want them listed side by side. If the phone already covers everything, adding a second client widens the number of places where a phishing page can be mistaken for the genuine one.
The Publisher’s Domain Against Other Distribution Routes
One route keeps the file and the digest on the same page under the vendor’s control, and every alternative shifts part of that trust to a third party. The comparison below weighs four acquisition routes on who signs the binary, how integrity gets confirmed, and where each route breaks down.
Four ways of obtaining the same desktop client sit side by side here: the manufacturer’s own page, a listing inside the operating system’s software catalogue when the vendor publishes one there, a general third-party download portal, and a copy you kept from an earlier release. Each column asks the same question – who stands behind the binary, how a recipient confirms nothing was swapped in transit, and what the route cannot promise.
Acquisition routes for the desktop companion client, compared by signer, integrity check and failure mode
| Route |
Who signs the binary |
How a recipient confirms integrity |
Where the route breaks down |
| Manufacturer’s own domain |
The publisher, with its release signing key |
Match the digest printed beside the file |
Readers skip the digest comparison |
| Listing in the system’s software catalogue |
Publisher account, reviewed by the platform holder |
Confirm the developer name shown in the listing |
Version and availability are set by the platform holder |
| General third-party download portal |
The portal operator, not the publisher |
No publisher-issued digest is available to compare |
Lookalike pages, bundled extras, outdated packages |
| Archived copy kept from an earlier release |
Whoever stored the file originally |
Only the digest recorded at the moment of capture |
Support status for that build cannot be confirmed |
The vendor’s own page fits almost everyone and remains the only route where the digest and the binary come from one source – the release page the publisher maintains for the desktop client. A catalogue listing fits computers where administrative rights are restricted and the employer approved that title; it does not fit people who need the newest build on the day it ships. Portals and personal archives fit nobody holding real value, with one exception: an archived copy can serve as evidence when you compare a suspected tampered file against a known-good original.
Why a Published Digest Outweighs a Portal’s Reputation
A digest is a short string computed from the whole file, and any single altered byte produces a completely different string, which is why comparing it detects tampering that a familiar-looking domain name cannot reveal. The comparison only works when the digest comes from a source you already trust independently of the file – the same page that offers the binary. A portal can host an unmodified copy, but it cannot issue a digest on the publisher’s behalf, so the check degrades into trusting the portal’s word.
Stale Packages and the Support Window
Keep an old build on disk and the file itself stays intact, yet the series it belongs to eventually leaves the support window, meaning the manufacturer stops signing it and stops publishing fixes for whatever is discovered later in that code. The window length is set by the publisher and revised with each product cycle, so the current cut-off belongs on the official release notes rather than in a summary written months ago. Pulling an out-of-window package from any mirror reintroduces exactly the trust problem the vendor page solves.
Risks, Limits and Mistakes That Survive a Version Check
Knowing your build does not protect you from a convincing page, a permission request that makes no sense, or the habit of clicking the top search result. Three mistakes account for most reported failures: treating a model name as a compatibility answer, arriving at a typo-squatted address, and granting the application access it never needs.
Treating a Model Name as a Compatibility Answer
Manufacturers ship laptops and desktops under one family label with different processors inside, so a name or a model year tells you nothing about which binary will run natively. The chip line and the build string settle it. Two units bought in the same month can carry different silicon, and support tables refer to architectures rather than product names, which is why the check belongs at the chip and build level.
Sponsored Results and Lookalike Addresses
Paid placements can sit above the genuine listing, and the address in the browser bar is the only thing that settles which domain you actually reached. Compare that string character by character against the address you already know, treat the padlock as a weak signal rather than proof, and regard any page requesting recovery words as hostile no matter how it arrived. A bookmark created once from the official release page removes this entire class of error.
Permission Requests Worth Refusing
A client that displays balances and signs transfers with a separate device has no reason to read your photo library, contacts, calendar or microphone, and a system dialog asking for those is a warning rather than a setup step. Accessibility and screen-recording grants deserve the same suspicion. A hardware-wallet companion legitimately needs network access and sometimes local file access for its own database; anything beyond that narrow set is a signal to stop and re-check where the file came from.
How Do You Verify the Downloaded Package Before Opening It?
This procedure confirms that the file sitting in your downloads folder matches the binary the publisher signed, and it takes a few minutes with Terminal open next to the release page. Have the package, the digest published for that exact build and, if the page offers one, the signing details ready before you start.
Step 1: Copy the published digest for your exact build
Open the manufacturer’s release page and copy the digest string printed for the file version you just saved. The digest is tied to one exact build, so a value from a different entry will not match even when the file looks identical.
Step 2: Move to the folder that holds the file
Open Terminal and change into the directory containing the package with a cd command before running anything else. Paths containing spaces need quotes around them, and the pwd command confirms you are standing in the right place.
Step 3: Compute the digest locally
Run shasum -a 256 followed by the file name and read the result it prints. Local computation is the point: the value you compare must come from your own disk, never from a third-party page that reports a verdict on your behalf.
Step 4: Compare the two strings character by character
Place the published string and the terminal output side by side and check every character, treating a single mismatch as a failed download. Digests differ absolutely rather than gradually, so there is no partial match to interpret and nothing to retry except a fresh copy from the same official page.
Step 5: Check the signature verdict before you double-click
Mount the image and run the system’s spctl assessment against the application inside so the signature and notarisation verdict is printed before anything launches. An accepted verdict next to a matching digest settles both the tampering question and the question of whether the publisher’s certificate remains valid.
Version Drift, Architecture Mix-Ups and What Readers Commonly Get Wrong
Two things move under this workflow: the minimum system release the publisher supports and the way release notes label builds. Neither is fixed, both are published on the vendor’s own pages, and any figure quoted in a forum thread or a summary article is a snapshot that may already be wrong.
Minimum Requirements Rise Silently
Publishers retire support for older system releases to avoid maintaining code paths for hardware they can no longer test, and the change usually appears in release notes rather than in a prominent notice. The practical consequence is that a computer which ran the client twelve months ago may be refused at the next launch, and the fix is a system update rather than a replacement download. Check the current floor on the official page before assuming your release still qualifies.
Labels in Release Notes Rarely Match Common Speech
Release notes refer to architectures, code names and build identifiers, while readers describe the same thing with model names and years, so mismatched vocabulary pushes people toward the wrong file. The chip line from the system panel maps directly onto the architecture labels on a release page, and the build string maps onto the version entry. Keeping those two mappings clear prevents most of the confusion that later looks like a compatibility failure.
Re-checking After Every Point Release
Each point release of the operating system can change how the compatibility layer behaves and how the platform treats older signed packages, which means a setup verified half a year ago deserves a fresh digest check after a system update. Re-verify the file you already hold rather than fetching a replacement on autopilot. If a package that previously passed now reports a rejected signature, the cautious response is to stop and confirm on the publisher’s page whether the certificate was rotated.
Q&A:
I installed Ledger Live from ledger.com, but macOS says it cannot check the app for malicious software. Should I bypass that warning?
Only bypass it after you confirm the file is genuine. The official macOS build is signed and notarized by Ledger. Delete the copy you have. Download the .dmg again from https://www.ledger.com/ledger-live. Compare the SHA-256 checksum of the .dmg with the value on Ledger’s official download page if one is listed. Open Terminal and run shasum -a 256 on the .dmg file you downloaded. For example: shasum -a 256 ~/Downloads/LedgerLive.dmg (use your actual file name). After installing, run: codesign –verify –deep –strict –verbose=2 /Applications/Ledger\ Live.app and spctl –assess –type execute –verbose /Applications/Ledger\ Live.app. If the checksum matches and the signature is valid, you can allow the app in System Settings > Privacy and Security. If anything does not match, do not open it. Re-download from the official site. Never enter your recovery phrase into the app or into any website.
Does Ledger Live need Full Disk Access, Accessibility, or Screen Recording on my Mac?
No. Ledger Live does not need those permissions to manage your accounts or connect to a Ledger device. On macOS, you may see a request for Bluetooth if you use a Ledger Nano X over Bluetooth. You may also see a request for notifications, which is optional. For USB connections, macOS usually does not ask for a special privacy permission. If an app or website tells you to grant Full Disk Access, Accessibility, Screen Recording, Camera, Microphone, or Contacts to Ledger Live, treat that as a warning sign. Go to System Settings > Privacy and Security > [category] and turn off anything that Ledger Live does not need. Keep only Bluetooth if you use it, and maybe notifications. Also confirm you downloaded Ledger Live from ledger.com, not from an ad, a search result, or a third-party download page.
Can I use Ledger Live on a Mac that I also use for games, torrents, and cracked software?
You can, but the risk is much higher. Ledger Live itself does not protect a compromised Mac. If malware can read your screen, capture keystrokes, or replace the app, it can trick you into sending funds to the wrong address. A hardware wallet still asks you to confirm each transaction on the device screen, so always compare the address and amount on the Ledger screen with what Ledger Live shows. For better safety, use a separate Mac account for crypto. Do not install cracked apps, pirated games, or unknown browser extensions on that account. Keep macOS and Ledger Live updated. Turn on FileVault, set a strong login password, and lock the screen when you leave. If you must use the same Mac, scan it with a trusted security tool, avoid remote-access software while Ledger Live is open, and never type your recovery phrase anywhere except on the Ledger device itself.
What should I check after installing Ledger Live on macOS to avoid a fake version?
Check four things. First, the source: the installer should come from ledger.com. Look at the browser address bar and make sure the domain is exactly ledger.com or www.ledger.com before downloading. Second, the file name and type: the official macOS download is a .dmg file, not an .exe, not a .pkg from an unknown site, and not a browser extension. Third, the app signature: after dragging Ledger Live to Applications, open Terminal and run codesign –verify –deep –strict –verbose=2 /Applications/Ledger\ Live.app. A valid result should mention Ledger SAS. You can also run spctl –assess –type execute –verbose /Applications/Ledger\ Live.app. Fourth, the device check: connect your Ledger, open the Ledger Live app, and confirm that the device screen shows the same accounts and addresses. If the app asks for your 24-word recovery phrase, close it. Ledger Live never needs that phrase. Delete the app, empty the Trash, and reinstall from ledger.com if anything looks wrong.
Is a VPN or antivirus necessary for Ledger Live on Mac, and can I use Wi-Fi?
A VPN is not necessary for Ledger Live to work. Ledger Live needs an internet connection to sync with blockchain data, but it does not send your private keys or recovery phrase anywhere. A VPN can hide your IP address from your internet provider or from a public Wi-Fi operator, but it will not fix malware on your Mac. Antivirus software is optional on macOS because the system has XProtect and Gatekeeper. Extra security tools can help, but avoid fake antivirus apps that ask for payment after showing scary alerts. You can use Wi-Fi, including public Wi-Fi, as long as you take basic steps: use a trusted network when possible, keep macOS and Ledger Live updated, do not ignore certificate warnings, and confirm every transaction on your Ledger device screen. For larger transfers, wait until you are on a network you control. If you use a VPN, pick a reputable provider and do not install random VPN profiles from pop-ups.
Should I install Ledger Live on my Mac from the Mac App Store or from the Ledger website?
Get it from Ledger’s official website. On macOS, use the download link at ledger.com/ledger-live. Check that the page uses HTTPS and that the download comes from Ledger. The Mac App Store can host copycat apps, so if an app claims to be Ledger Live but the developer name is not Ledger, close it. After downloading, drag Ledger Live to Applications, open it, and let macOS verify it. Ledger Live will never ask for your 24-word recovery phrase. If any installer or support person asks for that phrase, stop. No real Ledger staff or app needs it.
My Mac shows a security warning when I open Ledger Live. Should I allow it, and which permissions are safe?
If you downloaded Ledger Live from Ledger’s official site, you can open it through System Settings > Privacy & Security if macOS blocks the first launch. Read the warning. A normal first-launch prompt may ask if you want to open an app downloaded from the internet. Check that the app is from Ledger. You do not need to disable Gatekeeper for all apps. For permissions, allow Bluetooth only if you use a Ledger device over Bluetooth. USB access is handled when you plug in the device. Ledger Live does not need Full Disk Access, Accessibility, or Screen Recording. If it asks for those, deny and reinstall from the official source. Also check Activity Monitor if you see odd network or CPU use.
Can I leave Ledger Live running on my Mac, and what should I do after each update?
Leaving it open is fine for quick access, but close it or lock it when you step away. Set a password in Ledger Live if you share the Mac. On updates, download from Ledger’s official site or use the in-app update prompt only if you trust it came from the official app. After updating, open Ledger Live and check the version number. Connect your Ledger device, enter your PIN on the device, and check that firmware is current. Send a small test transaction before a large one. Confirm every address and amount on the device screen. Keep your recovery phrase offline and never type it into your Mac.
