My organization previously allowed its employees to hibernate their devices(Start>Power>Hibernate). Sometime later, the 'Hibernate' option disappeared from the Start menu. Some employees started using shutdown /h to hibernate their PCs. It worked for a few weeks. Later, running the same command through Windows command prompt threw an error that "Hibernate feature has been disabled on this machine".

Obviously, this was a step taken by IT team for some reason which I fail to understand. First they removed the option from Start menu, later they must've realized that people have started hibernating the PCs from the command prompt, and then disabled that as well.

My question is, how does enabling hibernate pose a security threat? Or could it have some other reason?

If it helps, we have Windows 7 Enterprise PCs, hard drive encrypted by Bitlocker, and we are allowed to put the PC in Sleep mode.

Also, I guess the hard drive is not encrypted when the PC is in sleep mode, but all the data is encrypted when it is in hibernate mode. Please correct me if I'm wrong.

EDIT: Well, my question's domain was not limited to Bitlocker encryption of hard drive. It was kind of a, more general question. I would be interested to know if there are any other threats in hibernate mode, apart from encryption. Also, if encryption would have been an issue, then obviously putting the machine in Sleep mode could be dangerous as well. But they do allow Sleep mode...

  • They might want the employees to shutdown their machines instead of hibernating so Windows updates and patched will get installed. It is a security challenge with some users who never reboot their systems. Nov 2, 2021 at 7:20
  • @FahadAlduraibi No, they have different system in place to make sure the employees keep the machines updated. Each update comes with a deadline. If the machine is not rebooted within the deadline, the machines goes through a forced reboot.
    – pri
    Nov 3, 2021 at 10:20

4 Answers 4


This is what Microsoft has to say about it:

Disable sleep

BitLocker unlock methods for operating system drives—such as TPM integrity checks or requests for a PIN or startup key before allowing access to the drive—are only used when a computer is turned on, is restarted, or comes out of hibernation. If a computer enters sleep mode after a period of inactivity instead of entering hibernation, the drive stays unlocked. Therefore, for added security, it is recommended that sleep mode be disabled by using Group Policy.

Bolds mine. Implied is the fact that resuming from hibernation is as secure as cold booting.

You're probably dealing with an overzealous IT dept, they misunderstood the issue, or they have other reasons not related to disk encryption for the change.

Regarding the more general question of why hibernate might get disabled, you'd have to ask your IT dept. At this point it's not even clear it was done for security-related reasons. Perhaps they were experiencing issues with it on some hardware and disabled it company-wide for uniformity.

Another reason could be they're aiming to disable fast startup for reasons.

Security-related, perhaps not all workstations use FDE or secure boot, and in that case hibernation could be a problem.

We could speculate for all eternity, but unless your IT dept roams SecSE, you won't get an actual answer.

  • Exactly! Any idea what other reasons could an organization have to disable hibernate mode?
    – pri
    Aug 30, 2016 at 12:33
  • @Priyank I've updated my answer
    – GnP
    Aug 30, 2016 at 12:56

From a software agnostic point of view FDE (full disk encryption) is generally implemented as a control to counter the risk of data recovery from lost or stolen devices. If it is for other reasons the following may not be applicable...

From a corporate risk management perspective, the decision about whether sleep or hibernate states should be permitted should be based on a technical assessment of how the FDE software works in those states and whether it will still be effective against the threat scenarios that are applicable.

For pre-boot authentication solutions there used to be a reliance on a device being shut down for the FDE to be effective, this was because of the potential for an attacker to access memory (and therefore in theory crypto keys) using DMA based attacks.

A couple of other factors that are relevant to the decision in current devices (when considering practical attacks):

  • Whether the device has external DMA capable interfaces
  • How storage is implemented (removable drive v’s hardwired memory)

There will be other things to consider as well, for example if a separate pre-boot password and logon password are implemented with differing complexity requirements there is the potential for an easier password guessing attack if the device state does not require the pre-boot password.


Also, I guess the hard drive is not encrypted when the PC is in sleep mode, but all the data is encrypted when it is in hibernate mode. Please correct me if I'm wrong.

The hard drive (minus a small boot partition) is always encrypted. The difference is that, while the machine is running or in sleep mode, the decryption key is in RAM (though it is only used to transparently decrypt and encrypt date coming from / going to the drive; everything that actually touches the drive is still encrypted). On the other hand, during hibernation (or full power-off), there is no power to RAM and the key is gone. Because the hibernation file (hiberfil.sys) is on the encrypted system partition, any secrets that were in RAM and are now in the hiberfile are encrypted too. You can't restore the machine from hibernation, or otherwise read the hiberfile contents, without getting the BitLocker decryption key (from the TPM, or from a passphrase/PIN, or from a flashdrive, or using the recovery key).

obviously putting the machine in Sleep mode could be dangerous as well. But they do allow Sleep mode...

Yeah, your IT department is incompetent. They should have disabled sleep, but left hibernation enabled, not the reverse. Hibernation is safe (no keys in plaintext), sleep is not (key is persisted in plaintext in RAM, and can be stolen by an attacker with physical access). This is documented in many places, some dating back more than a decade[1].

[1] The author of that post was my mentor at Microsoft in 2008.


When you put the system in hibernation the entire memory is stored on disk (hiberfil.sys). This always poses a security threat because the memory can contain private data, passwords, keys and so on. Approaching the storage with another systems gains you access to the entire memory dump. Encrypting the disk helps but not all memory can be encrypted to disk, for example some memory segments must be available in order to run the kernel.

On the other hand, sleepmode still keeps power floating through the memory, and thus requires persistent storage (ignore caching for the moment). The hard disk is always encrypted when BitLocker is setup, even when Windows is up and running.

From an attackers point of view, I don't think hibernation and BitLocker create an insecure environment. I would even argue the sleeping mode to be more vulnerable since it leaves a great window of opportunity for an attacker to try to gain access to plain memory contents.

  • 1
    "for example some memory segments must be available in order to run the kernel" This is not necessary and simply not the case for Windows. Bitlocker or MBR-based FDE software will have to be unlocked before the hibernate file can be read.
    – billc.cn
    Aug 30, 2016 at 13:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .