Recovery methodsTechnicalUpdated October 15, 2026 · Data Recovery Cases Editorial Team

Self-Encrypting Drives and Controller Encryption in RAID and NAS

A correct RAID geometry does not replace an unlock dependency. Media encryption inside a drive, read locking configured on its ranges, and encryption managed by a RAID controller or NAS are different things, and a shutdown, a replacement controller or appliance, or moving the members can take away the unlocked state of a layer, or the availability of what it depends on, each in a different way — without removing the encryption on the drives itself. Establish first what the system actually returns and what that access depends on; whether to copy, keep it running or shut it down is then decided with source health and data consistency in view — there is no universal rule to keep every system powered on.

In short

Before a shutdown, migration or drive removal, record what currently provides access: drive, controller, appliance or key server.
Encryption capability, configured security and current lock state are separate facts; access to some ranges does not mean the whole drive is unlocked.
Credentials, key identifiers and media keys are different things; a saved configuration does not always contain enough to unlock.
A working decrypted view can allow a prioritized export if health and consistency permit; it does not replace member images or metadata.
Reset, revert, crypto erase and rekey are not diagnostic steps; depending on product and state, some destroy keys and data.

Where the encryption lives, and what a read returns

“The drives are encrypted” can describe at least four different arrangements, and each depends on something different:

In-drive media encryption. A drive implementing the TCG Opal or Enterprise storage specifications encrypts user data inside the drive with a media encryption key, whether or not anyone has set a credential; the Opal SSC v2.30 requires full disk encryption of all host-accessible user data (§2.4). Not every TCG storage profile means the same thing: the TCG and NVMe joint white paper notes that Pyrite does not specify cryptographic protection of data at rest, so a Pyrite device offers access control without media encryption.
Drive authentication and read-locked ranges. Once a credential is set and locking is configured, a range can refuse reads until authorization succeeds. Opal allows several locking ranges, each encrypted with its own media encryption key and unlockable independently of the others (white paper, Opal SSC section).
Controller-managed credentials or controller encryption. A RAID controller may hold, or fetch at start-up, the credentials that unlock its member SEDs, or apply encryption of its own; the member then depends on the controller’s key-management configuration.
Appliance or software encryption of a volume, storage pool or shared folder, applied above the RAID layer by a NAS or a host operating system.

For each layer, keep three facts apart: capability (the device can encrypt or lock), configured security (a credential or key mode is actually set up) and current access state (locked or unlocked right now). Opal discovery reports media encryption and “locking enabled” separately, and locking is reported as enabled only once the locking function is in a state other than Nonexistent or Manufactured-Inactive (Opal SSC v2.30 §3.1.1.3). An SED label, a controller feature list or a NAS menu entry establishes capability, not configuration or state.

Relative to a given encryption layer, an ordinary read of a member or volume does one of three things:

Scroll horizontally to see the full table →

What an ordinary read can return relative to one encryption layer. The same member can be in a different state for another layer.
The read returns	Typical reason	What it does not show
Plaintext relative to that layer	The layer is unlocked, or was never secured	That the content is readable: a host-encrypted volume, container or encrypted application file above it can still be ciphertext
Ciphertext that can be copied	The encryption was applied by a device that is no longer in the read path, such as a controller or appliance	Anything usable without that device’s keys and configuration
Refusal for some ranges	A locked range of a self-encrypting drive denies reads until authorization succeeds	That the rest of the drive is locked, or that readable ranges mean the whole drive is unlocked

Which of these applies is established from configuration, documentation and metadata, not from how the bytes look; random-looking data, zeros or a RAW volume have other explanations too, as Remote NAS Recovery vs. Member-Level Reconstruction explains. The key roles behind these layers are covered in Encryption Key Hierarchies and Recovery Metadata; this page is about recording and keeping the dependencies.

A dependency record: what holds access

The purpose of the record is to make the unlock path reproducible by the people entitled to use it, without the record becoming a secret itself. It covers encryption dependencies only; the wider physical record of members, bays and connections belongs to Documenting a Multi-Disk System Before Drives Are Removed.

Scroll horizontally to see the full table →

Entries of an encryption dependency record. Record identifiers and owners, never PINs, passphrases or key material.
Entry	What to record	Why it matters
Drive identities and ranges	Serial and model of each member; which ranges exist and which are readable, locked or unknown	State can differ per range; partial access is not an unlocked drive
Security state	Capability, whether security is configured, current lock state, and how each was established	Capability alone says nothing about configuration
Controller or appliance identity	Model, firmware or OS version, slot or chassis, configuration identifier	Import and migration behaviour is product- and version-specific
Key-management mode	Local on the controller or appliance, external key server, automatic unlock at start-up, or manual entry	Decides what is lost when that device or its network is unavailable
Key or server identifier	Key ID, key server name, management-controller dependency, administrator — not the secret	Lets the owner confirm the right key without exposing it
Configuration and key backups	Whether they exist, where, of what date, and what the product documents them as containing	A saved configuration does not always contain the secret, and key export is not always supported
Authorized credential owner	Who holds each passphrase or administers each key server, and how to reach them	Credentials, and the right to use them, are confirmed by their owner, not inferred
Accessible representation	What is readable now — share, volume or member — and whether it is plaintext at that layer	A readable member does not confirm a readable volume
Effect of power-off	Which layers could return to a locked state on power loss or a covered reset event, which need manual entry, which need a key server	The basis for any decision to shut down or move hardware
Known and unknown	What has been confirmed, and what is assumed or still open	Keeps assumptions from turning into facts in later steps

