Hardware Encryption, NAS and Self-Hosted Storage: Owning Your Own Files

Before we start: the scope of this guide

If you're still building your mental model of why local storage security matters, the plain-English secure storage guide is the right starting point. This piece picks up where that one leaves off. It assumes you're comfortable with concepts like symmetric encryption, filesystem permissions and basic network topology, and it goes into the implementation detail that practitioners actually need.

The threat model for files at rest

Encryption is only useful relative to a threat. Getting this wrong leads to either over-engineering or, more commonly, protecting against the wrong thing entirely.

Four threats dominate for self-hosted storage. First: physical loss or theft of a device. A drive removed from a powered-down machine, or a laptop left on a train, is the scenario hardware and software encryption was literally designed for. Second: seizure, whether by law enforcement under a warrant or by a border agent exercising schedule 7 powers under the Terrorism Act 2000. The legal exposure here is nuanced; the NCSC's device security guidance touches on it, though the legal specifics are properly a question for a solicitor rather than a technical guide. Third: remote compromise, where an attacker gains access to a running system. Encryption at rest provides almost no protection here because the keys are already in memory. Fourth: ransomware, which is a hybrid threat: remote access leading to local destruction or encryption of your own files.

These threats demand different mitigations. Full-volume encryption addresses theft and seizure of a powered-down device. Snapshot and versioning strategies address ransomware. Network segmentation and access controls address remote compromise. No single mechanism covers all four, and pretending otherwise is how people end up with a beautifully encrypted NAS that a ransomware payload can still write to because the share was mounted.

Practical takeaway: Write down your actual threat model before configuring anything. A drive that leaves your home needs different treatment from a NAS that never does.

Hardware encryption on drives: what the labels mean, and where they've failed

Most modern SSDs and many external drives advertise hardware-based AES encryption, usually AES-128 or AES-256. The marketing term you'll see most often is "Self-Encrypting Drive" or SED. The Trusted Computing Group's Opal 2.0 specification is the relevant standard for enterprise-class SEDs, defining how a drive's locking mechanisms, authentication and key management should behave.

In principle, hardware encryption is attractive. The encryption and decryption happen in the drive's controller, so there's no CPU overhead, no software to patch and no key material sitting in host memory. In practice, the history here is uncomfortable reading.

In 2018, researchers Carlo Meijer and Bernard van Gastel at Radboud University published findings on a range of consumer and enterprise SSDs, including drives from Samsung and Crucial. They found that several drives accepted any password, or ignored the user password entirely and used a fixed key, or had other implementation flaws that meant the hardware encryption provided no meaningful protection. Microsoft responded by updating its guidance: BitLocker, which had been configured by default to defer to hardware encryption on SEDs, was updated so that administrators could force software encryption instead. The researchers' paper is in the public record and the CVEs are documented.

The Opal standard itself isn't the problem. The problem is that drive firmware implementing Opal is proprietary, rarely audited publicly, and varies enormously between manufacturers and even between firmware versions of the same model. There's no reliable way for a user to verify that a drive's hardware encryption is correctly implemented without specialist equipment and access to the firmware.

What the certification labels actually tell you is limited. "256-bit AES" on a drive's packaging tells you the key length of the cipher used, nothing about how the key is derived, stored or protected. FIPS 140-2 or FIPS 140-3 validation is more meaningful for enterprise procurement, but even that validates a specific firmware version tested at a specific point in time.

The practical consequence: for most self-hosting scenarios, treating hardware encryption as a useful performance-free baseline while adding a software layer on top is the defensible approach. Don't rely on hardware encryption alone.

Practical takeaway: Check whether your OS is deferring to hardware encryption by default. On Windows, manage-bde -status will tell you whether BitLocker is using hardware or software encryption. If you're concerned about SED reliability, disable hardware encryption in the drive's management tool (where possible) and use a software layer instead.

Software encryption layers: BitLocker, FileVault, VeraCrypt and LUKS

Software encryption runs in the operating system or a dedicated application layer. It's slower than hardware encryption in principle, though on modern hardware with AES-NI instruction set support the performance difference is rarely noticeable for typical workloads.

BitLocker

