He was sent our way by someone who had run into exactly the same problem, and it's the little details like this one that matter. His own words were "Bitlocker was deployed to my work PC and it encrypted my external SSD", however "The encryption process did not complete properly, as a result, I was not provided with a password or recovery key". A process that begins, stops midway and hands back no key is completely different from one that finishes and gives the user a key for the encrypted volume. A colleague hitting the identical failure also suggests a policy misfiring across machines, and that shapes where the key, if it exists at all, might still be recovered.
| Media | External SSD caught by a work PC's BitLocker policy: encryption started but never completed, and no password or recovery key was issued to the owner |
| Reported situation | Corporate BitLocker policy applied to a personal external drive · process stopped before completion · no key or password given to the user at any point · a co-worker reports the identical failure · access to the drive's contents needed |
| Fault class | Partial encryption: a volume left half converted, where unencrypted portions may still be readable and key material may survive on the initiating system, unlike a cleanly finished encrypted disk |
| Equipment used | Before any interpretation, a disk image of the drive taken under a hardware write-blocker, so nothing is written back to the original · BitLocker metadata read from the image to show the conversion state and how far encryption had got · unencrypted areas the conversion never reached identified and recovered directly · conversion state and unencrypted portions verified at hex level in X-Ways Forensics · the initiating PC's escrow checked: Active Directory, Azure AD or a recovery key backup where corporate policy would have placed one · dislocker and native tools used against the image where valid key material is found |
Full disk encryption happens over a period of time, so if the process is cut off, there is evidence of exactly where it had got to. BitLocker encrypts a volume on a sector-by-sector basis. If the encryption fails at any point, there will be unencrypted sectors alongside encrypted ones. How far it got can be worked out by examining the metadata associated with the volume. Any sectors it never reached remain exactly as they were and don't need a key at all to read.
There are two meanings of "No key was provided", and these must be separated carefully. One is that a key does exist but was never shown to him, possibly held within the corporate escrow used to deploy the policy. Getting this key back would be an administrative retrieval. The other is that the failure was so severe that a usable key was never generated, and the encrypted portion of the data is unrecoverable. Before promising anything, we establish which of the two applies, rather than assuming the hopeful one.
The fact that his colleague has the same fault is a real clue, not idle chit-chat. With several computers failing in the same way, the organisation probably has a problem with how it is deploying BitLocker. Most organisations that push BitLocker set it up to escrow recovery keys centrally, within Active Directory or Azure AD. The key he was "not provided" may well be sitting in his employer's directory already, and all it would take is one simple IT request. Asking for it is therefore the first course of action and the cheapest one to try.
Being able to read parts of the drive is really a nice present. A fully encrypted BitLocker volume with a genuinely lost recovery key is beyond reach. This drive is not in that position: because the encryption never completed, a meaningful share of the data can be read directly, and whatever sat in the unencrypted sections comes back however the key question is resolved.
Creating an image of the drive is a safe way of preserving its fragile intermediate state. Once a drive is part-way through the conversion, there is a real risk of further sections being encrypted as soon as anyone tries to mount it or carry on converting it. In other words, mounting it or resuming the conversion could destroy some or all of the data that is currently readable. A write-blocked image freezes the drive in exactly the condition the failure left it in, and every extraction and key attempt is then run against copies.
How the work splits is set out before any of it starts. The unencrypted data can be recovered straight away. How much of the encrypted data comes back depends on whether valid key material turns up in the corporate escrow. The best possible outcome is that a valid key is stored in the directory and the entire drive can then be read. A realistic expectation is that the readable portions are returned while the rest waits on IT. In the worst case, no key was ever generated and the encrypted data stays sealed. Each of these three scenarios is explained clearly at the start, not after the fact.
This original drive was imaged under a hardware write-blocker, then its BitLocker metadata was extracted from that image to work out how far through the conversion process it had gone. The areas that had never been encrypted were identified and recovered directly. Next, the employer's escrow was checked (Active Directory, Azure AD or a policy key backup), and dislocker with native tooling was used against the image wherever a valid key was found. All extractions were verified.
The current state of the conversion was determined, the unencrypted areas were recovered directly, and any encrypted portions remaining were resolved against the company's escrow where the key survived. A free assessment and one fixed price quoted in writing, plus VAT; BitLocker work is paid upfront once you accept the fixed quote. The decode: a fully encrypted BitLocker volume that has lost its key stays locked, but yours never completed. The part it never got to is readable today, and the key nobody handed you is most likely sitting in your employer's directory rather than lost.
Stop attempting to mount the drive or reconnect it. An attempt to restart the broken encryption process can encrypt the portion of the disk which remains accessible, destroying data you can still reach. Prior to presuming the recovery key is lost, ask your IT department to obtain the BitLocker recovery key from Active Directory (AD) or Azure AD, since corporate deployments almost always hold these keys centrally. If another employee encountered the same problem, then that would indicate a possible company-wide IT policy issue, which they need to know about anyway. Do not alter the original drive, so that its partially encrypted state, along with all the parts of the disk that are still readable, remains undisturbed.
Our case files are written up from genuine enquiries our lab has handled for customers across Sheffield and South Yorkshire, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery approach our engineers apply to that fault, using the equipment listed.
All jobs start with a complimentary diagnostic and a fixed quote. In most instances you only pay if we successfully recover your data. Start online today, or call our freephone number.