VeraCrypt Done Right: The Practical Guide That Prevents Lockouts, Data Loss, and False Confidence

VeraCrypt is easy to use badly.

You can choose an unnecessarily complicated cipher cascade, forget a custom PIM, leave the only copy of a keyfile on a dying USB stick, sync a mounted container through two computers, or discover during a boot failure that your recovery media was never tested.

None of those failures means the cryptography was broken. They mean the surrounding system was badly designed.

This guide focuses on both sides of VeraCrypt: how to operate it and how to make defensible decisions about passwords, key derivation, filesystems, backups, system encryption, hidden volumes, SSDs, and recovery.

The instructions and terminology here were checked against VeraCrypt 1.26.29, released on June 9, 2026, and current as of September 2026. Version 1.26.29 is especially significant because it adds Argon2id for non-system volumes and fixes a plausible-deniability issue affecting some hidden volumes created by versions 1.26.6 through 1.26.28. (veracrypt.io)

TL;DR

If you want the short version:

• Use an encrypted file container for a manageable collection of sensitive files.
• Encrypt an entire USB stick or external drive when everything on it should be protected.
• Use VeraCrypt system encryption only on supported Windows x64 systems, and only after creating and testing recovery media.
• Use FileVault for a Mac startup disk and LUKS for a Linux system disk. VeraCrypt does not provide macOS or Linux system encryption.
• For a new non-system volume in VeraCrypt 1.26.29, use the default AES encryption algorithm and Argon2id KDF unless you need compatibility with an older VeraCrypt installation.
• Leave PIM at its default unless you understand the security, memory, performance, and recovery consequences.
• Prefer a long, unique password over unusual cipher combinations.
• Treat keyfiles as additional credentials that must be backed up perfectly.
• Never store your only backup inside the encrypted volume it is supposed to protect.
• Unmount a volume before unplugging its device, copying its container, or letting a cloud service synchronize it.
• Never format a device merely because Windows calls it RAW after VeraCrypt encryption.
• A Rescue Disk can repair certain system-encryption failures. It cannot recover a forgotten password.
• VeraCrypt protects data at rest. It does not protect an unlocked volume from malware, ransomware, a keylogger, or another process running with sufficient privileges.

What Is VeraCrypt?

VeraCrypt is open-source disk-encryption software derived from TrueCrypt. It creates encrypted storage that is decrypted and encrypted on the fly as applications read and write data.

A VeraCrypt volume can be:

• A file-hosted container
• An encrypted partition
• An encrypted physical device
• A Windows system partition or system drive

After you mount a volume, the operating system sees a normal filesystem. Applications can open, edit, compile, index, and delete files without knowing that VeraCrypt is involved.

When data is read, VeraCrypt decrypts the required sectors in memory. When data is written, VeraCrypt encrypts those sectors before sending them to storage. VeraCrypt does not decrypt the entire volume into a temporary directory. (veracrypt.io)

When a VeraCrypt filesystem is properly contained inside the encrypted volume, encryption covers:

• File contents
• File and directory names
• Filesystem metadata
• Directory structures
• Allocated filesystem sectors
• The filesystem’s representation of free space

That does not mean the surrounding host system reveals nothing. A container’s filename, apparent size, location, timestamps, backup copies, cloud synchronization history, and access patterns may still be observable.

Encryption at Rest Is Not Runtime Isolation

VeraCrypt is primarily designed to protect data at rest.

If a laptop is powered off and its system drive is encrypted, a thief should not be able to remove the drive and browse its files without the required credentials.

If a VeraCrypt USB drive is lost while unmounted, the person who finds it should see encrypted data rather than the files inside it.

The situation changes when a volume is mounted.

A mounted volume is intentionally usable. Any process with sufficient operating-system access may be able to read its decrypted files. Malware can copy them, ransomware can modify them, a keylogger can capture the password, and an administrator-level attacker may be able to inspect memory.

VeraCrypt’s own security model explicitly excludes protection against malware, a compromised operating system, an attacker with administrator-level control, and sensitive information remaining in RAM. (veracrypt.io)

That distinction is the foundation for every sensible VeraCrypt deployment:

Encryption protects a locked system from offline access. It does not make an already-unlocked system trustworthy.

What VeraCrypt Protects

VeraCrypt is a strong fit for threats such as:

• A powered-off laptop being stolen
• A lost USB flash drive
• A stolen external HDD or SSD
• Someone removing a storage device and attaching it to another computer
• Unauthorized offline examination of files
• Casual browsing of sensitive material by someone without the credentials
• Protecting archived project files, credentials, documents, or source code at rest

It can also provide portable encrypted storage across supported operating systems, provided that VeraCrypt and a mutually supported filesystem are available on each machine.

What VeraCrypt Does Not Automatically Protect

VeraCrypt does not automatically stop:

• Malware running while the volume is mounted
• Keyloggers
• Screen capture by sufficiently privileged software
• An attacker with administrator or root control
• Ransomware modifying files on a mounted volume
• Data copied from the encrypted volume into an unencrypted directory
• Sensitive temporary files created outside the volume
• Sensitive data written to swap, pagefiles, hibernation files, or crash dumps
• Files exposed through editor backup directories, build caches, recent-file lists, or search indexes
• Compromised or unencrypted backups
• Weak or reused passwords
• Password disclosure through phishing or coercion
• Access while the computer is unlocked
• Hardware tampering before you enter the password
• Traffic analysis when encrypted storage is transmitted over a network
• Unauthorized modification of ciphertext

VeraCrypt provides confidentiality, but its normal disk-encryption format does not authenticate all encrypted data. The documentation warns that VeraCrypt does not preserve or verify the integrity or authenticity of data stored in a volume. An attacker able to modify ciphertext may corrupt blocks or restore older ciphertext blocks. Use signatures, hashes, authenticated application formats, version control, and trusted backups when integrity matters. (veracrypt.io)

Is VeraCrypt Safe?

VeraCrypt is a serious, actively maintained encryption project, but “safe” is not a permanent binary property.

A Quarkslab assessment of VeraCrypt 1.18 in 2016 identified multiple issues, including a critical vulnerability that was addressed in the following release. A broader evaluation commissioned by Germany’s Federal Office for Information Security and conducted by Fraunhofer SIT was published in 2020. That evaluation reported no serious vulnerabilities but identified opportunities to improve development processes and code quality. (ostif.org)

Those assessments increase confidence, but they are not a timeless certification of every later release. VeraCrypt has evolved considerably since then, including substantial bootloader work and the addition of Argon2id in 1.26.29.

The practical security answer is:

• Use the current stable release.
• Read release notes before upgrading security-critical systems.
• Verify downloads.
• Use strong credentials.
• Maintain tested backups.
• Understand the runtime threat model.
• Avoid unsupported platform configurations.
• Do not treat hidden volumes or cipher cascades as magic.

VeraCrypt vs TrueCrypt

VeraCrypt is a maintained descendant of TrueCrypt, whose development stopped in 2014.

VeraCrypt retained the broad volume model and much of TrueCrypt’s design while adding platform support, security changes, higher password-derivation costs, new algorithms, and many implementation fixes.

Current users should create new volumes in the VeraCrypt format. The official download page directs users who still need TrueCrypt-format support to VeraCrypt 1.25.9, primarily as a migration path. Convert the old volume, verify the converted data, and then return to the current VeraCrypt release. Do not keep obsolete software in normal use merely to preserve an old volume format. (veracrypt.io)

A safe migration workflow is:

1. Make a verified backup of the TrueCrypt volume.
2. Obtain VeraCrypt 1.25.9 from the official legacy download page.
3. Verify the download.
4. Mount or convert the old volume according to the official conversion guide.
5. Copy critical files to a newly created current-format VeraCrypt volume if needed.
6. Test the new volume on every required system.
7. Retire the old volume only after confirming the backup and migration.

Core VeraCrypt Concepts

Volume

A volume is the encrypted block-storage object managed by VeraCrypt. It may be hosted in a file, partition, or device.

Container

A container is a normal host file whose contents form a VeraCrypt volume.

For example:

D:\Encrypted\projects.hc

The .hc extension is conventional, not mandatory. A container can be moved, renamed, copied, or deleted like any other file while it is unmounted.

Partition-hosted volume

A partition-hosted volume occupies one partition on a physical drive. The partition table remains outside that encrypted partition and can reveal the partition’s existence, boundaries, and approximate size.

Device-hosted volume

A device-hosted volume uses the physical device rather than a single existing partition. This can hide the device’s internal partition structure, but the operating system may consider the device uninitialized or unformatted until VeraCrypt mounts it.

System volume

A system volume contains the Windows installation that boots from it. VeraCrypt system encryption adds pre-boot authentication so that the correct password is required before Windows starts.

Mounted volume

A mounted volume has been unlocked and presented to the operating system as usable storage.

On Windows, it normally receives a drive letter. On Linux and macOS, its filesystem is attached to a mount point.

Unmounted volume

An unmounted volume is locked. Its filesystem is no longer available through the operating system.

Current VeraCrypt versions use Unmount in the interface and documentation. Older tutorials may say Dismount. The older command-line form remains available in some contexts but is deprecated in favor of --unmount on Unix-like systems. (veracrypt.io)

How to Download and Install VeraCrypt Safely

Download VeraCrypt only from the official project site or the release links provided there.

Do not use a generic software-download portal. Encryption software is exactly the kind of package for which an altered installer would be catastrophic.

VeraCrypt 1.26.29 supports:

• Windows 11 on x64 and ARM64
• Windows 10 version 1809 or later on x64 and ARM64
• Windows Server 2019 or later on x64
• macOS 12 Monterey or later
• Linux on x86, x86-64, and ARM64
• Several BSD and Raspberry Pi configurations

System encryption has a narrower support matrix than ordinary containers and device-hosted volumes. (veracrypt.io)

Windows installation

The official download page provides:

• An EXE installer for x64 and ARM64
• MSI installers
• A portable package

For a normal workstation, use the installed version. System encryption requires an installed VeraCrypt environment and cannot be treated as a portable-only workflow.

Portable mode is useful for carrying the application alongside a container, but it does not eliminate driver, permission, or administrative requirements on the computer where you run it.

Linux installation

The official project provides:

• An AppImage
• Generic installers
• Debian and Ubuntu packages
• RPM packages
• GUI and console-only builds

Use the package built for your distribution when one is available.

For a downloaded Debian or Ubuntu package:

sudo apt install ./veracrypt-1.26.29-<distribution>-amd64.deb

Replace the placeholder with the exact official filename for your distribution.

For the AppImage:

chmod +x VeraCrypt-1.26.29-x86_64.AppImage
./VeraCrypt-1.26.29-x86_64.AppImage

Do not blindly paste filenames from an old tutorial. Package names and supported distribution releases change.

macOS installation

VeraCrypt 1.26.29 supports macOS 12 Monterey and later. It requires a compatible FUSE implementation to expose mounted filesystems.

The official download page offers:

• A macFUSE-compatible build
• A FUSE-T-compatible build

The project recommends the FUSE-T-compatible version for Apple silicon Macs. Install the selected FUSE implementation and the matching VeraCrypt package rather than mixing the two variants. (veracrypt.io)

VeraCrypt on macOS supports ordinary file-hosted and device-hosted volumes. It does not provide VeraCrypt system encryption for the Mac startup disk.

Use Apple FileVault for startup-disk protection.

How to Verify a VeraCrypt Download

VeraCrypt publishes:

• PGP signatures for binary and source packages
• X.509 signatures for Windows binary packages
• SHA-256 and SHA-512 checksum files

A checksum detects accidental changes only if you already trust the checksum. A signed checksum or package signature provides a path to verifying authenticity.

Verify the Windows installer signature

For the EXE installer:

1. Right-click the installer.
2. Select Properties.
3. Open Digital Signatures.
4. Inspect the listed signature.
5. Open its details and confirm Windows reports that the signature is valid.

The official documentation identifies the expected signer as IDRIX or IDRIX SARL. (veracrypt.io)

Verify a PGP signature

The current official VeraCrypt PGP key fingerprint documented by the project is:

5069 A233 D55A 0EEB 174A 5FC3 821A CD02 680D 16DE

Inspect the key before importing it:

gpg --import-options show-only --import VeraCrypt_PGP_public_key.asc

If the fingerprint matches the official documentation, import it:

gpg --import VeraCrypt_PGP_public_key.asc

Then verify the detached signature:

gpg --verify veracrypt-package.sig veracrypt-package

Change both filenames to the package and signature you downloaded.

A successful cryptographic signature check proves that the package was signed by the corresponding key. You still need a trustworthy way to establish that the fingerprint belongs to the VeraCrypt project.

Which VeraCrypt Option Should I Use?

Use a file container when:

• You need to encrypt a selected set of files.
• You want an encrypted archive that can be moved or backed up as one file.
• You want to place encrypted storage on an otherwise unencrypted drive.
• You need a volume that can be synchronized or transported carefully.

Encrypt a partition when:

• One partition should be encrypted but other partitions must remain available.
• You want an unencrypted compatibility or tools partition beside encrypted storage.
• You need the partition table to remain visible.

Encrypt an entire non-system device when:

• Everything on an external drive or USB stick should be encrypted.
• You do not need an unencrypted partition.
• You want to reduce accidental plaintext storage on the same device.

Use Windows system encryption when:

• You need Windows temporary files, logs, the registry, pagefile, and hibernation data on the system partition protected at rest.
• You are comfortable managing pre-boot authentication and recovery media.
• Your Windows architecture and boot configuration are supported.

Use a hidden volume only when:

• Coercive password disclosure is a realistic part of your threat model.
• You understand operational metadata leakage.
• You can follow the hidden-volume rules consistently.
• You accept a significantly more fragile workflow.

Use FileVault instead when:

• You need to encrypt the startup disk of a Mac.

Use LUKS instead when:

• You need native Linux root or full-disk encryption.
• You need integration with the Linux boot process, initramfs, TPM tooling, or system administration stack.

How to Create a VeraCrypt File Container

A container is usually the best place for a new user to start. It is easier to back up, test, move, and abandon than a fully encrypted physical device.

Before creating it

Decide:

• What data belongs inside it
• Its maximum required capacity
• Which operating systems must read it
• Whether old VeraCrypt versions must mount it
• Where its backups will live
• Whether plausible deniability is actually required

Do not size the container only for today’s files. Leave room for application metadata, filesystem overhead, build outputs, version history, and normal growth.

At the same time, remember that a regular container occupies its configured size on the host filesystem. A 200 GiB container is operationally awkward even if it contains only 20 GiB of files.

Complete container walkthrough

1. Open VeraCrypt.
2. Select Create Volume.
3. Choose Create an encrypted file container.
4. Choose Standard VeraCrypt volume.
5. Select the location and filename for the container.
6. Choose the encryption algorithm.
7. Choose the KDF and related options.
8. Set the volume size.
9. Set the password.
10. Configure PIM or keyfiles only if required.
11. Select a filesystem and cluster size.
12. Generate entropy as requested by the wizard.
13. Format the volume.
14. Mount it and perform a write test.
15. Unmount it.
16. Mount it again to verify the credentials.
17. Back up the container or its contents.

The official beginner’s tutorial follows the same basic wizard flow. (veracrypt.io)

Encryption algorithm

For most users, choose AES.

AES is widely analyzed, normally hardware-accelerated on modern CPUs, and usually the best balance of performance, compatibility, and simplicity.

Choosing three algorithms because three sounds stronger is not automatically a better security decision. Cipher cascades increase computational work and configuration complexity. They do not repair weak passwords, malware, unencrypted backups, or an unsafe recovery plan.

KDF

For a new non-system volume in VeraCrypt 1.26.29, choose Argon2id unless you need compatibility with a VeraCrypt version that predates Argon2id support.

Argon2id is memory-hard, which increases the cost of large-scale password guessing on GPUs and other specialized hardware. In VeraCrypt, it is available only for non-system volumes. System encryption continues to use PBKDF2-HMAC. (veracrypt.io)

If you need to mount the volume using an older VeraCrypt release, use PBKDF2-HMAC instead. Older software cannot understand a KDF added in 1.26.29.

Password

Use a unique password that is not used for an account, password manager, laptop login, or another encrypted volume.

Good approaches include:

• A long random password generated and stored by a password manager
• A long, randomly generated multiword passphrase
• A high-entropy secret stored in a documented recovery process

Do not rely on:

• A quote
• A song lyric
• A keyboard pattern
• A date plus punctuation
• A company or project name
• A reused “strong” password
• Character substitutions such as P@ssw0rd

The KDF slows password guesses. It cannot turn a predictable password into a good one.

PIM

For a normal deployment, leave PIM blank and use the default.

A custom PIM becomes part of the required authentication input. If you forget it, the correct password alone will not mount the volume.

VeraCrypt 1.26.29 uses an Argon2id default equivalent to PIM 12, with 416 MiB of memory and a time cost of six iterations. PBKDF2 uses different PIM formulas and defaults. (veracrypt.io)

Do not lower PIM merely because the mount delay feels inconvenient. Do not raise it to a huge value without testing every target computer, recovery environment, and automation path.

Filesystem

Choose based on the systems that must mount the volume:

• NTFS is a practical choice for Windows-focused use.
• ext4 is appropriate for Linux-only use.
• APFS is appropriate for modern macOS-only use.
• exFAT is usually the simplest choice for Windows, Linux, and macOS interoperability.
• FAT can be useful for small, highly compatible volumes but has more restrictive file and volume behavior.

Encryption does not make a filesystem portable. VeraCrypt can unlock the encrypted block device, but the operating system must still understand the filesystem inside it.

Quick Format

If you are unsure, leave Quick Format disabled.

A full format fills the volume with encrypted random-looking data. Quick Format is faster but can reveal which regions have not yet been allocated, depending on the host storage and filesystem.

Never use Quick Format for an outer volume that will contain a hidden volume. (veracrypt.io)

Dynamic containers

A dynamic container is an NTFS sparse file whose physical host size grows as data is added.

It sounds convenient, but it has significant drawbacks:

• Unused regions are distinguishable.
• Performance is worse.
• The host filesystem can run out of space even though the encrypted filesystem believes space remains.
• A failed host allocation can corrupt the filesystem inside the container.
• It is unsuitable for hidden-volume workflows.

Use a regular fixed-size container unless you have a specific reason to accept those risks. (veracrypt.io)

How to Mount and Unmount a Container

GUI workflow

1. Open VeraCrypt.
2. Choose an unused slot or drive letter.
3. Click Select File.
4. Select the container.
5. Click Mount.
6. Enter the password.
7. Enter the correct PIM if a custom PIM is used.
8. Select the required keyfiles if applicable.
9. Use the mounted filesystem normally.
10. Close every application using it.
11. Return to VeraCrypt.
12. Select the mounted volume.
13. Click Unmount.

Read-only mounting

Use a read-only mount when:

• Examining an old backup
• Performing forensic inspection
• Testing whether a volume mounts
• Recovering files from questionable storage
• Opening an outer volume without risking writes
• Preventing accidental modification

Read-only mounting protects the filesystem from normal writes through that mounted view. It does not make untrusted data safe to open.

Force unmount

Force unmount exists for situations where an application refuses to release a file handle.

Use it as a last resort.

Forced unmounting can leave application writes incomplete and may damage the filesystem. It also does not erase decrypted copies that an application still holds in RAM. (veracrypt.io)

Automatic mounting and favorites

Favorites can reduce repetitive setup, but convenience changes the threat model.

Consider:

• Whether credentials are cached
• Whether the volume mounts whenever the user logs in
• Whether the machine is unattended
• Whether auto-mounting exposes the volume to ransomware
• Whether a removable device could be replaced
• Whether a failed mount leaks useful information into logs

Automatically mounting a volume is reasonable for availability and workflow automation. It is not the strongest choice when the main benefit comes from keeping sensitive storage locked most of the time.

Container File Management

An unmounted container is a normal file. You can:

• Rename it
• Move it
• Copy it
• Store it on another drive
• Back it up
• Delete it

Unmount it before moving or copying it.

Copying a live container while its internal filesystem is changing may create a backup containing an inconsistent mix of old and new encrypted sectors. The copied file may mount while still containing a damaged filesystem.

Avoid misleading extensions

Do not disguise a large encrypted container as a JPEG, MP4, DLL, or other unrelated file type.

That does not provide meaningful secrecy, and applications may modify or “repair” the file because of its extension.

A neutral extension such as .hc, .bin, or no extension is less likely to invite accidental processing.

What happens if a container is deleted?

Deleting a container removes the host filesystem’s reference to it. It does not guarantee that every physical copy, cloud version, snapshot, journal fragment, or backup has disappeared.

On flash storage, SSD garbage collection and wear leveling make reliable overwrite claims especially difficult.

If cryptographic erasure is important, control the entire storage lifecycle and all copies. Do not assume that deleting one visible file eliminated every copy of its ciphertext.

VeraCrypt Containers in Cloud Storage

A VeraCrypt container can be placed in a cloud-synchronized directory, but the safe workflow is restrictive:

1. Mount it on only one computer.
2. Finish all work.
3. Close applications using it.
4. Unmount it.
5. Allow synchronization to complete.
6. Confirm that the destination has the complete version.
7. Only then mount it elsewhere.

Do not mount the same writable container from multiple computers.

Concurrent filesystem modification can corrupt ordinary filesystems, encrypted or not. VeraCrypt’s network-sharing documentation permits simultaneous access to a shared container only under constrained read-only conditions. (veracrypt.io)

Cloud storage also exposes information outside the encrypted contents:

• Container size
• Filename and path
• Modification time
• Update frequency
• Account identity
• Previous versions
• Device and IP access records

A container protects its internal plaintext. It does not make cloud activity invisible.

For active multi-device work, file-level encryption or an application designed for concurrent encrypted synchronization may be more suitable than repeatedly synchronizing one large block-level filesystem image.

Encrypting a USB Drive With VeraCrypt

Yes, VeraCrypt can encrypt a USB flash drive.

You have three practical designs:

• Encrypt the entire device
• Encrypt one partition and leave another unencrypted
• Store a VeraCrypt container on the existing USB filesystem

Which USB design should you choose?

Encrypt the entire device when:

• Everything on it is sensitive.
• You do not need unencrypted compatibility storage.
• You can install or run VeraCrypt on every computer that needs it.

Encrypt a partition when:

• You want a small unencrypted partition for tools or instructions.
• You need both plaintext and encrypted storage.
• You understand that the partition layout remains visible.

Use a container when:

• You need some ordinary unencrypted files on the USB stick.
• You want easier copying and backup.
• You want to keep VeraCrypt portable files outside the container.
• You accept that the host filesystem reveals the container file.

USB encryption walkthrough

First, back up the USB drive. The normal creation workflow formats the selected partition or device and destroys its existing contents.

Then:

1. Insert the USB drive.
2. Confirm its exact capacity and device identity.
3. Open VeraCrypt.
4. Select Create Volume.
5. Choose Encrypt a non-system partition/drive.
6. Choose Standard VeraCrypt volume.
7. Click Select Device.
8. Select the USB device or the intended partition.
9. Recheck the manufacturer, size, and device path.
10. Choose AES unless you have a documented reason not to.
11. Choose Argon2id for a new non-system volume if all target computers run VeraCrypt 1.26.29 or later.
12. Set a long, unique password.
13. Leave PIM at the default unless you have a tested plan.
14. Select the filesystem.
15. Format the volume.
16. Mount it and copy a test file.
17. Unmount it.
18. Mount it again and verify the test file.
19. Back up the actual data you plan to store on it.

Selecting the wrong device can destroy another disk. Capacity alone is not a sufficient identifier if multiple similar drives are attached.

Device or partition?

If you encrypt a partition, the device retains a visible partition table.

If you encrypt the device, the operating system may see no conventional partition table and may ask you to initialize or format it. Decline that prompt. Mount the device through VeraCrypt instead.

USB filesystem choice

For broad compatibility, exFAT is usually the practical choice.

For a Windows-only USB drive, NTFS offers Windows-native behavior.

For Linux-only use, ext4 is generally more appropriate.

For macOS-only use, APFS may be appropriate.

Test the final choice on every target operating system before depending on it.

Safe removal

The correct order is:

1. Close files and applications.
2. Unmount the VeraCrypt volume.
3. Use the operating system’s eject or safely-remove function.
4. Wait for confirmation.
5. Physically remove the USB drive.

Removing the device while its VeraCrypt volume is mounted can cause data loss or filesystem corruption. (veracrypt.io)

What if the encrypted USB drive is lost?

If the volume was unmounted, the password is strong and unique, the required keyfiles were not stored with it, and the computer used to unlock it was not compromised, the finder should not be able to read the encrypted contents through ordinary offline examination.

They can still learn physical facts such as:

• The device model
• Its capacity
• Its serial number
• Whether it appears to contain random-looking data
• Any visible unencrypted partition structure

If the drive was lost while attached to an unlocked machine, the threat model is different. VeraCrypt cannot retroactively lock a volume that an attacker can already access.

What if the USB volume becomes corrupted?

A VeraCrypt volume has an embedded backup header, but that protects only against certain header failures. It does not reconstruct damaged files, repair NAND failure, or replace a filesystem backup.

The recovery order is:

1. Stop writing to the device.
2. Make a sector-level image if possible.
3. Work on a copy.
4. Confirm the password, PIM, keyfiles, and KDF.
5. Try the embedded backup header.
6. If the volume mounts but the filesystem fails, use filesystem-specific recovery tools on a copy.
7. Restore files from backup whenever possible.

Encrypting an External HDD or SSD

For an external drive, choose between:

• One large encrypted partition
• An entire-device VeraCrypt volume
• One or more file containers

Entire-device encryption

Advantages:

• Everything written through the mounted device is encrypted.
• There is less temptation to leave plaintext beside the protected data.
• The internal partition structure is not exposed in the usual way.

Disadvantages:

• Operating systems may call it blank, RAW, or uninitialized.
• Partitioning and compatibility workflows are less conventional.
• Accidental formatting prompts become a serious risk.
• You cannot keep ordinary unencrypted files on the same device.

Partition encryption

Advantages:

• You can keep separate encrypted and unencrypted partitions.
• The device remains conventionally partitioned.
• Recovery and device identification may be easier.

Disadvantages:

• Partition boundaries and sizes remain visible.
• Users can accidentally store sensitive files on an unencrypted partition.
• The partition table may reveal more about the device’s intended use.

Encrypting existing data in place

Do not assume VeraCrypt can safely encrypt any existing filesystem in place.

The official documentation describes non-system in-place encryption for NTFS partitions on Windows. For other filesystems and platforms, the conservative workflow is:

1. Back up the data.
2. Verify the backup.
3. Create a new encrypted volume.
4. Copy the files into it.
5. Verify the copied files.
6. Retain the backup until the new volume has been used and tested.

Even when the wizard offers in-place encryption, make a verified backup first. In-place encryption is not a backup mechanism, and hardware failure during a long conversion can still destroy data. (veracrypt.io)

Partition Encryption vs Entire-Device Encryption

The key distinction is the encryption boundary.

With a partition-hosted volume:

• The partition table is outside the VeraCrypt volume.
• Other partitions can exist.
• Only the selected partition is encrypted.
• The device’s broad layout remains visible.

With an entire-device volume:

• VeraCrypt uses the device as the volume host.
• A conventional partition table may not be available to the operating system.
• The device may appear unformatted until mounted.
• Accidentally initializing or formatting it can damage the volume.

Neither option automatically makes backups, prevents hardware failure, or protects data while mounted.

VeraCrypt System Encryption

VeraCrypt system encryption protects the Windows system partition or system drive and requires authentication before Windows boots.

This is not the same thing as mounting a container after login.

The VeraCrypt bootloader obtains the password, derives the required key material, unlocks the system volume, and allows Windows to start. Reads and writes are then encrypted and decrypted on the fly.

Current support limitations

VeraCrypt 1.26.29 system encryption officially supports:

• Windows 11 x64
• Windows 10 version 1809 or later on x64

Windows ARM64 supports non-system volumes only. VeraCrypt system encryption is not currently supported on Windows ARM64. (veracrypt.io)

VeraCrypt does not provide system encryption for:

• macOS
• Linux
• Windows on ARM64
• Unsupported legacy Windows configurations
• Windows installed for native boot inside VHD or VHDX files

What system encryption protects

Within its encrypted key scope, system encryption protects data such as:

• Windows system files
• User profiles
• Registry data
• Application files
• Temporary files on the encrypted system partition
• The Windows pagefile, if it resides within the encrypted scope
• The hibernation file on the encrypted system partition
• Logs and recent-file metadata stored there
• Crash-related data stored within the encrypted scope

This is a major advantage over keeping only selected files in a container. Applications often create plaintext artifacts outside the directory containing the original file. System encryption protects those artifacts at rest when they remain within the encrypted system area. (veracrypt.io)

What system encryption does not protect

It does not protect:

• A running, unlocked Windows session from malware
• Data copied to unencrypted drives
• Data uploaded to remote services
• Unencrypted backups
• RAM while the system is running
• Passwords captured by a keylogger
• Hardware modified before password entry
• Data on separate partitions outside the encrypted scope
• The EFI System Partition on modern UEFI systems
• Ciphertext integrity against all unauthorized modification

UEFI and EFI considerations

On modern UEFI systems, the EFI System Partition must remain unencrypted so firmware can load the bootloader.

As a result, the VeraCrypt wizard normally encrypts the Windows system partition rather than literally every sector of the physical drive. Other data partitions need separate protection.

In legacy MBR boot mode, encrypting the entire system drive can include additional partitions within the selected key scope.

VeraCrypt 1.26.29 includes support for Microsoft UEFI CA 2023-signed EFI bootloaders while retaining compatibility with the earlier Microsoft UEFI CA 2011 trust path. If firmware Secure Boot trust entries change, the official documentation recommends repairing or reinstalling VeraCrypt so the appropriate bootloader set is refreshed. (veracrypt.io)

System encryption uses PBKDF2

Argon2id is not available for VeraCrypt system encryption.

The pre-boot environment uses PBKDF2-HMAC. Depending on the selected hash and PIM configuration, VeraCrypt applies the documented system-encryption iteration rules. (veracrypt.io)

Keyfiles are not supported for system encryption

VeraCrypt keyfiles can be used with ordinary containers and non-system volumes, but not with system encryption. Pre-boot authentication uses the password and optional PIM rather than a normal VeraCrypt keyfile workflow. (veracrypt.io)

Before Enabling Windows System Encryption

Do all of this first:

1. Create a complete backup of important data.
2. Verify that the backup can be opened.
3. Create separate recovery media for Windows.
4. Install all pending firmware and storage-driver updates.
5. Confirm the system boots reliably before encryption.
6. Check the disk and filesystem for errors.
7. Confirm the Windows installation uses a supported x64 version.
8. Identify whether the system boots through UEFI or legacy MBR.
9. Document the partition layout.
10. Confirm that important data partitions are inside or outside the intended encryption scope.
11. Confirm where the Windows pagefile is stored.
12. Disable Windows Fast Startup if it is enabled.
13. Disconnect unnecessary external drives.
14. Decide how the VeraCrypt Rescue Disk will be stored and tested.
15. Record the password and custom PIM, if any, in a secure recovery process.
16. Ensure you have enough time and reliable power to complete the operation.
17. Do not proceed before the VeraCrypt pre-test succeeds.

Windows Fast Startup is a hybrid shutdown mechanism that can preserve system state in ways that cause surprising VeraCrypt behavior. VeraCrypt’s known-limitations documentation recommends disabling it. (veracrypt.io)

The System Encryption Pre-Test

The wizard performs a pre-test before committing to full encryption.

The pre-test installs the VeraCrypt boot path and verifies that:

• The bootloader starts
• The keyboard works as expected
• The password is accepted
• Windows can boot through the VeraCrypt path
• The firmware and storage configuration are compatible enough to continue

Do not bypass or casually dismiss failures.

A failed pre-test is valuable. It means the system found a boot problem before the entire Windows partition was encrypted.

Pre-boot keyboard behavior

VeraCrypt’s pre-boot environment uses the US keyboard layout. During setup, VeraCrypt switches input handling to help ensure that the password corresponds to the keys available before Windows starts.

Type the password manually during setup and testing. Be especially careful with symbols whose positions differ across keyboard layouts. (veracrypt.io)

VeraCrypt Rescue Disk

The VeraCrypt Rescue Disk is recovery media created for a specific system-encryption setup.

In EFI boot mode, it is normally USB-based. In legacy MBR mode, the traditional workflow uses CD or DVD, with an additional documented USB approach.

Depending on the failure, the Rescue Disk can:

• Start the VeraCrypt bootloader
• Restore bootloader files
• Restore system-volume header key data
• Help mount the system partition without normal pre-boot authentication
• Restore the original system loader in certain legacy MBR scenarios

It cannot:

• Recover a forgotten password
• Guess a forgotten PIM
• Replace destroyed user data
• Repair arbitrary filesystem corruption
• Replace a full backup
• Unlock a system without the required credentials

The recovery media does not contain a plaintext copy of your password. Finding it does not, by itself, let an attacker decrypt the system. (veracrypt.io)

Test the Rescue Disk

A recovery artifact you have never booted is only a theory.

After creating it:

1. Use VeraCrypt’s System > Verify Rescue Disk function.
2. Boot the computer from it.
3. Confirm the firmware recognizes it.
4. Confirm the rescue interface loads.
5. Do not perform a destructive restore operation merely as a test.
6. Store a second protected copy of the rescue image or media.
7. Recreate it if firmware trust configuration changes or VeraCrypt instructs you to do so.

What Happens When System Encryption Goes Wrong?

The bootloader does not appear

Boot from the VeraCrypt Rescue Disk and use the documented loader-restoration option.

On EFI systems, the relevant operation restores VeraCrypt loader binaries to the system disk. On legacy MBR systems, use the corresponding bootloader repair option.

The bootloader appears but rejects the correct password

Check:

• US keyboard layout assumptions
• Caps Lock
• Symbol positions
• PIM
• Whether the password was changed
• Whether you are booting the expected disk

If credentials are definitely correct, the system header may be damaged. The Rescue Disk can restore the protected header data in supported scenarios, but it will still require the correct password.

Windows fails after authentication

The encryption layer may be unlocking correctly while Windows itself has a boot, update, driver, or filesystem problem.

Do not immediately rewrite boot structures with unrelated tools. Generic repair tools may replace the VeraCrypt bootloader or modify the encrypted system unexpectedly.

Use the Rescue Disk, your documented partition layout, Windows recovery media, and a verified backup.

The machine becomes unreliable during encryption

Stop and investigate power, storage health, firmware, and driver issues. Do not repeatedly force shutdowns during unexplained disk errors.

Although the encryption operation can be paused and resumed, resumability does not make failing hardware safe. (veracrypt.io)

Hidden Operating Systems

VeraCrypt documentation still describes hidden operating systems, in which a hidden Windows installation exists inside a hidden volume and a separate decoy system can be disclosed.

This is a highly specialized feature.

EFI hidden-OS and full-drive configurations were introduced through an advanced manual procedure rather than an ordinary, broadly exposed wizard workflow. The operational requirements are extensive, and much of the public hidden-OS documentation reflects older Windows examples. (veracrypt.io)

I would not recommend a hidden operating system to an advanced beginner.

Use it only if:

• Coercive disclosure is a concrete threat
• You can maintain a believable decoy system
• You understand firmware, bootloader, filesystem, RAM, logging, and network metadata
• You can follow VeraCrypt’s hidden-system precautions exactly
• You are prepared for a more fragile recovery process

A hidden operating system is not an “extra private mode.” It is a strict operational-security system whose plausible-deniability properties can be undermined by ordinary activity.

VeraCrypt on Linux

VeraCrypt supports containers, partitions, and devices on Linux. It does not replace native Linux root-disk encryption.

For Linux system encryption, LUKS is the normal choice. Ubuntu’s current documentation describes LUKS block-level encryption, with LUKS2 supporting Argon2-based password derivation and integration with the Linux boot and device-mapper stack. (documentation.ubuntu.com)

Use VeraCrypt on Linux when you need:

• Cross-platform containers
• A VeraCrypt-formatted external drive
• Compatibility with Windows VeraCrypt workflows
• A portable encrypted archive
• GUI or CLI access to non-system volumes

Use LUKS when you need:

• Encrypted Linux root storage
• Boot-time unlocking
• Native device-mapper integration
• Linux key-slot management
• Distribution installer integration
• TPM-assisted Linux full-disk encryption

Basic Linux CLI usage

Display current help:

veracrypt -t --help

Mount interactively:

veracrypt -t --mount ~/vaults/projects.hc

Mount at a specific directory:

veracrypt -t ~/vaults/projects.hc /media/veracrypt1

Mount read-only:

veracrypt -t -m ro ~/vaults/projects.hc /media/veracrypt1

List mounted volumes:

veracrypt -t --verbose --list

Unmount one volume:

veracrypt -t --unmount ~/vaults/projects.hc

Unmount all VeraCrypt volumes:

veracrypt -t --unmount

The --dismount command is deprecated. Use --unmount. (veracrypt.io)

Linux permissions

A VeraCrypt password unlocks encryption. It does not override Unix ownership and permissions inside the mounted filesystem.

Common issues include:

• The mount directory is owned by root.
• Files inside an ext4 volume belong to a different UID.
• An exFAT or NTFS mount uses unexpected ownership options.
• A desktop environment mounted the physical device before VeraCrypt.
• A FUSE or privilege prompt was dismissed.
• The current user cannot access the selected device node.

For Linux-only use, choose a Linux-native filesystem and set ownership after mounting.

For cross-platform use, expect simpler permission semantics from filesystems such as exFAT.

Linux automation

Do not put passwords directly in command-line arguments. They may be exposed through process listings, shell history, logs, or automation output.

VeraCrypt supports reading a password from standard input in non-interactive mode:

printf '%s\n' "$VERACRYPT_PASSWORD" |
    veracrypt -t \
        --non-interactive \
        --stdin \
        --pim=0 \
        --protect-hidden=no \
        "$VOLUME_PATH" \
        "$MOUNT_POINT"

This avoids placing the password in a normal command-line argument, but an environment variable is not automatically a secure secret store. Prefer a dedicated secrets mechanism, restricted process environment, or interactive prompt where possible.

The official CLI documentation explicitly warns that passwords, PIMs, token PINs, and hidden-volume credentials passed as arguments can be exposed. (veracrypt.io)

Linux filesystem options

Current VeraCrypt CLI documentation lists creation support on Linux for filesystems including:

• FAT
• ext2
• ext3
• ext4
• NTFS
• exFAT
• Btrfs

The required system formatter must be installed. VeraCrypt 1.26.29 also adds Linux options for selecting in-kernel NTFS drivers during mounting. (veracrypt.io)

VeraCrypt on macOS

VeraCrypt on macOS is useful for:

• Cross-platform containers
• Encrypted external drives
• Exchanging VeraCrypt volumes with Windows or Linux
• Separating selected data from the normal Mac filesystem

It is not a replacement for FileVault on the startup disk.

VeraCrypt volume encryption vs FileVault

VeraCrypt:

• Creates independently mounted containers or device-hosted volumes
• Uses its own password, KDF, and volume format
• Can support cross-platform workflows
• Does not integrate as the Mac startup-disk encryption system

FileVault:

• Is integrated with macOS startup and account authentication
• Protects the Mac’s internal data volume
• Uses Apple’s Secure Enclave and hardware encryption capabilities on supported Macs
• Provides Apple-specific recovery workflows

On Apple silicon and T2-equipped Macs, Apple’s encryption hierarchy integrates with the Secure Enclave. FileVault adds user-credential protection to the internal volume’s encryption key. (support.apple.com)

For a modern Mac:

• Turn on FileVault for the startup disk.
• Use VeraCrypt when you specifically need containers, cross-platform storage, or independently managed removable encryption.

What Is a VeraCrypt Hidden Volume?

A hidden volume is an encrypted volume stored inside the apparent free space of another VeraCrypt volume.

The outer and hidden volumes use different credentials.

Entering the outer password mounts the outer volume. Entering the hidden password against the same host mounts the hidden volume.

The intent is that a user under coercion can disclose the outer password while denying that an additional volume exists.

A hidden volume is not a directory inside the outer filesystem. Its data occupies sectors that the outer filesystem considers free. (veracrypt.io)

Outer volume

The outer volume should contain plausible, sensitive-looking files that you are genuinely willing to disclose.

Its password must be different from the hidden-volume credentials.

Hidden volume

The hidden volume occupies a reserved region toward the end of the host volume’s apparent free space.

Its header is placed in an area that contains random-looking data when no hidden volume exists. VeraCrypt determines whether to mount the outer or hidden volume by attempting to decrypt the relevant headers with the provided credentials. (veracrypt.io)

How to Create a Hidden Volume

1. Select Create Volume.
2. Choose Create an encrypted file container or a suitable non-system device.
3. Choose Hidden VeraCrypt volume.
4. Create the outer volume.
5. Do not enable Quick Format.
6. Mount the outer volume when instructed.
7. Add believable decoy files.
8. Unmount it.
9. Continue the wizard.
10. Let VeraCrypt determine the available hidden-volume space.
11. Create the hidden volume with different credentials.
12. Test the outer password.
13. Test the hidden password.
14. Practice mounting the outer volume with hidden-volume protection.
15. Back up the actual files, not by cloning the entire hidden-volume host.

Critical 1.26.29 warning

If you created a hidden volume inside a file container using VeraCrypt 1.26.6 through 1.26.28 and rely on plausible deniability, the release notes instruct you to recreate both the outer file container and hidden volume using VeraCrypt 1.26.29 or later, then securely retire the old container.

A quick-format behavior in those versions could write plaintext zero sectors at regular intervals and undermine plausible deniability. (veracrypt.io)

Protecting a Hidden Volume From Overwrite

The outer filesystem does not know that the hidden volume exists. If you add too much data to the outer volume, it may allocate sectors occupied by the hidden volume.

To write to the outer volume safely:

1. Mount the outer volume.
2. Open Mount Options.
3. Enable Protect hidden volume against damage caused by writing to outer volume.
4. Enter the hidden-volume credentials.
5. Mount the outer volume.

VeraCrypt reads the hidden-volume header into RAM to determine its boundaries. It does not mount the hidden filesystem. Writes that would overlap the hidden area are rejected.

If a write reaches that area, the outer volume becomes write-protected until unmounted. (veracrypt.io)

You must enable this protection every time you mount the outer volume for writing.

If you only need to read outer-volume files, mount it read-only.

The Limits of Plausible Deniability

Plausible deniability is not mathematical proof that no hidden volume exists.

It can fail operationally because of:

• Filesystem journals
• Container timestamps
• Host filesystem fragments
• Backups
• Cloud version history
• Recently opened file lists
• Search indexes
• Thumbnail caches
• Application logs
• Temporary files
• Swap or pagefiles
• Crash dumps
• Network records
• Observed changes between copies of the volume
• SSD wear leveling
• TRIM
• The user’s behavior
• Disclosure requirements in a legal jurisdiction

The official hidden-volume precautions are demanding. They warn that ordinary operating systems and applications may write filenames, file contents, passwords, or other evidence to non-hidden storage. (veracrypt.io)

Hidden volumes make sense only under a narrowly defined coercion threat model. They are not necessary for normal stolen-device protection.

Keyfiles

A VeraCrypt keyfile is additional input combined with the password when deriving access to a non-system volume.

A keyfile can be:

• A file generated by VeraCrypt
• Another existing file
• One of several files
• Data stored through a supported security token or smart card

VeraCrypt processes only the first 1 MiB of each keyfile. (veracrypt.io)

What a keyfile changes

Without the correct keyfile, the password alone will not mount the volume.

That can add useful separation:

• Password in a password manager
• Keyfile on a separate removable device
• Encrypted volume stored elsewhere

It also creates a new permanent failure mode.

If the keyfile is lost or any processed bit changes, the volume cannot be mounted with the original credential set. (veracrypt.io)

Should a keyfile replace a strong password?

Usually, no.

A keyfile is best treated as an additional factor, not permission to use a weak password.

If an attacker obtains both the container and a keyfile stored beside it, only the password remains. If the password is weak, the keyfile arrangement provided little lasting value.

Sensible keyfile storage

Good options include:

• A VeraCrypt-generated random keyfile
• Multiple verified copies on separate encrypted media
• A supported hardware token
• A carefully documented organizational escrow process

Bad options include:

• The same directory as the container
• The only copy on the same USB device
• A photo or office document that may be edited or re-encoded
• A file synchronized through an account that also stores the container and password
• An undocumented keyfile known only to one employee

After creating a keyfile, compare the backup copies byte for byte.

On Linux:

sha256sum keyfile.bin keyfile-backup.bin

On macOS, the equivalent built-in command may be:

shasum -a 256 keyfile.bin keyfile-backup.bin

Matching hashes confirm that the copies are identical. Store the hash carefully if it reveals the keyfile’s identity or location.

Passwords, PIM, and Key Derivation

These are related but distinct:

• The password is the primary secret.
• A keyfile contributes additional secret input.
• The KDF turns that input into cryptographic key material.
• The PIM modifies the KDF’s work parameters.

What Is VeraCrypt PIM?

PIM means Personal Iterations Multiplier.

With PBKDF2, it affects the number of iterations. With Argon2id, it controls memory and time costs according to VeraCrypt’s formulas.

PIM can also act as an additional secret. The correct password with the wrong non-default PIM fails to mount.

That does not make PIM a substitute for password entropy. It mainly changes the cost of each password attempt and adds another value you must preserve.

When should you customize PIM?

Consider a custom PIM only when:

• You have benchmarked mount time on every required device.
• You understand whether the volume uses PBKDF2 or Argon2id.
• You have documented the PIM in a secure recovery system.
• You need a deliberate security or performance tradeoff.
• Automation can provide the exact value safely.

Leave it at the default when:

• You are uncertain.
• Other people must recover the volume.
• Multiple operating systems or older machines are involved.
• You are creating ordinary personal encrypted storage.
• You would be tempted to write the value on the device.

Forgotten password or PIM

VeraCrypt cannot recover a forgotten volume password.

There is no account reset, administrator override, vendor master key, or recovery email.

Recovery is possible only if you can reconstruct the credentials through:

• A remembered candidate
• A password-manager backup
• A documented escrow process
• A viable candidate search against a weak or partially known password

Header repair does not bypass authentication. The header contains the encrypted master keys, not a password-reset mechanism.

Argon2id vs PBKDF2 in VeraCrypt

Argon2id

Argon2id is the recommended KDF for new non-system volumes in VeraCrypt 1.26.29.

It is designed to consume both computation time and memory, increasing the cost of highly parallel password guessing.

VeraCrypt’s default Argon2id configuration is equivalent to PIM 12:

• 416 MiB memory
• Time cost of 6
• Parallelism of 1

Higher PIM values raise memory and time costs according to VeraCrypt’s documented formulas, with memory capped at 1,024 MiB. (veracrypt.io)

PBKDF2-HMAC

PBKDF2 remains available for non-system volumes and is used for system encryption.

For PBKDF2-HMAC, current VeraCrypt supports:

• SHA-512
• SHA-256
• BLAKE2s-256
• Whirlpool
• Streebog

Non-system PBKDF2 volumes use 500,000 iterations by default when PIM is left empty. System-encryption defaults depend on the selected hash. (veracrypt.io)

Which should you choose?

Choose Argon2id for a new non-system volume when:

• Every required system runs VeraCrypt 1.26.29 or later.
• The mount environment has enough RAM.
• You want a modern memory-hard KDF.

Choose PBKDF2 when:

• You need compatibility with older VeraCrypt releases.
• You are configuring Windows system encryption.
• A low-memory environment cannot handle the Argon2id configuration.
• An organizational compatibility standard requires it.

Should I Use AES, Serpent, or Twofish?

For most people: use AES.

VeraCrypt 1.26.29 supports individual ciphers including:

• AES
• Camellia
• Kuznyechik
• Serpent
• Twofish

It also supports multiple two-cipher and three-cipher cascades. All listed volume-encryption choices use XTS mode. (veracrypt.io)

AES

Choose AES when you want:

• Excellent performance
• Broad analysis and standardization
• Hardware acceleration on modern CPUs
• The least surprising configuration
• Strong interoperability across VeraCrypt installations

Serpent

Serpent is a conservative AES finalist with a larger round count than AES. It is available for users with a specific policy or design preference.

It is normally slower than hardware-accelerated AES.

Twofish

Twofish was also an AES finalist and remains a respected 128-bit block cipher with a 256-bit key option in VeraCrypt.

It is a reasonable alternative when a documented requirement calls for it, but it is not inherently a better default than AES.

Cipher cascades

Cascades encrypt each block through multiple independently keyed ciphers.

They may appeal to a threat model concerned about a catastrophic future break in one algorithm. The costs include:

• Lower performance
• More implementation paths
• More complex testing
• Longer boot or processing paths in some configurations
• No protection against weak credentials or compromised endpoints

More algorithms do not automatically mean more security.

For ordinary use, a long unique password, a suitable KDF, verified software, and reliable backups matter more than replacing AES with a three-cipher cascade.

How VeraCrypt Encryption Works

VeraCrypt stores randomly generated master keys in the encrypted volume header.

The password is not used directly as the data-encryption key.

At mount time:

1. VeraCrypt reads the salt and encrypted header area.
2. It combines the password and optional keyfiles.
3. The selected KDF derives header key material.
4. VeraCrypt attempts to decrypt and validate the header.
5. The header yields the master keys and volume parameters.
6. The master keys encrypt and decrypt volume sectors in XTS mode.

The salt is not secret. Its purpose is to make precomputed attacks against many volumes less useful.

Current VeraCrypt volume headers use a 512-bit salt. Non-system volumes also contain an embedded backup header near the end of the volume, encrypted with a separately derived header key and salt. (veracrypt.io)

Performance

VeraCrypt performance depends on:

• CPU architecture
• AES hardware acceleration
• Storage speed
• USB or Thunderbolt interface
• Filesystem
• Workload size
• Random vs sequential I/O
• KDF
• PIM
• Cipher or cascade
• Container fragmentation
• Operating-system driver behavior
• RAM availability
• Antivirus and endpoint-security software

Mount time vs normal I/O performance

These are different measurements.

The KDF mainly affects the delay while mounting or booting.

The selected encryption algorithm affects ongoing reads and writes.

A high Argon2id or PBKDF2 cost may add noticeable mount delay without proportionally slowing every file operation after the volume is unlocked.

AES acceleration

Modern x64 and ARM64 processors often provide hardware instructions that accelerate AES. VeraCrypt can use these instructions, which is one reason AES is usually the practical default.

You can inspect VeraCrypt’s benchmark dialog on the actual machine rather than trusting an unrelated online benchmark. (veracrypt.io)

Container performance

A container adds another filesystem layer:

• The filesystem inside the container
• The host filesystem containing the container file

A heavily fragmented container can perform worse because logically adjacent encrypted sectors may be scattered across the host disk.

Do not defragment SSDs merely to optimize a container. On hard drives, any host-level maintenance should be done while the container is unmounted and after making a backup.

Do not optimize away security

Avoid:

• Very low PIM values
• Dynamic containers without a clear need
• Unsafe password caching
• Mounting automatically everywhere
• Disabling security features solely to reduce a small delay
• Choosing a weak password because Argon2id feels slow

A volume that mounts quickly but depends on a predictable password is not well designed.

SSDs, TRIM, and Wear Leveling

VeraCrypt can encrypt data stored on an SSD. The difficult part is not whether encryption works. It is what the storage device reveals and retains outside VeraCrypt’s logical view.

TRIM

TRIM tells an SSD which logical sectors are no longer in use.

If TRIM reaches an encrypted device, an observer may be able to distinguish sectors that are unused from sectors containing ciphertext. This can reveal allocation patterns and undermine plausible deniability.

It does not reveal the plaintext contents of allocated encrypted sectors by itself.

Current VeraCrypt behavior differs by platform:

• On Windows, TRIM is blocked by default for non-system VeraCrypt partitions and drives, but users can enable it.
• On Windows system encryption, TRIM is enabled by default unless a hidden operating system is running, and users can configure VeraCrypt to block it.
• On Linux, TRIM is not blocked when VeraCrypt uses native kernel cryptographic services, which is the default.
• On macOS, VeraCrypt does not support passing TRIM through its volumes, so it remains blocked. (veracrypt.io)

Do not disable TRIM reflexively.

Blocking it can affect long-term SSD performance and device behavior. Allowing it may leak allocation information. The correct decision depends on whether your threat model is ordinary confidentiality or strict plausible deniability.

Wear leveling

SSDs and flash drives remap logical writes to different physical cells.

As a result:

• Overwriting a volume header may not physically erase the previous version.
• Changing a password may leave an older encrypted header somewhere in flash.
• A previously compromised password could remain useful if an attacker can recover the older header.
• In-place encryption cannot guarantee that every old plaintext sector was physically overwritten.
• Secure deletion through repeated logical overwrites is unreliable.

VeraCrypt’s documentation recommends avoiding wear-leveling devices when strict plausible deniability is required. (veracrypt.io)

Practical SSD guidance

For normal lost-device protection:

• Encrypt the device before placing sensitive data on it.
• Use strong credentials.
• Keep backups.
• Accept that allocation information may be visible depending on TRIM policy.
• Use native whole-system encryption where platform integration matters.

For strict plausible deniability:

• Do not rely on flash storage, snapshots, cloud versioning, or wear-leveling filesystems without understanding how they affect the claim.
• Follow the VeraCrypt hidden-volume precautions exactly.
• Assume that old physical versions and metadata may persist.

Pagefiles, Swap, Hibernation, RAM, and Temporary Files

Encrypting a container does not guarantee that all traces of the files remain inside it.

RAM

Applications need plaintext to use plaintext.

An editor opening an encrypted source file may hold:

• File contents
• Search terms
• Undo history
• Decrypted temporary buffers
• Password-related data

Unmounting the volume removes the filesystem view and causes VeraCrypt to erase the non-system volume’s master keys from its own active state. It cannot force every application to erase its memory. (veracrypt.io)

Windows pagefile

Windows may move memory pages to the pagefile.

If you mount a container on an otherwise unencrypted Windows system, plaintext from open files could be written into an unencrypted pagefile.

Encrypting the Windows system partition protects the pagefile at rest only when the pagefile is within the encrypted key scope. (veracrypt.io)

Windows hibernation

Hibernation saves system memory state to disk.

If the Windows system partition is not encrypted, hibernation may persist decrypted data from mounted volumes.

If you cannot use system encryption, disable hibernation during sessions involving sensitive mounted volumes. (veracrypt.io)

Linux swap

A VeraCrypt container does not encrypt Linux swap.

Use encrypted swap or full Linux system encryption if plaintext memory pages must not be written to an unencrypted disk.

Crash dumps

Operating-system and application crash dumps may contain:

• File fragments
• Password fields
• Paths
• Keys
• Application memory

Store dumps only on encrypted storage where feasible, restrict access, and configure dump behavior according to your threat model.

Temporary files and build artifacts

Developers should pay particular attention to:

• Compiler output
• Dependency caches
• Language-server indexes
• IDE history
• Editor swap files
• Test fixtures
• Core dumps
• Package-manager caches
• Git working trees outside the volume
• Docker build contexts
• CI artifacts
• Shell history

Opening one encrypted source tree does not automatically move the entire development toolchain inside the encrypted boundary.

Backups: Encryption Does Not Replace Them

Encryption protects confidentiality. It does not prevent:

• Disk failure
• Flash wear
• Accidental deletion
• Filesystem corruption
• Bad sectors
• Controller failure
• Ransomware
• Application bugs
• Human error
• Theft of the only copy
• Forgotten credentials

VeraCrypt’s documentation explicitly recommends regular backups because encrypted volumes can still be corrupted by hardware or software failure. (veracrypt.io)

What should be backed up?

Depending on the design:

• The files inside the volume
• The unmounted container file
• A separately created backup VeraCrypt volume
• External volume-header backups
• System images
• The VeraCrypt Rescue Disk
• Password-manager and recovery records
• Keyfiles
• Custom PIM documentation

A volume-header backup is not a data backup

A header backup may help when header key data is damaged.

It cannot restore:

• Deleted files
• A corrupted filesystem
• Failed NAND
• Overwritten ciphertext
• A lost container
• A forgotten password
• A missing keyfile

File-level backups

A strong workflow is:

1. Mount the primary volume.
2. Mount a separately created backup volume.
3. Copy or synchronize files from the primary filesystem to the backup filesystem.
4. Verify the backup.
5. Unmount both.
6. Keep one backup offline.

Creating the backup volume independently ensures that it has different master keys.

Do not clone a volume and use both copies independently

VeraCrypt warns against creating a new working volume by cloning an existing one and then allowing both to diverge. The copies share the same master keys, which can expose change relationships and undermine hidden-volume deniability. (veracrypt.io)

A temporary byte-for-byte backup of an unmounted container can still be operationally useful, but do not treat the copied image as a separately created long-term volume that will evolve independently.

Ransomware

If a VeraCrypt volume is mounted, ransomware running with access to it can encrypt or delete its files.

Keep at least one backup:

• Offline
• Unmounted
• Versioned
• Inaccessible to the normal workstation account
• Periodically tested

Verify recovery

A backup is not verified because the copy command succeeded.

Periodically:

1. Mount the backup.
2. Open representative files.
3. Verify hashes for important archives.
4. Confirm required keyfiles and PIM values are available.
5. Test on another supported computer.
6. Confirm the recovery procedure is understandable to whoever may need it.

Header Backups and Recovery

Non-system VeraCrypt volumes contain an embedded backup header.

You can also create an external header backup through VeraCrypt.

An external header backup should be protected because it contains encrypted master-key data. It does not contain the password in plaintext, but it remains part of the volume’s security and recovery material.

On Linux and macOS, the CLI includes:

veracrypt -t --backup-headers /path/to/volume.hc

To restore headers interactively:

veracrypt -t --restore-headers /path/to/volume.hc

Work on a copy whenever possible. Restoring a header modifies the volume.

Troubleshooting: Identify the Layer That Failed

VeraCrypt failures usually occur in one of three layers:

1. Authentication or header decryption
2. Volume mounting
3. The filesystem inside the successfully mounted volume

Do not treat all three as “the password is wrong.”

“Incorrect Password or Not a VeraCrypt Volume”

Check the simple causes first:

• Wrong password
• Caps Lock
• Keyboard-layout mismatch
• Wrong PIM
• Missing keyfile
• Changed keyfile
• Wrong keyfile search path
• Wrong KDF selection
• Wrong container or device
• Attempting to open a TrueCrypt volume with the wrong migration setup
• Selecting a partition instead of the whole device, or vice versa

If all credentials are correct, the volume header may be damaged.

For a non-system volume:

1. Stop modifying the original.
2. Make a backup copy or disk image.
3. Select the volume in VeraCrypt.
4. Choose Tools > Restore Volume Header.
5. Try the embedded backup header.
6. Enter the exact original credentials.

The embedded header still requires the correct password, PIM, and keyfiles. (veracrypt.io)

The Volume Mounts, but the Filesystem Is Invalid

If VeraCrypt accepts the credentials and creates a mounted device, authentication probably succeeded.

An operating-system message such as “This device does not contain a valid filesystem” points to a different layer:

• Filesystem corruption
• Unsupported filesystem
• Missing filesystem driver
• A volume that was never formatted
• Mounting with the wrong filesystem assumptions

Before running a repair tool:

1. Make a copy of the volume.
2. Work on the copy.
3. Mount read-only if possible.
4. Use the repair utility appropriate for that filesystem.

On Windows, VeraCrypt exposes a Repair Filesystem action that invokes the relevant Windows tooling. The official documentation warns that filesystem repair can make damage worse, so make a backup first. (veracrypt.io)

Windows Says the Encrypted Device Is RAW

A VeraCrypt-encrypted partition or device may appear RAW or unformatted while it is not mounted through VeraCrypt.

Do not format it.

Do not initialize it.

Do not create a new partition table.

Instead:

1. Cancel the Windows prompt.
2. Open VeraCrypt.
3. Choose Select Device.
4. Select the correct physical device or partition.
5. Mount it using the correct credentials.

Only investigate formatting after you have conclusively established that no recoverable VeraCrypt volume exists and that verified backups are available.

The Drive Does Not Appear in VeraCrypt

Check:

• Cable
• USB port
• External power supply
• Storage enclosure
• Operating-system device manager
• Disk Management or lsblk
• Whether another application has exclusively opened it
• Whether the OS auto-mounted an unencrypted partition
• Whether you selected Select File instead of Select Device

On Linux:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL

Do not run formatting or partition-creation commands merely to make the device appear.

If the physical device does not appear at the operating-system level, VeraCrypt cannot mount it. Solve the hardware or driver problem first.

A Container Was Moved and No Longer Mounts

Moving an unmounted container does not change its password or encryption.

Investigate:

• Incomplete copy
• Cloud sync conflict
• File truncation
• Sparse-file behavior
• Filesystem corruption on the host
• Antivirus quarantine
• Selecting an older copy
• Lost keyfile path
• Changed permissions
• A custom PIM omitted on the new machine
• An older VeraCrypt version lacking the required KDF

Compare source and destination sizes and hashes where possible.

On Linux:

sha256sum source.hc copied.hc

Identical hashes mean the files are byte-for-byte identical.

Linux or macOS Permission Errors

If the encrypted volume unlocks but you cannot access files:

• Check ownership inside the mounted filesystem.
• Check mount-point ownership.
• Check whether VeraCrypt was launched with different privileges.
• Check filesystem-specific mount options.
• Confirm the target OS supports the filesystem.
• Confirm the FUSE implementation is installed and approved on macOS.
• Avoid changing device permissions broadly as a first reaction.

The encryption credentials and filesystem permissions are separate access-control layers.

VeraCrypt Will Not Unmount

Usually, an application still has a file open.

On Linux:

lsof +D /path/to/mount-point

Or:

fuser -vm /path/to/mount-point

Close shells whose current directory is inside the volume, editors, terminals, file managers, indexers, compilers, and background synchronization tools.

Use force unmount only after accepting the risk of incomplete writes.

Windows System Encryption Will Not Boot

Use this order:

1. Stop repeated speculative changes.
2. Confirm you are booting the expected physical disk.
3. Check firmware boot order.
4. Boot the VeraCrypt Rescue Disk.
5. Try booting the VeraCrypt loader from rescue media.
6. Restore VeraCrypt loader files if needed.
7. Restore system header key data only through the documented option.
8. Use Mount Without Pre-Boot Authentication from a suitable environment when instructed.
9. Recover important files before aggressive repair.
10. Restore from a known-good backup if filesystem or Windows damage is extensive.

Do not assume a Rescue Disk resets the password. It repairs specific boot and header components while preserving the requirement for valid credentials.

What If I Forget the Password?

There is no VeraCrypt password-recovery service.

Your options are limited to:

• Recovering the password from a password manager
• Finding a documented recovery copy
• Reconstructing a partially remembered password
• Testing likely candidates
• Restoring a backup encrypted with known credentials

Replacing or restoring a volume header does not remove the password requirement.

Any tool claiming instant universal VeraCrypt recovery is either relying on a weak password, exploiting compromised endpoint data, or making a dishonest claim.

Common VeraCrypt Mistakes

Using encryption instead of backup

An encrypted drive can fail as completely as an unencrypted one.

Keeping the only keyfile on the encrypted device

The device’s failure then destroys both the ciphertext and a required credential.

Setting a custom PIM and failing to record it

The password no longer works by itself.

Choosing a cipher cascade to compensate for a weak password

It does not.

Using an old tutorial

Current terminology, supported platforms, TrueCrypt migration, KDF choices, and bootloader behavior have changed.

Blindly accepting an operating-system format prompt

This can overwrite an encrypted partition or device.

Copying a mounted container

The resulting copy may contain an inconsistent filesystem state.

Synchronizing one writable container from multiple computers

Ordinary filesystems are not designed for concurrent block-level modification through independent hosts.

Treating portable mode as universal compatibility

The target computer still needs a supported OS, suitable privileges, VeraCrypt driver behavior, and support for the filesystem inside the volume.

Forgetting plaintext artifacts

Editors, compilers, browsers, preview tools, indexers, pagefiles, swap, and crash dumps can write outside the encrypted volume.

Leaving a volume mounted all day

A volume that is always unlocked provides little protection against runtime compromise.

Storing recovery material only inside the encrypted volume

Recovery information must remain available when the primary volume is not.

Assuming a changed password erased the old password from an SSD

Wear leveling may leave an older header physically recoverable.

Using hidden volumes without reading the precautions

Plausible deniability is mostly an operational-security problem after the cryptographic structure is created.

Practical VeraCrypt Best Practices

• Use VeraCrypt 1.26.29 or a later stable release.
• Verify installer signatures.
• Use AES by default.
• Use Argon2id for new non-system volumes when compatibility allows.
• Use a long, unique password.
• Leave PIM at the default unless you have a measured reason to change it.
• Use generated keyfiles rather than editable documents.
• Keep multiple verified keyfile backups.
• Create fixed-size containers rather than dynamic containers.
• Unmount before copying, syncing, or removing storage.
• Mount read-only when examining questionable media.
• Keep offline, versioned backups.
• Back up data, not only headers.
• Test the password, PIM, keyfiles, and recovery process before adding irreplaceable data.
• Use FileVault for Mac system-disk encryption.
• Use LUKS for Linux system-disk encryption.
• Create and boot-test the VeraCrypt Rescue Disk before completing Windows system encryption.
• Keep sensitive pagefiles, swap, hibernation files, and temporary files inside an encrypted system boundary where possible.
• Do not rely on encryption to protect a compromised running system.
• Avoid flash storage when strict plausible deniability is required.
• Never format a suspicious RAW device before ruling out a recoverable encrypted volume.

Real-World Use Cases

Protecting developer credentials and configuration

A small container can hold:

• SSH private keys
• Infrastructure recovery files
• Offline API credentials
• Signing keys
• Sensitive .env archives
• Certificate bundles

Do not mount it automatically unless the workflow truly requires that. Restrict host permissions as well as encrypting the volume.

Archiving a completed client project

Create a fixed-size container, copy the final source tree and documentation into it, verify the contents, unmount it, and create multiple offline backups.

Store credential and retention information separately.

Carrying sensitive data on a USB drive

Encrypt the entire USB drive when no plaintext compatibility area is needed. Use exFAT if Windows, Linux, and macOS must all access the mounted filesystem.

Unmount and safely eject every time.

Encrypting an external backup disk

Encrypt the entire device or a dedicated partition, then use a backup application against the mounted filesystem.

Keep the disk disconnected when not backing up so ransomware cannot modify it.

Separating personal data on a shared workstation

A container can stop other casual users from browsing the files while it is unmounted.

It cannot protect the data from a malicious administrator or compromised host.

Protecting a Windows laptop at rest

VeraCrypt system encryption can protect the Windows system partition with pre-boot authentication on supported x64 configurations.

For users who prioritize native recovery, TPM integration, enterprise management, and automatic device encryption, BitLocker may be the better Windows system-disk choice.

VeraCrypt vs BitLocker

BitLocker is Microsoft’s native Windows volume-encryption system.

BitLocker offers:

• Windows integration
• TPM and Secure Boot integration
• Recovery passwords and recovery keys
• Enterprise escrow through Microsoft Entra ID or Active Directory
• Management through Group Policy and device-management platforms
• BitLocker To Go for removable storage

VeraCrypt offers:

• Open-source implementation
• Cross-platform non-system volumes
• File containers
• Independent password-based volume management
• Hidden volumes
• Multiple ciphers and KDF choices
• A system-encryption model not centered on normal TPM unlocking

BitLocker is generally the easier choice for managed Windows fleets and users who want native hardware-backed recovery integration. VeraCrypt is attractive when cross-platform containers, independent key management, pre-boot password entry, or hidden volumes are explicit requirements.

BitLocker recovery can use a 48-digit recovery password or recovery-key file, depending on configuration. VeraCrypt has no equivalent universal recovery credential for a forgotten volume password. (learn.microsoft.com)

VeraCrypt vs FileVault

Use FileVault for the internal startup disk of a Mac.

Use VeraCrypt for:

• Cross-platform containers
• Removable media shared with Windows or Linux
• Data that needs credentials independent from the Mac account
• Portable encrypted archives

FileVault integrates with Apple silicon, the T2 chip, the Secure Enclave, macOS accounts, recovery keys, and Apple’s boot process. VeraCrypt does not provide that startup-disk integration on macOS. (support.apple.com)

VeraCrypt vs LUKS

Use LUKS for Linux system disks and Linux-native encrypted block devices.

Use VeraCrypt when:

• Windows and Linux must share the encrypted volume.
• You need a file-hosted encrypted container.
• Existing workflows already use the VeraCrypt format.
• A removable device must work across several desktop operating systems.

LUKS offers native Linux boot integration, multiple key-slot workflows, device-mapper support, and distribution tooling. VeraCrypt provides easier cross-platform volume portability.

FAQ

Can VeraCrypt encrypt a USB drive?

Yes. VeraCrypt can encrypt a USB partition, the entire USB device, or a container stored on the USB filesystem.

Can VeraCrypt encrypt an entire hard drive?

Yes, for non-system devices. It can also encrypt supported Windows system configurations, although on UEFI systems the EFI System Partition remains unencrypted and additional data partitions may require separate encryption.

Can VeraCrypt encrypt an SSD?

Yes. VeraCrypt encrypts logical reads and writes to an SSD, but TRIM and wear leveling can reveal allocation information or preserve older physical versions. These issues are especially important for plausible deniability and in-place encryption.

Does VeraCrypt slow down an SSD?

It adds cryptographic processing and filesystem overhead. The actual effect depends on CPU acceleration, cipher, workload, storage interface, filesystem, and KDF. KDF settings mainly affect mount time, while the encryption algorithm affects ongoing I/O.

What happens if I forget my VeraCrypt password?

The volume cannot be unlocked unless you recover or correctly guess the password and any required PIM or keyfiles. VeraCrypt does not provide password reset or vendor recovery.

What is PIM in VeraCrypt?

PIM is a parameter that changes the work performed by the selected KDF. With Argon2id it controls memory and time cost. With PBKDF2 it affects iteration count. A custom PIM must be entered correctly whenever the volume is mounted.

Should I use a keyfile?

Use one only if you need an additional credential and can maintain multiple exact backups. A lost or modified keyfile can permanently lock you out.

Which encryption algorithm should I use?

Use AES unless a documented policy or threat model requires another choice. Serpent, Twofish, and cascades are available, but complexity is not automatically stronger security.

Should I use Argon2id or PBKDF2?

Use Argon2id for new non-system volumes when all target installations support VeraCrypt 1.26.29 or later. Use PBKDF2 for system encryption, older-version compatibility, or constrained environments.

Can VeraCrypt encrypt the Mac startup disk?

No. Use FileVault for the macOS startup disk.

Can VeraCrypt encrypt a Linux root filesystem?

VeraCrypt does not provide the normal Linux system-encryption workflow. Use LUKS through your distribution’s installer or system-administration tools.

Does VeraCrypt protect files after I unlock the computer?

Only against access paths that still encounter encrypted storage. While a volume is mounted, authorized applications and sufficiently privileged malware can read its plaintext.

Can I recover a corrupted VeraCrypt container?

Sometimes. An embedded backup header may repair header damage, and filesystem tools may repair a damaged filesystem after the volume mounts. Neither method guarantees recovery. Work on a copy and prefer restoring from a verified backup.

Does VeraCrypt protect file integrity?

Not by itself. VeraCrypt’s normal XTS disk-encryption format provides confidentiality but does not authenticate every encrypted block. Use trusted backups, signatures, hashes, and authenticated application formats where integrity matters.

Can I email a VeraCrypt container?

Technically yes, if the mail system accepts its size. Exchange the password through a separate secure channel, and remember that email metadata and attachment size remain visible.

Can two people mount the same writable container?

Not safely through independent computers. Concurrent writes can corrupt the filesystem. Use a proper shared storage or file-level collaboration system instead.

Is VeraCrypt better than BitLocker?

Not universally. VeraCrypt is better suited to cross-platform containers, independent credentials, and hidden volumes. BitLocker is usually better integrated with Windows hardware, recovery, and enterprise management.

Is VeraCrypt better than FileVault?

Not for a Mac startup disk. FileVault is the correct native system-encryption choice on macOS. VeraCrypt is useful for portable containers and removable storage.

Is VeraCrypt better than LUKS?

Not for a typical Linux root disk. LUKS is natively integrated with Linux. VeraCrypt is useful when cross-platform compatibility matters.

Final Recommendations

For most people, the sensible VeraCrypt setup is deliberately boring:

• Current VeraCrypt release
• Standard volume
• Fixed-size container or dedicated external device
• AES
• Argon2id for new non-system volumes
• Default PIM
• Long, unique password
• No keyfile unless there is a real credential-separation requirement
• A filesystem selected for the target operating systems
• Multiple verified backups
• Manual mounting only when the data is needed
• Read-only mounting during recovery work
• Prompt unmounting afterward

For Windows system encryption, add:

• Supported Windows x64 configuration
• Complete backup
• Disabled Fast Startup
• Successful pre-test
• Tested VeraCrypt Rescue Disk
• Documented password and PIM recovery
• A clear plan for firmware, bootloader, and Windows recovery failures

For Mac and Linux system disks, use the native system-encryption stack and reserve VeraCrypt for the cases where it is strongest: portable encrypted volumes, independently managed containers, removable devices, and carefully defined cross-platform workflows.

The cryptography is only one part of the system. Password management, backups, mounting discipline, endpoint security, storage behavior, and recovery testing determine whether the encrypted data remains both confidential and usable.

Sources

• VeraCrypt official downloads
• VeraCrypt release notes
• VeraCrypt documentation
• VeraCrypt introduction
• VeraCrypt beginner’s tutorial
• Supported operating systems
• Supported systems for system encryption
• System encryption
• VeraCrypt Rescue Disk
• Creating new volumes
• Encryption algorithms
• Key derivation algorithms
• Argon2id
• Header key derivation
• PIM
• Keyfiles
• Hidden volumes
• Hidden-volume protection
• Hidden-volume security requirements
• Plausible deniability
• VeraCrypt volume format
• Security model
• Security requirements and precautions
• Authenticity and integrity
• Unencrypted data in RAM
• Paging files
• Hibernation files
• TRIM
• Wear leveling
• Secure backup guidance
• Volume clones
• Troubleshooting
• Known issues and limitations
• Linux and macOS command-line usage
• Windows command-line usage
• Digital-signature verification
• TrueCrypt conversion guide
• Quarkslab VeraCrypt security assessment
• Fraunhofer SIT and BSI VeraCrypt security evaluation
• Microsoft BitLocker FAQ
• Microsoft BitLocker recovery overview
• Apple FileVault overview
• Apple FileVault recovery options
• Ubuntu full-disk encryption documentation
• Author's Website