BitLocker is Microsoft's full-volume encryption, built into Windows Pro, Enterprise and Education editions. It uses AES-XTS (128 or 256-bit) for fixed drives, AES-CBC for removable media. The volume master key is typically protected by the TPM, optionally combined with a PIN or startup key. TPM-only mode, which is the default in many deployments, protects against offline attacks but not against someone who steals a logged-in machine or who can extract the key from a running system.

BitLocker's recovery key, a 48-digit numerical key, is the critical asset. By default, Windows often prompts you to back it up to a Microsoft account. For a self-hosting privacy setup, that's worth reconsidering: a recovery key stored with Microsoft is accessible to Microsoft and, under a valid legal process, to authorities who approach Microsoft. Storing it locally, on paper, or in an offline password manager is more consistent with the threat model most self-hosters have.

BitLocker hasn't been publicly audited in the way that open-source tools have. Its security rests substantially on trust in Microsoft's implementation. That's a reasonable position for many organisations, but it's worth being clear-eyed about it.

FileVault

Apple's FileVault 2 uses XTS-AES-128 for full-volume encryption on macOS. On Apple Silicon Macs, the encryption is tightly integrated with the Secure Enclave, which handles key derivation and protection in dedicated hardware. The threat model coverage is good for the physical theft scenario. Like BitLocker, FileVault can escrow recovery keys to iCloud, with the same caveats about third-party custody applying.

VeraCrypt

VeraCrypt is the successor to TrueCrypt, maintained as an open-source project. It supports full-disk encryption, encrypted containers (files that mount as volumes) and, on Windows, system partition encryption. It's been independently audited: a 2016 audit commissioned by the Open Source Technology Improvement Fund found issues, most of which were subsequently addressed. A further audit in 2020 covered the bootloader. The audit reports are publicly available.

VeraCrypt's key strength for self-hosters is its cross-platform nature and its support for hidden volumes, which provide plausible deniability under coercive circumstances. Its key derivation is deliberately slow (using algorithms like PBKDF2, bcrypt or Argon2 with high iteration counts), which is a feature against brute-force attacks but means container mounting takes a few seconds.

One practical limitation: VeraCrypt encrypted containers don't play well with cloud sync tools. Because any write to the underlying file changes a large block of the container, sync clients tend to re-upload the entire container rather than just the changed portion. For large containers, this makes cloud backup impractical without a workaround.

LUKS

Linux Unified Key Setup is the standard for disk encryption on Linux. It's the default on most Linux distributions when you select full-disk encryption at install time. LUKS2, the current version, uses Argon2id for key derivation by default, which is memory-hard and resistant to GPU-accelerated brute force. It supports multiple key slots, meaning you can have several passphrases or keyfiles that all unlock the same volume master key, which is useful for recovery scenarios.

LUKS is the natural choice for a Linux-based NAS or home server. It's well-documented, widely deployed, and the implementation is in the public kernel and cryptsetup codebase. It doesn't provide hidden volume functionality, and like all full-volume encryption it offers no protection against a running, mounted system being compromised remotely.

Practical takeaway: If you're on Linux, LUKS2 with Argon2id is the well-supported default. On Windows, BitLocker is fine for most threat models if you control where the recovery key lives. VeraCrypt is worth the additional complexity if you need cross-platform containers or plausible deniability.

NAS encryption models: folders versus volumes, and the reboot key problem

Network-attached storage introduces complications that don't exist on a single-user machine. The device is always on, often accessed by multiple users or services, and typically reboots unattended after a power cut. Each of these properties creates tension with encryption.

Folder-level versus volume-level encryption

Most consumer and prosumer NAS operating systems (Synology DSM, QNAP QTS, TrueNAS and others) offer encryption at one or both of two granularities.

Volume-level encryption encrypts the entire storage pool or volume. It's closer to full-disk encryption and provides the strongest protection for the physical theft scenario. The entire dataset is opaque without the key.

Folder-level or shared-folder encryption encrypts specific shared folders independently. This is more flexible: you can have some shares encrypted and others not, different keys for different shares, and you can mount and unmount individual shares without rebooting. The tradeoff is that filesystem metadata, directory structure and unencrypted shares remain visible even if the encrypted shares are locked.

Synology's implementation, to take a documented example, uses AES-256-CBC for encrypted shared folders and stores the key in an encrypted key file on the NAS itself. The key file is protected by a passphrase or, optionally, a hardware security key. QNAP's implementation is broadly similar. TrueNAS (both Core and Scale) uses GELI on FreeBSD or ZFS native encryption on Linux, with key management handled through the web interface or CLI.

The reboot key problem

This is the issue that most NAS documentation underplays. If your NAS reboots after a power cut and the encrypted volumes require a passphrase to mount, they won't mount automatically. Your services, your backups, your media server, all of it stays offline until someone manually enters the passphrase. For a home user who's away for a week, that's a real operational problem.

The common workarounds each have security costs. Storing the key on the NAS itself (auto-mount on boot) means the key is accessible to anyone who has physical access to the device, which defeats most of the point of encryption against theft. Some NAS platforms support a network-based key server: the NAS contacts a trusted server on boot, retrieves the key over a mutually authenticated TLS connection, and mounts the volume. This is architecturally sounder but requires a separate always-on service, which is its own complexity and failure point. TPM-based key sealing, where the key is bound to the platform state, is available on some enterprise NAS hardware but rarely on consumer devices.

The honest answer is that for a home NAS, you're usually choosing between operational convenience and strict encryption-at-rest guarantees. If the device lives in a physically secure location and your threat model is primarily remote attack rather than physical theft, auto-mount on boot with a strong volume password (stored in a password manager, not in plaintext on the device) is a defensible compromise. If physical theft is a real concern, manual key entry on reboot is the more honest approach, and you should have a plan for what happens when you're not available.

Practical takeaway: Decide before you configure: is your NAS in a physically secure location? If yes, auto-mount with a strong, unique passphrase is reasonable. If no, plan for manual key entry and test your reboot recovery procedure before you rely on it.

Private sharing from your own hardware: encrypted sync done right

One of the main reasons people self-host is to share files with others without routing them through a third-party cloud. Done carelessly, this can expose more than a commercial service would.

The basic options for encrypted sync from a NAS or home server fall into a few categories. Protocol-level encryption (SFTP, FTPS, HTTPS for WebDAV) protects data in transit but leaves it unencrypted at rest on both ends unless you add a separate layer. End-to-end encrypted sync tools encrypt before transmission and store only ciphertext on the server, meaning the server operator (you) can't read the files without the client key.

Syncthing is worth understanding here because its architecture is documented and its code is open source. It uses TLS for transport and device authentication via certificate fingerprints. The data at rest on each synced device is unencrypted by default, meaning Syncthing is a sync tool, not an encryption tool. Syncthing does support "encrypted folders" (introduced in a later version) where one node stores only ciphertext and cannot decrypt it, which is useful for an untrusted relay or backup node. The documentation is clear about what this does and doesn't protect.