Three things stay separate in the record: a credential (what a person or system supplies to unlock), a key identifier (which key or key server is meant) and the media or data key itself, which normally never leaves the drive or controller. Dell’s PERC tech note states this for its own design: the drive’s data encryption key is never revealed outside the drive, and the key-encryption key never outside the controller (PERC SED Support and FAQs). Passphrases, PINs, recovery keys and key material do not go into the record, a ticket or an email thread; they travel through a separate protected channel, and whether they are valid — and whether the holder may use them — is confirmed by the person responsible for them.

A readable member does not confirm a readable volume. The member may be unlocked while the controller or volume layer above it is not, or the volume may need other members that are still locked.

What a power or hardware change can take away

A power cycle or a reset event covered by the device’s locking policy can return configured ranges to a locked state. A host restart does not necessarily remove drive power, and the resulting access state depends on the device, controller and configuration. Do not test this by restarting a system that holds the only accessible copy. As an example of power-loss behaviour, the TCG and NVMe white paper describes the plaintext media key as lost when the device loses power, after which the drive is locked until it is unlocked again (“Self-Encrypting Drive Basics”); that simplified description is not a specification of every warm reset. Which reset events relock a range is itself configuration: the TCG FAQ on Opal SSC 2.02 changes lists new optional LockOnReset values, including hardware reset as an option (Table 1, §4.3.5.2.2). Whether the original system unlocks it again by itself depends on its key management. The situations below differ in what can still be learned without adding risk.

Scroll horizontally to see the full table →

Considerations for common starting points. They are not a sequence of steps, and product behaviour has to be checked for the exact model and firmware.
Starting point	Can be established without extra risk	What may be lost	What stays uncertain
Original system running, volumes unlocked	Key-management mode and identifiers from the existing interface, exported settings and documentation; the current readable representation; health already reported	The unlocked state, on shutdown or on a reset event covered by the locking policy, which a restart may or may not be; continued operation also keeps writing	Whether unlock after a restart would work, unless the dependency is documented and confirmed
Source already powered off	Labels, documentation, configuration backups, administrator and key-server records — without powering anything on	Nothing further by staying off; powering on to check can start a rebuild or resync and loads weak disks	Each drive’s security state, and whether automatic unlock was configured
Replacement controller or appliance	What the replacement documents for importing secured members, and what it requires, such as the original passphrase or a minimum firmware or OS version	Import can change security metadata; Dell’s PERC note says a member imported with a different passphrase is re-keyed with the local key	Whether the replacement handles that generation’s configuration at all
External key server unreachable	Which server, who administers it, what it depends on, and whether it can be restored	Access, for as long as the server stays unreachable	Whether the key still exists on the server
Members already removed	Original positions if known; what each member returns now, within its health limits	The original system’s unlocked view and any unlock tied to that chassis	Whether the controller or appliance that held the keys can be brought back

Restarting the system “to test”, reconnecting members to see what happens, or trying the original controller online are not read-only diagnosis: each can lock a layer, start a rebuild or resync, or change key state. Local and external key management are two examples of dependencies, not a list of every arrangement, and release or import steps documented for one controller generation are not evidence for another. This page does not describe migrating between key-management modes. How controllers record member roles and foreign configurations is covered in RAID Metadata, Member State and Foreign Configurations.

Two bounded examples: controller key management and NAS auto-unlock

Controller-managed credentials with an external dependency (Dell PERC 10, vendor-specific). Dell’s PERC Self-Encrypting Drive (SED) Support and FAQs tech note covers PERC 10, where firmware 50.5.1-2633 added enterprise key management. Under Local Key Management, the user-provided passphrase is hashed and stored on the controller, and the controller uses the stored key to unlock secured drives it detects. Under Secure Enterprise Key Management, the unlock key is stored on an external server: during boot the controller requests it from iDRAC, which obtains it from the key management server, and the data is not accessible until iDRAC can communicate with that server. For a record, the second mode means the controller and the drives are not the whole dependency — the management controller, the key server and their administrators are part of it. The same note allows moving secured disks between controllers but requires the original passphrase on import. Newer PERC generations and other vendors’ controllers are documented separately and can behave differently.

