Self-encrypting drive · SED · OPAL · eDrive · hardware encryption · ATA password · BitLocker · recovery key
Self-encrypting and OPAL drives BitLocker recovery. The drives that encrypt themselves, how BitLocker uses them, and why the software case became the norm.
A self-encrypting drive, or SED, does its encryption in the drive's own hardware, all the time, and BitLocker can either manage such a drive's hardware encryption (a feature called eDrive, using the OPAL standard) or ignore it and apply its own software encryption on top. This matters for recovery, and it has a history worth knowing. In 2018 researchers found that the hardware encryption in several popular SEDs was poorly implemented and could be bypassed, and because BitLocker had been trusting that hardware encryption on eDrive-capable drives, the weakness undermined BitLocker too. Microsoft responded in 2019 by changing BitLocker's default to use its own software encryption rather than trusting a drive's hardware encryption, unless an administrator explicitly chose otherwise. So most BitLocker drives today, even self-encrypting ones, are protected by software BitLocker. For recovery, the key questions are which encryption was actually in use and what credential opens it, and the free look establishes that. These drives are recovered only for their owners, behind proof of ownership.
Rather talk it through? An engineer answers the bench line
0800 6890668
Why these machines land at the recovery screen.
A self-encrypting drive encrypts everything in hardware using a key held in the drive, and that internal key is itself protected by a credential, an ATA password, or BitLocker through the eDrive/OPAL mechanism. When BitLocker manages an SED as an eDrive, it protects the drive's hardware-encryption credential with its usual protectors, and your recovery key still opens it. When BitLocker instead applies software encryption on top, which since 2019 is the default, the drive's own hardware encryption is not the thing in play, and we decrypt the software-BitLocker volume with your key.
The history explains why software is now usual. In 2018 security researchers showed that the hardware encryption of several widely-used SEDs could be bypassed because of implementation flaws, and since BitLocker had been trusting that hardware encryption on capable drives, those flaws weakened BitLocker on them. Microsoft's 2019 response was to default BitLocker to its own software encryption rather than trust a drive's hardware encryption. The upshot for an owner today is that your drive is most likely protected by software BitLocker regardless of whether it can self-encrypt.
For recovery, we establish which encryption was actually used and what credential opens it, then recover the drive and decrypt with your key, imaging first as always. A failed SED is recovered like any failed drive; the encryption, hardware or software, is resolved with your credential at the end. Tell us the drive model and anything you know about how it was encrypted.
What to know for this make.
What you see, and what is behind it.
Describe yours to us →| What you see | The usual reason | Where that leaves you |
|---|---|---|
| A self-encrypting drive locked by BitLocker eDrive, key held | BitLocker-managed hardware encryption | The recovery key opens it; recovered and decrypted |
| An SED with software BitLocker on top, key held | Software encryption, the 2019 default | Decrypted as software BitLocker with your key |
| A failed self-encrypting drive, key held | A hardware failure with encryption on top | Imaged, then decrypted with your credential |
| An SED locked by an ATA password nobody has | Hardware encryption with a lost credential | Assessed honestly; often the hard limit |
| Not sure which encryption was used | Hardware or software, unclear | The free look establishes it before any work |
From the drive arriving to your files going back.
Work we have closed →Logged the day it lands, and the first look costs nothing Free
A number goes on the parcel and the drive the day it is opened, matched to your enquiry by the booking sheet inside. Before anything is read we check the proof of ownership you sent. The drive is then connected through a write blocker, read-only, and examined: whether it is a healthy drive behind a lost key, or a failing drive behind a known key, is settled here, and so is whether what you want is possible. That first look is free, and you may stop at it owing nothing.
Imaged at the sector level, before anything else
A drive that answers at all is imaged in full on a hardware imager, behind a write blocker, weak areas last, with a map kept of what could not be read. The image is a copy of the encrypted sectors, so it is useless to anyone without your key, which is a privacy gain in itself. Every later step is done on the image. The original drive is never decrypted, never written to, and never worked on directly.
The physical fault repaired on the clone, when there is one
A drive that has failed, that reads slowly or that drops out is stabilised and imaged in passes; a mechanically failed disk is repaired and read on the bench, a dead SSD controller read at the chip level, before any decryption is attempted. The aim at this stage is one clean image of the encrypted volume to decrypt from. Where the drive is healthy and the problem is only the key, this stage is skipped.
The image decrypted with your key or password
With your recovery key, recovery password or the drive's password, the image is unlocked: the protector releases the Volume Master Key, the VMK releases the Full Volume Encryption Key, and the volume is decrypted from the clone. Where the metadata or header is damaged, repair-bde and the key package rebuild it at the block level onto a separate target. Where the key is lost but a memory image or hibernation file is available, the Volume Master Key is extracted from it with Passware. Without a key, a password to attack, or a memory capture, the volume cannot be opened, and you are told so at the free look.
The file system rebuilt, and the list before the bill
Once the volume is open it is an ordinary NTFS or exFAT file system, and any damage in it is repaired on the image and the files recovered. What was recovered is listed for you first, and only then does a bill exist. The files go home on fresh media. The original drive is returned, or securely destroyed at your request; we never send the key and the data by the same route.
From the bench
- Tell us the drive model and how it was encrypted, if you know. Whether hardware or software encryption was in play shapes the whole recovery.
- Most drives today use software BitLocker, even self-encrypting ones, because Microsoft stopped trusting hardware encryption by default in 2019.
- A lost ATA password on a hardware-only SED is often the hard limit, and we say so honestly at the free look.
2019: Microsoft defaulted BitLocker to software encryption after researchers found weaknesses in several self-encrypting drives' hardware encryption.
What helps, and what harms.
Do this much first
- Have your recovery key or password ready
- Stop using a failing drive at once
- Send the drive to be imaged, not decrypted in place
- Send proof the drive is yours
What sets us back
- Decrypting a failing drive in place
- Running chkdsk or repair tools on a dying encrypted drive
- Continuing to power on a drive that is dropping out
- Assuming a failed encrypted drive is unrecoverable; with the key it usually is not
Questions answered before you commit.
What is a self-encrypting drive, and how does it relate to BitLocker?
A self-encrypting drive, or SED, encrypts everything in its own hardware all the time. BitLocker can either manage that hardware encryption, through eDrive using the OPAL standard, or apply its own software encryption on top. Which was used shapes how the drive is recovered, and your recovery key or credential is what opens it.
Why does Microsoft not trust hardware encryption any more?
In 2018 researchers found that the hardware encryption in several popular self-encrypting drives was poorly implemented and could be bypassed, which undermined BitLocker on drives where it trusted that hardware encryption. In 2019 Microsoft changed BitLocker's default to use its own software encryption instead, unless an administrator chose otherwise.
Does my drive use hardware or software BitLocker?
Most likely software, because that has been the default since 2019 even on self-encrypting drives. But it depends on when and how the drive was set up, and whether an administrator chose hardware encryption. The free look establishes which was actually used before any recovery work.
Can you recover a failed self-encrypting drive?
Yes, with your recovery key or credential: a failed SED is recovered like any failed drive, and the encryption, hardware or software, is resolved with your credential at the end. A hardware-only SED locked by a lost ATA password with no BitLocker protector is often the hard limit, which we assess honestly and free.
What does it cost?
Single-disk recovery and decryption of a failed self-encrypting drive is £800 + VAT, 50% non-refundable on acceptance and 50% no fix, no fee. The drive must be removed from the computer and sent in on its own, and the free look establishes which encryption was used first.
Begin here if yours is doing the same thing.
The data is behind the key, not gone.
Looking at it is free, and it starts with whether you have the recovery key or can retrieve it. Tell us the make and model, what the recovery screen says, and what happened just before it, and send proof the drive is yours. Back comes a straight account of what is possible and the one price to do it. Until then, reinstall nothing and reformat nothing.