For sharing with people outside your network, a reverse proxy with a valid TLS certificate (via Let's Encrypt, for example) in front of your NAS web interface gives you HTTPS without exposing the NAS management interface directly. Combining this with a VPN for remote access, rather than exposing services directly to the internet, reduces your attack surface considerably. The NCSC's VPN guidance covers the considerations for choosing and configuring a VPN endpoint.

One thing to be clear about: if you share a link to a file on your self-hosted instance, you're responsible for that link's security. Time-limited links, password protection and access logging are features worth enabling if your NAS software supports them. Nextcloud, for instance, supports all three and its security architecture is documented in its published changelogs and security advisories.

Practical takeaway: Never expose NAS management interfaces directly to the internet. Use a VPN for your own remote access, and HTTPS with a valid certificate for any sharing links. Check your NAS's security advisory history before relying on its sharing features.

Snapshots and versioning as ransomware defence

Ransomware targeting NAS devices is documented and ongoing. QNAP devices in particular have been targeted by multiple ransomware campaigns (Qlocker, DeadBolt and others), with the incidents publicly reported and CVEs assigned. Synology devices have also been targeted. The attack pattern is typically exploitation of a vulnerability in the NAS web interface, followed by encryption of all accessible shares.

Encryption at rest doesn't help here. The ransomware runs on the NAS itself, with access to the mounted, decrypted filesystem. What does help is immutable or append-only snapshots.

ZFS, which underlies TrueNAS and is available on other Linux-based systems, has native snapshot support. A ZFS snapshot is a read-only point-in-time copy of a dataset. Crucially, a snapshot cannot be deleted or modified by a process that doesn't have administrative access to the ZFS pool itself. If your NAS user account is compromised but the attacker doesn't have root or pool-admin access, they can encrypt or delete the live filesystem but the snapshots remain intact.

Btrfs, used in Synology's newer DSM versions and available on Linux generally, has similar snapshot semantics. Synology's Snapshot Replication package automates this and supports snapshot replication to a second device, which is important: snapshots on the same device as the data they protect are not a backup.

The key configuration decisions are frequency and retention. Hourly snapshots retained for a week, daily snapshots retained for a month, and weekly snapshots retained for a quarter is a common pattern that gives you granular recovery for recent events and longer-term recovery for slower-moving problems. The storage overhead depends on your rate of change; ZFS and Btrfs both use copy-on-write, so snapshots only consume space for blocks that have changed since the snapshot was taken.

One important caveat: snapshots are not a substitute for off-device backups. A hardware failure, a fire, or a sufficiently privileged attacker can destroy both the live data and its snapshots. The 3-2-1 rule (three copies, two different media, one off-site) remains the relevant framework, and snapshots fill the "multiple copies on primary storage" part of it, not the off-site part.

Practical takeaway: Enable automatic snapshots on your NAS today, if you haven't already. Set retention to at least 30 daily snapshots. Then verify that your snapshot schedule is actually running by checking the snapshot list, not just the configuration.

When the cloud honestly wins: zero-knowledge providers and trade-offs

Self-hosting is not always the right answer. Saying so plainly feels important, because a lot of privacy-focused writing treats self-hosting as an unambiguous virtue. It isn't. It's a set of trade-offs, and for some threat models a well-implemented zero-knowledge cloud provider is genuinely the more secure choice.

Zero-knowledge in this context means the provider encrypts your data client-side before it leaves your device, stores only ciphertext, and does not hold the keys needed to decrypt it. The provider cannot read your files, and a legal request to the provider produces only ciphertext. This parallels the guarantees that end-to-end encryption provides for communications, applied to stored files.

The practical advantages over self-hosting are real. A zero-knowledge cloud provider offers redundancy across multiple data centres, professional security operations, automatic software updates, and no reboot key problem. You don't have to manage hardware, configure firewalls, or respond to 3am alerts about a failed drive.

The limitations are also real. You're trusting the provider's implementation of their client-side encryption, which may or may not have been independently audited. You're trusting that the client software isn't backdoored. You're subject to the provider's terms of service and their continued existence as a business. And if you lose your key, you lose your data, with no provider support available to recover it.

Tresorit, Proton Drive and Filen are examples of providers that publish documentation of their encryption architecture and, in some cases, have commissioned audits. Evaluating their claims means reading the technical documentation, not the marketing copy. The question to ask is: at what point does the provider hold a key that could decrypt my data? If the answer is "never, including during account recovery," that's meaningful. If account recovery is possible without your passphrase, the provider holds a key somewhere.

For UK users, data residency is a separate consideration from encryption. UK GDPR requires that personal data transferred outside the UK has adequate protections in place. The ICO's guidance on international transfers is the relevant reference. If you're self-hosting for compliance reasons as well as privacy reasons, the data residency question is yours to answer precisely; a cloud provider's data centre location matters, and not all providers make this configurable.

The honest comparison looks like this:

The right answer depends on your threat model, your operational capacity and your tolerance for complexity. Neither option is categorically superior. What matters is that you've made the choice deliberately, with accurate information about what each option actually protects.

Practical takeaway: If you're evaluating a zero-knowledge cloud provider, find their technical architecture documentation and look for an independent audit. If neither exists, treat their zero-knowledge claims as unverified. If you're self-hosting, be honest with yourself about whether you're keeping the software up to date and monitoring for vulnerabilities, because a self-hosted system you're not maintaining is often less secure than a managed alternative.