NAS automatic unlock as a configured option (QNAP, vendor-specific). QNAP’s SED tutorial covers SED secure storage pools in QTS and QuTS hero; its documented scope is all QNAP NAS models and TL series JBOD enclosures running QTS or QuTS hero, and it excludes SED features for drives installed on drive adapters with hardware RAID. TCG Opal drives are supported, and TCG Enterprise drives from QTS 5.0.1 and QuTS hero h5.0.1. SED security has to be chosen when the pool is created; it cannot be enabled on an existing standard pool. The optional Auto unlock on startup setting is called “Save encryption key” in some earlier versions. Where the documented Auto unlock on startup option is confirmed as enabled, the system can unlock and mount the SED pool without the user entering the password at that start. This does not establish that the password is known or that the saved unlock dependency can be reproduced on another unit. A NAS that is simply accessible after a restart does not by itself confirm the option: someone may have entered the password, or another documented authorized flow may have been used. The tutorial does not say where the saved key is kept, so it should not be assumed to survive a chassis or system-disk failure. Moving the drives to another NAS requires the password and a QTS or QuTS hero version the same as or newer than the original, and migration between QTS and QuTS hero is not possible. The tutorial also warns that if the password is forgotten, the pool or volume becomes inaccessible and all data unrecoverable. If no usable authorized unlock path remains, knowing the correct RAID layout does not restore access. A currently working auto-unlock or already unlocked view is a separate surviving access path whose dependencies should be preserved; a forgotten password alone does not prove that the data is already inaccessible.

Preservation choices by what the source returns

A decrypted view is available. A prioritized, independent export of the most important content can be considered, if the members’ health and the consistency of the data allow it; Live Systems, Snapshots and Consistent Recovery Copies explains what a copy of running databases or virtual machines captures. The export does not replace member images, metadata or the dependency record, but it can keep the content that matters if the unlock path is later lost.
A member returns ciphertext. Preserve a defined scope — which members and ranges — together with its metadata and the dependency record. That is preservation, not a promise of an unlock; What a Disk Image Preserves — and What It Does Not covers what such a copy carries.
A range refuses reads. An authorized access path has to be established first. Trying more RAID geometries does not open a locked range.

Health comes before additional reads. A full surface scan of a failing member only to find out whether it is encrypted adds load without answering the question, which configuration and records answer better; How to Image a Failing Drive Safely covers acquisition planning for weak members. Neither power decision is safe by default: an unstable system left running can degrade further, and one shut down may lock layers that nobody can unlock again.

Training scenario: the volume is readable, but nobody knows how it unlocks

Observed

A RAID volume on a server is online and readable. Its members are self-encrypting drives, the controller reports security as enabled, and no one present knows whether the controller holds the key locally, obtains it from a key server, or would ask for a passphrase at the next boot.

Interpretation

A readable volume shows that the unlock path worked at the last start. It does not show which path that was, or whether it would work again after a shutdown.

Safer next step

Before any planned shutdown, record the key-management mode and identifiers from the existing interface and documentation, ask the system owner who holds the credential and who administers any key server, review the health already reported, and consider a prioritized export of critical data if health and consistency allow.

Limit

If the passphrase or key server cannot be confirmed, the export may be the only plaintext copy. The record documents the dependency; it cannot recreate a key that no longer exists.

A restart is not a reset: actions that change security state

A power cycle, or a reset event covered by the device’s locking policy, can return ranges with locking configured to a locked state until the system unlocks them; whether a given host restart removes drive power or counts as such an event depends on the device, controller and configuration. Reset, revert, cryptographic erase, secure erase and rekey are different classes of action: they change credentials or keys. The Opal SSC v2.30 lists Revert, RevertSP and GenKey among its data removal operations, using cryptographic erase in which the keys used to encrypt user data are changed (§3.1.1.6); the TCG and NVMe white paper describes cryptographic erase as destroying a media key and generating a new one, after which data encrypted with the old key can no longer be decrypted. Dell’s PERC note says a cryptographic erase leaves the data indecipherable and unrecoverable, and QNAP’s tutorial says its SED Erase erases all data on the disk and removes the encryption password.

What a specific command does depends on the product and on the drive’s state: not every menu item called “reset” destroys a media key, and changing a credential usually re-wraps a key rather than replacing it. Because some of these actions do destroy keys and data, none of them is a diagnostic step, and they are not substitutes for an authorized unlock. Importing secured members into a controller can also re-key them, as the Dell example shows, so an import is a state change rather than a read.

Technical references: TCG Storage Opal SSC v2.30 — full disk encryption required (§2.4); LockingEnabled reported separately (§3.1.1.3); Revert, RevertSP and GenKey as data removal (§3.1.1.6) · TCG FAQ on Opal SSC 2.02 changes — new optional LockOnReset values, hardware reset as an option (Table 1) · TCG and NVM Express: TCG Storage, Opal, and NVMe — KEK and wrapped MEK; locking after power loss; per-range keys; cryptographic erase; Pyrite without media encryption · Dell: PERC Self-Encrypting Drive (SED) Support and FAQs — PERC 10 Local and Secure Enterprise Key Management, import passphrase, re-keying, cryptographic erase · QNAP: How to use self-encrypting drives on your QNAP NAS — SED secure pools, auto unlock on startup, migration requirements, SED Erase. The Dell note covers PERC 10-era firmware and the QNAP tutorial its named QTS and QuTS hero versions as published at the time of checking; other generations, models and firmware can behave differently, and the TCG documents do not describe how a particular controller or NAS manages credentials.