XPS 15 7590: How to pass by BitLocker recovery key

@Dubistmein  if your motherboard was going to be replaced, the Dell tech shouldn't have simply suspended BitLocker.  He or she should have confirmed that you had a Recovery Key (which you can back up at any time when your drive is unlocked) or completely disabled it prior to performing that replacement.  Suspending BitLocker allows your system to boot ONCE without needing the TPM embedded on the motherboard to provide the key.  Suspending BitLocker is intended to be used for situations such as making certain changes that would otherwise cause the TPM's "platform integrity check" to fail and therefore cause the TPM to refuse to release its key, and also for situations where you might need to reboot a system remotely and don't want it to get stuck prompting for a BitLocker PIN if you have one enabled, since you wouldn't be able to enter that remotely.  But when BitLocker is suspended, after that first reboot, the key is required again -- and in your case since your motherboard was replaced, the TPM on the new motherboard didn't have the key at all, so it of course could not provide the key as needed. BitLocker does not automatically store a new key into a new TPM when it sees that the motherboard has changed.  You have to take manual steps to do that.

So the Dell tech definitely could have done a better job, but it is also true that you should always -- ALWAYS -- have your Recovery Key backed up somewhere for any drive where you enable BitLocker.  I'm not sure how BitLocker would even have been enabled without somebody having the Recovery Key.  If your Windows login is linked to your Microsoft account, it should be available in the cloud by logging into your Microsoft account.  If you enabled it manually, the initial setup wizard would have forced you to back up your Recovery Key by saving it to a file, printing it, or storing it in the cloud.  And if this is a system managed by an IT department, they have ways to enable BitLocker while backing up the Recovery Key somewhere, including in their Active Directory environment if this system is joined to an AD domain.

But if you truly don't have a Recovery Key, then there's no other way to bypass BitLocker.  The Recovery Key is the bypass mechanism.  If BitLocker could be bypassed without knowing the Recovery Key, then the encryption would be effectively pointless.  So unfortunately if you don't have your Recovery Key, then the data on the drive is effectively lost, no matter how much you would be willing to pay.  Hopefully you have a recent backup of your data.  If you don't, then I would suggest that you implement a backup solution going forward.  System image backups are particularly useful since they allow you to restore your entire hard drive, including your OS, applications, and data.  Macrium Reflect is a popular tool for this purpose, and it has a free version that is quite capable.

@Dubistmein  for systems joined to an Active Directory environment, which is often true of work systems but usually NOT true for personal systems, there are a variety of options for backing up a system's BitLocker Recovery Key. But it would be up to the IT department to decide what mechanism(s) to use for that purpose.  If you're having this issue on a personal system, then I would NOT expect your work IT to be able to help you.  But if you're having this issue on a WORK laptop, then I would absolutely expect your work's IT department to be able to help you.  If your work is allowing (or requiring) BitLocker to be used on the systems that they manage, then they should absolutely be taking responsibility for backing up the Recovery Keys of those managed systems.  The mechanism I mentioned in my earlier post about backing up Recovery Keys into Active Directory is easy for an IT department to implement.  It involves using a tool called Group Policy, which allows organizations to enforce certain settings, configurations, and restrictions on systems.  One setting that can be configured that way basically says, "Automatically back up BitLocker Recovery Keys to Active Directory", and another setting basically says, "Prevent BitLocker from being enabled if the Recovery Key cannot be backed up first" -- which can happen if you try to enable BitLocker while not connected to your work network, for example.  I personally have both of those settings configured in the Active Directory environments that I manage.  If your work's IT department did not implement policies like that, then I personally would consider that a serious oversight on their part, but of course serious oversights do happen, so that may be what happened here.

The system image suggestion I mentioned was not a way to recover your data at this point.  It was a suggestion of something you could do in the future to prevent something like this from happening again, because if you had a system image backup that was captured while the drive was unlocked (such as while Windows was running), then you would have been able to restore that at this point.  A backup captured from within Windows would have been unencrypted, which means that if you restored that, your data would have been unencrypted and therefore you would not have to deal with BitLocker.

@Dubistmein  based on the information you provided, I can't really answer whether the laptop you have would be considered a work laptop.  The relevant question is whether your laptop was joined to their Active Directory domain.  The IT department should be able to answer that.  But the question of who ordered the system wouldn't be relevant on its own, and I'm not sure what "the Microsoft" was that you installed and what the registration process did.  Requiring the laptop's physical address is typically used for network monitoring and/or management purposes, but that by itself would not determine whether it was a personal or work laptop.

In terms of the old motherboard, yes in theory if you were able to get your original motherboard back and its TPM had not been cleared, then it should be able to unlock your drive since the TPM should still have the decryption key for your drive.  I've never actually tried to get a replaced part back, but I seriously doubt that it would actually be possible.

@Dubistmein  I definitely understand the pain, and I wish it were clearer how this happened in the first place, since BitLocker is generally designed to take steps to make sure that a Recovery Key gets backed up before encryption is enabled specifically to avoid outcomes like this.

You're not going to bypass BitLocker by changing BIOS settings.  Those threads are related to the "platform integrity check" I mentioned earlier.  Basically, when a TPM on the motherboard stores a decryption key for the drive, it will only release it in order to allow the drive to unlock automatically if it determines that nothing about the system's hardware or firmware environment has changed since the "known trusted" state, since certain hardware or firmware changes could be related to a security exploit intended to compromise the key that the TPM would normally release.  Certain BIOS settings changes and even BIOS updates (or downgrades), as well as certain hardware additions or removals, count as those kinds of changes, so if the TPM detects changes from that "known trusted" state, it will refuse to release the key and you'll instead be prompted for the Recovery Key.  At that point you either have to enter the Recovery Key (in which case the TPM will start trusting the new configuration going forward) or else you have to reverse whatever change you made so that the system returns to the "known trusted" state and the TPM will therefore automatically release the key again as it did before.  Or actually this is one of the INTENDED use cases of suspending BitLocker, because if you suspend BitLocker before making those changes, then the TPM will automatically update to trust the new configuration going forward WITHOUT you having to enter the Recovery Key once after the change.  But none of that amounts to a bypass.  The BIOS settings "bypass" you're seeing would just be undoing whatever BIOS settings change caused the platform integrity check failure in the first place.

Unfortunately in your case, the problem isn't that the TPM is refusing to release the key.  The problem is that the new TPM in your new motherboard doesn't even have the key to begin with, so no amount of changing BIOS settings is going to help here.  And to my knowledge there are no known exploits or vulnerabilities in BitLocker overall that would somehow allow decrypting the data without the key.  If there were, that would be cause for massive concern because BitLocker is widely used and relied upon to protect sensitive data.

I don't know whether this will make it worse for you or give you some closure, but there really isn't any point in holding out hope that someone will come along with a bypass.  Your data is encrypted using algorithms that are widely used and believed to be highly secure, and it seems there's no decryption key available.  I don't know how that happened, but without a key, there really is no recourse here.  I've been an IT professional for about 15 years now, I've used BitLocker fairly extensively, and I have a semi-professional interest in information security.  Unfortunately, I know what I'm talking about here.

@Dubistmeinsuspension of BitLocker might work for other scenarios, but it absolutely doesn't work for a motherboard replacement scenario. Again, suspending BitLocker allows the system to boot ONCE without needing the key from the TPM because suspension causes the disk's decryption key to be temporarily written to the disk itself in cleartext (i.e. in unencrypted form).  But afterward, that decryption key is erased for obvious security reasons, and from that point on the key needs to come from the TPM again -- which won't be possible on a brand new motherboard.  If you do some searching for information about what you're supposed to do with BitLocker when replacing the motherboard, you will find that the answers are either to disable and re-enable BitLocker (which causes a new key to be stored in the new TPM) or to run some commands to make BitLocker recreate its "TPM protector", which causes it to store a new key in the new TPM without having to decrypt and re-encrypt the entire drive.  But that is a manual process; it does not happen automatically.  And that's why suspension was not the correct approach for the repair tech to take in this scenario.

Maybe they're convinced that suspending BitLocker works because the repair tech only waits around long enough to confirm that the system boots normally once.  The system will indeed to that -- once.  So if the tech leaves at that point, they might never know about the lingering problem they left.  Most users will have their BitLocker Recovery Key, so they might end up fixing this on their own without ever complaining to Dell.

@Dubistmein  the ability to log into a page for a Microsoft service using a work account does NOT necessarily mean you're using that service.  Microsoft's services are all handled by Microsoft accounts, and Microsoft offers a huge array of services.  So it is absolutely possible to have a Microsoft account that will allow you to log into something without you ever having used that particular service.  Also, Azure Active Directory is something that your work IT organization would need to have set up, not something you would do on your own.  And if your system wasn't joined to any sort of Active Directory domain anyway, which it sounded like your IT department confirmed was the case, then it definitely wouldn't have sent any information to Azure Active Directory.

@Dubistmein  the more precise phrasing for that article would be that systems are shipped from the factory with BitLocker pre-installed and in a suspended state.  This means that all of the work to actually encrypt the data blocks on the disk has already been done, but due to the suspended state, the decryption key is being stored on the drive itself.  The end result is that the partition works as a normal unencrypted partition.  I can't speak to Lenovo on this next point, but on the Dell side, if you choose to link your Windows login to your Microsoft account at some point, then the Recovery Key gets backed up to your Microsoft account and BitLocker is then fully enabled.  Since the encryption has already been done in advance, this enable process is virtually instantaneous, since at that point the system just has to purge the decryption key rather than spend time doing the encryption.  I wouldn't be surprised if joining the system to an Azure Active Directory environment triggered the same behavior, but I haven't confirmed that myself.  And again, when you're dealing with Active Directory, whether the Recovery Key gets backed up might depend on how the IT administrator configured their Active Directory policies.  It may indeed be possible to have a policy that causes systems joined to the domain to have BitLocker enabled without backing up the Recovery Key anywhere.  That would of course be poor design, as I already said, but that doesn't mean it doesn't happen.

I don't know where your Recovery Key ended up, partly because it's not even clear whether your system was joined to an Active Directory environment.  I do know that BitLocker does take steps to mitigate the risk of users ending up in this situation where their system is encrypted and the Recovery Key hasn't been backed up anywhere.  It's not like Microsoft, Dell, and Lenovo didn't realize the danger of that situation.  That said, it's also true that in the real world, not everything turns out as the design intended.  I suppose it's also technically possible that it was in fact backed up to your own Microsoft account at one point and then something else happened to get rid of it, although I'm not sure what that would be.  I've definitely seen other threads on this forum with people saying they were prompted for a BitLocker Recovery Key after some hardware or firmware change and they didn't even realize BitLocker was enabled on their system before that point, never mind where to find their Recovery Key.

My own perspective on systems shipping with BitLocker "pre-staged" is that I understand the benefit of having data encrypted -- smartphones encrypt their data by default too -- but I also feel that if vendors are going to do that, then when the user does something that fully enables BitLocker rather than keeping it suspended, Windows should pop something up at them saying, "Hey, your disk is now using BitLocker.  Be aware that in certain circumstances you might need your Recovery Key at some point in the future.  We've already backed it up [wherever], but if you want to back it up yourself somewhere else, here it is.  And you can always go to Control Panel > BitLocker in the future to back it up again as desired."  And BitLocker does sort of do this when you set it up manually, but that's not what we have today for the "pre-staged" deployment scenario.

@Dubistmein  FANTASTIC!!  I'm a little disappointed that whoever was in your IT department didn't immediately know where to go for Recovery Keys if they were in fact storing them for systems like yours, but at least you finally got through to someone who was able to help!

Yes, you're correct that if BitLocker is automatically enabled, the Recovery Key should be either in your personal Microsoft account or somewhere that your organization maintains.  My point was just that it was theoretically possible for the organization to enable BitLocker without requiring a Recovery Key backup, and possible for the Recovery Key to have been backed up originally and somehow have been deleted since then.  But it sounds like It sounds like you're good to go.

However, you still need to get BitLocker fully operational again on your system so you don't need to enter that key every time -- unless Windows has started automatically adding keys to new TPMs after a Recovery Key is entered, but I don't think so.  One way to do this is to disable and re-enable BitLocker.  If you do this, you will get a new Recovery Key, so back it up.  Alternatively, you can follow the steps below, which are slightly more complicated but are also much faster since they doesn't require decrypting and re-encrypting, and they will preserve your existing Recovery Key:

1. Open an elevated/admin Command Prompt window.
2. Enter "manage-bde -protectors -get c:"
3. Look for the protector that involves the TPM.  It should be called "TPM", but it might be "TPMandPIN" if our organization required a PIN even for normal BitLocker operation.  Make a note of the exact type name.
4. Highlight the ID of that protector, including the curly bracket/braces, and copy it to the clipboard.
5. Now enter "manage-bde -protectors -delete c: -id YourID".  Replace YourID with the ID that you copied to the clipboard, including the curly brackets/braces.
6. Now enter "manage-bde -protectors -add C: -TPM", or if the protector type you checked in Step 3 was something else, like "TPMandPIN", then replace "TPM" in my example command with that alternate type instead.
7. Reboot your system.  BitLocker should work normally at this point, but if not you can still enter your Recovery Key to get back into Windows.