Trezor Suite Desktop File Permissions: Preventing Unauthorized Wallet Access on Shared Computers

A household has a shared Windows machine, a family MacBook, or a Linux workstation used by multiple people. One user installs Trezor Suite and connects a hardware wallet to manage cryptocurrency. The software runs without storing private keys locally—that isolation is the entire point of the hardware wallet design. But the computer itself remains a shared resource, and file permissions, user isolation, and encryption settings determine whether another person on that machine can access transaction history, paired device information, settings, or recovery data. The technical question is concrete: how do operating system permissions prevent unauthorized access to Trezor Suite data on a system with multiple active users?

This is not a theoretical concern. Trezor Suite stores configuration files, wallet metadata, transaction history, and device pairing information in application directories that a standard installation may leave accessible to other local users. Private keys never reside on the computer—they remain isolated on the hardware device—but everything else does. A colleague, family member, or roommate with shell access can enumerate paired wallets, observe transaction patterns, or modify settings if the installation was not secured through OS-level access controls. The hardware wallet itself provides strong cryptographic isolation; the operating system must enforce the perimeter around it.

Understanding Trezor Suite data directories and default permissions

Trezor Suite stores persistent data in platform-specific locations. On Windows, this is typically %APPDATA%\Trezor Suite (a hidden folder inside the user’s profile directory). On macOS, data lives in ~/Library/Application Support/Trezor Suite. On Linux, the default is ~/.config/Trezor Suite or ~/.local/share/Trezor Suite, depending on the distribution and installation method. These directories contain wallet metadata, paired device information, transaction histories, address book entries, exchange rate data, and application preferences.

The critical issue is that new user accounts on the same computer may have read access to these directories if permissions are not explicitly restricted. In a standard Linux installation, a user’s home directory is often created with 755 permissions (world-readable), which means any user on the system can list files and descend into subdirectories. On Windows, a default NTFS installation may allow the “Users” group or “Everyone” to read files depending on how the partition was configured and whether the installing account ran the setup with administrator privileges. On macOS, file permissions are similarly permissive by default unless the account has explicitly sealed its home directory through FileVault or Access Control Lists.

The Trezor Suite desktop application does not create or enforce restrictive permissions on its data folders during installation. The responsibility falls to the operating system user. When you install Trezor Suite, the application inherits the security context of the logged-in user. If other users on the system have read access to that user’s directories—whether through standard group permissions, shared folders, or misconfigured ACLs—they can browse the wallet metadata and transaction history.

This does not give a second user access to the private keys. The hardware wallet remains the cryptographic boundary. However, transaction history and address lists reveal financial activity. A user might infer which assets are held, when transactions occurred, and which addresses are associated with the wallet. For some threat models, this metadata exposure is acceptable. For others—particularly those involving privacy from household members, business partners, or coworkers—file-level access control becomes essential.

Windows: NTFS permissions and user isolation

On Windows, Trezor Suite data is stored in the user’s local APPDATA directory, which normally grants read access only to that user by default. However, this protection depends on the underlying NTFS partition being configured correctly and other users not having administrator rights. A Windows administrator account can read any file on the system, regardless of permissions. If a coworker or family member has an administrator account on the shared machine, they can bypass NTFS-level permissions entirely.

The first step is to verify the actual permissions on the data directory. Right-click the %APPDATA%\Trezor Suite folder, select “Properties,” then the “Security” tab. Click “Advanced” to see the full permission structure. Ideally, only your user account (or the current logged-in user) should have “Full Control.” The “Users” group and “Everyone” should have no permissions. If you see SYSTEM, Administrators, or other accounts listed with read or modify permissions, select those entries and remove them.

In practice, SYSTEM and Administrators may need to appear on NTFS volumes for Windows to function. The important control is that other regular user accounts should not be listed. If another user is present, ensure they do not have any “Allow” permissions on this directory. To prevent future users from accessing the directory by default, right-click the folder again, select “Security,” “Advanced,” then enable “Replace all child object permissions” and apply your restricted ACL to all subfolders and files.

A more robust approach is to use a local Windows user account dedicated solely to cryptocurrency activities. Create a new local account (not linked to a Microsoft account), set a strong password, and use only that account when running Trezor Suite. Other users on the machine cannot access files within that account’s home directory unless they know the password or have administrator privileges. This approach isolates not just the Trezor Suite data but all browser history, credentials, and temporary files associated with cryptocurrency activity.

If the computer is joined to a domain or uses a Microsoft account, additional complexity arises. Domain policies may override local permissions, and Microsoft account integration can cache credentials or backup files to the cloud. For a shared desktop where multiple network users log in, consider using Group Policy Objects to enforce tighter access controls, or simply restrict the use of Trezor Suite to a single local account that other users are not permitted to use.

macOS: FileVault, ACLs, and application sandboxing

macOS provides stronger default privacy than Windows in some respects, but the protections require active configuration. The primary tool is FileVault, Apple’s full-disk encryption. When FileVault is enabled, the entire drive is encrypted with a key derived from the user’s login password. Even if another user has physical access to the Mac and boots it from recovery mode, they cannot read encrypted volumes without the user’s credentials.

However, FileVault protects against physical theft and requires a restart to take effect. For a shared Mac where multiple users are logged in concurrently, or where the system remains on and unlocked, FileVault alone is insufficient. The second layer is Access Control Lists (ACLs), which refine POSIX permissions. By default, a macOS user’s Library folder is accessible only to that user and system processes, but this depends on how the account was created and whether permissions have been subsequently modified.

To audit and tighten permissions on the Trezor Suite directory, open Terminal and run:

ls -led ~/Library/Application\ Support/Trezor\ Suite

This lists the permissions on that directory. If the output shows “drwx——” (700 in octal), only you have read, write, and execute access. That is ideal. If it shows anything more permissive—such as “drwxr-xr-x” (755)—other users can read the contents. To restrict it, run:

chmod 700 ~/Library/Application\ Support/Trezor\ Suite

This removes all group and other-user permissions. Then apply the change recursively to all files within the directory:

chmod -R 700 ~/Library/Application\ Support/Trezor\ Suite

For additional control, you can set an extended attribute that prevents even administrator accounts from changing permissions without a password. This is more defensive than typical household use requires, but it is available:

sudo chflags uchg ~/Library/Application\ Support/Trezor\ Suite

That command marks the directory as immutable. To reverse it, you would need to run sudo chflags nouchg on the same path. Use this only if you understand the recovery implications.

macOS Ventura and later also offer Advanced Data Protection, which extends encryption protections to iCloud backups. If you use iCloud Keychain or automatic backups, ensure that sensitive Trezor Suite data is not being synced to Apple’s servers. Check System Settings > [Your Name] > iCloud > App Data & Privacy, and disable syncing for applications you consider sensitive.

Linux: Umask, home directory defaults, and file encryption

Linux permissions are explicit and well-understood, which makes misconfiguration easier to spot and easier to correct. When a user is created on a Linux system, the umask determines the default permissions for new files and directories. A umask of 0077 means new files are created with permissions 600 (owner read-write, no group or other access). A umask of 0022 (more common on shared systems) creates files with 644 permissions, world-readable.

Check your current umask by running umask in the terminal. If the output is “0022,” files created by Trezor Suite or any application will be readable by all other users. To change it for your current session, run umask 0077. To make it permanent, add this line to your shell configuration file (~/.bashrc, ~/.zshrc, or your shell’s equivalent):

umask 0077

After adding this line, log out and log back in, or source the configuration file with source ~/.bashrc. New Trezor Suite installation or configuration changes will now respect the restrictive umask. Existing files may already be world-readable; audit and correct them manually.

To check permissions on the Trezor Suite config directory, run:

ls -la ~/.config/Trezor\ Suite

Ideally, every file and folder should show permissions like “drwx——” (700) and “-rw——-” (600). If you see anything with “r” permissions for “group” or “other,” remove them:

chmod -R go-rwx ~/.config/Trezor\ Suite ~/.local/share/Trezor\ Suite

This command removes all group and other-user read, write, and execute permissions from those directories and all contents. Run it even if you installed Trezor Suite before learning about umask, as the initial installation may have created world-readable files.

For stronger protection on a multi-user Linux system, consider using encrypted home directories or LUKS-encrypted containers. eCryptfs, encrypted LVM volumes, or LUKS partitions can encrypt a user’s entire home directory, making it inaccessible to other users even if they somehow gain root access. This is overkill for a household machine but worthwhile for a workplace shared server. Most Linux distributions offer encrypted home setup during user creation; if not already configured, it can be added later through ecryptfs-setup-private on Ubuntu/Debian or equivalent tools on other distributions.

Isolating Trezor Suite across user accounts and sessions

The simplest and most robust approach on any operating system is to create a dedicated user account for cryptocurrency activity and never log into that account from a shared context. On Windows, create a local user account with a strong password. On macOS or Linux, create a standard user account separate from any accounts used by others. Configure that account with restrictive permissions, enable disk encryption if available, and use it only when running Trezor Suite or managing your hardware wallet.

Other users on the system should not know the password to this account, and the account should not be used for general browsing, email, or any activity that exposes it to malware. If you use the same machine for work or shared activities, switch to a separate account before accessing cryptocurrency. This prevents malware running under a work account from directly accessing your Trezor Suite data, and it prevents a coworker from casually browsing your transaction history if they gain temporary physical access.

For maximum isolation, some users choose to dedicate a physical machine to Trezor Suite and cryptocurrency activities. This eliminates file permission complexity entirely. The machine can be a low-cost laptop or a small form-factor PC used exclusively for hardware wallet management. If that is impractical, the dedicated user account approach on a shared machine provides most of the same isolation benefits without the hardware cost.

On mobile, this concern is less acute. iOS and Android enforce application sandboxing by design; each app runs in its own process with its own data directory that other apps cannot access. A second user logging into the same iPad or Android device would need to use their own user profile, and applications installed or data created under your account are not visible to them by default. However, this assumes the device is using the operating system’s native multi-user or multi-account features. Shared login credentials or admin account access can bypass these protections.

Monitoring and maintaining permissions over time

File permissions can degrade over time. System updates, backup utilities, or new applications may reset permissions or create world-readable copies of your data. It is worthwhile to audit the Trezor Suite directory monthly and reset restrictive permissions if they have loosened. On Windows, create a scheduled task that checks NTFS ACLs monthly. On macOS or Linux, a cron job can verify permissions and log discrepancies.

A simple Linux cron job might look like:

0 9 1 * * find ~/.config/Trezor\ Suite ~/.local/share/Trezor\ Suite ! -perm -700 -ls | mail -s “Trezor Suite permissions alert” yourname@example.com

This runs on the first of each month and emails a list of any files or directories with permissions looser than 700. The equivalent Windows scheduled task would use PowerShell to inspect ACLs and alert you to any that have changed.

Also monitor for new Trezor Suite installations on shared systems. If you are the only person who should be running Trezor Suite, you can verify this by checking for multiple installations or unusual processes. On Linux, run ps aux | grep -i trezor to list running instances and identify which user launched them. On Windows, use Task Manager to check for multiple instances of Trezor Suite under different user accounts.

Encryption of the entire partition provides a baseline. FileVault on macOS, Windows BitLocker on enterprise editions, and LUKS on Linux all encrypt at the storage layer, making offline access to files impossible without the correct credentials. If your shared computer already uses full-disk encryption, the OS-level file permissions become a secondary control against a user already logged into a different account on the same boot. If the disk is not encrypted, file permissions alone are insufficient against a determined attacker with physical access.

Integration with Trezor Suite security architecture

The security model of trezor suite assumes that the computer running the software is compromised or untrusted. Private keys never leave the hardware device, and transaction data is always verified on the device’s screen before approval. Even if another user on the computer modifies your Trezor Suite configuration files, steals your transaction history, or observes your activity, they cannot spend your funds without the hardware device itself and its PIN.

However, the threat model of shared computer access includes risks that private key isolation does not address. An attacker with access to your Trezor Suite data could see which addresses hold funds, reconstruct the timing of your transactions, identify which wallet is associated with which exchange account, or modify settings to route future transactions through a malicious node they control. The last scenario is particularly dangerous: if another user modifies your custom node settings in Trezor Suite to point to a server they operate, they could intercept and modify transactions or inject fake data into the wallet display.

File permission controls prevent this by making Trezor Suite data readable and writable only by the account that created it. A second user cannot modify configuration files even if the hardware device is physically present. This is why combining OS-level isolation with the hardware wallet’s cryptographic isolation creates two independent security layers. Break either one, and the system is still secure. Only if both are compromised can a user’s funds be at risk.

When you install Trezor Suite desktop, verify that the installation directory and data directory are both restricted to your user account. Some distributions or package managers may handle this automatically; others leave it to the user. The security is not automatic.

Practical checklist for shared computer use

Before using Trezor Suite on a shared machine, work through this sequence. First, create or identify a local user account that only you can access. Set a strong, unique password. On Windows, ensure it is a local account, not linked to a Microsoft account. On macOS and Linux, use a standard user account separate from any work or family accounts.

Second, enable full-disk encryption if available and not already active. On Windows, enable BitLocker (available in Pro, Enterprise, and Education editions; Home edition lacks built-in BitLocker). On macOS, enable FileVault through System Preferences > Security & Privacy. On Linux, enable LUKS during installation or afterward if the partition is not already encrypted. Full-disk encryption is not a substitute for file permissions, but it is a necessary foundation.

Third, verify the umask and directory permissions for Trezor Suite data directories. Use the commands provided above for your operating system. Audit both the main data directory and any subdirectories. If you find world-readable files, restrict them immediately with the chmod or icacls commands appropriate to your OS.

Fourth, install Trezor Suite while logged into your dedicated account. Let the installation complete and run through its initial configuration. Do not skip setup steps or default options; they exist to establish the basic security perimeter. Plug in your Trezor hardware wallet only after you have confirmed that the application is running under your account and no other user is logged in.

Fifth, set up Trezor Suite with Tor integration if you want to reduce IP-level exposure. This does not protect your data directory, but it does prevent your ISP or network administrator from seeing that you are connecting to Trezor infrastructure. Enable Tor in the application settings (Settings > Privacy > Use Tor), and verify that connections route through the Tor network before proceeding with any transactions.

Sixth, consider enabling optional features like coin control and transaction previews. These allow you to inspect transaction details before signing and to verify that malicious software or another user has not modified the intended recipient address or amount. Always verify critical transaction data on the device screen itself, never just in the application interface.

Finally, create a monthly reminder to audit file permissions, especially after system updates or major application changes. A single audit is not sufficient; permissions can degrade, and new versions of Trezor Suite may reset file creation defaults. Recurring verification keeps the protection active.