Data Recovery Case File · Formatted & Logical Faults · Right Key, Wrong Volume

Having the Key Is Not the Same as Having the Right One

His enquiry is unusual in this archive because the key exists. A machine that will not boot: "I am able to launch third-party recovery software, however I cannot access my system drive to recover the data, as the recovery key I have saved within my account is not being recognised." Almost every encryption case here ends with no key at all. A key that is present and refused is a different problem — and it usually has a mundane explanation that can be checked in a couple of minutes.

The decode: three reasons a correct key gets refused

The first and commonest — it is the key for a different volume. An account holds a recovery key for every encrypted volume ever registered to it: every machine, every rebuild, every additional drive. They look identical and are distinguished only by an identifier. The unlock screen displays the identifier of the volume it wants, and the account lists keys against theirs. Matching those two strings is the first thing to do, and a surprising proportion of these cases end there — with the right key three entries further down the list.

The second — the credential is being entered in the wrong place. An encrypted volume typically accepts either a password or a recovery key, and they are different lengths and different things. Entering a recovery key where a password is expected fails, correctly, and the error is frequently unhelpful about which was wanted.

The third, and this is where it stops being an administrative problem: the volume's metadata may be damaged. Unlocking works by using the key to decrypt a protected header that holds the actual encryption key. If that header is unreadable — because the drive has a fault in that region, or the structures were damaged when the machine stopped booting — a perfectly valid key cannot be validated against it, and the rejection is about the volume rather than the credential. That is a recovery problem, not a key problem.

Why the third-party recovery environment matters here: tools that boot a machine to recover files vary in how completely they implement unlocking for an encrypted volume, and some handle it partially or not at all. An unlock should be attempted natively before concluding the key is wrong, because a failure inside a third-party environment may say more about the tool than the key.

What order to work in: match the identifiers, confirm which credential is being asked for, attempt the unlock natively — and only then treat it as a metadata problem. Each step is quick and each eliminates a whole category.

Why the machine not booting is a separate question: it may be the same fault that damaged the volume header, or it may be unrelated. Establishing whether the drive is healthy underneath comes with the assessment rather than before it.

On the bench

The key identifier was matched against the account record before any other work — accounts holding a key for every volume ever registered, distinguished only by an identifier that the unlock screen displays, which resolves a substantial proportion of these cases outright. Unlock was attempted natively rather than through third-party tooling, those varying in how completely they implement it. Volume metadata integrity was assessed, a damaged protected header preventing a valid key from being validated. The drive was imaged write-blocked at block level, and decryption performed against the image once a valid key was confirmed.

The outcome

The identifiers matched first, unlock attempted natively and the volume metadata assessed before any conclusion about the key. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: your account holds a key for every volume ever registered to it, and they are told apart only by an identifier. The unlock screen shows which one it wants — match those two strings first. Then check whether a password or a key is being asked for, and try the unlock natively rather than through recovery software.

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.