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...


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 cuestión 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 '16 at 12:33
  • @Priyank I've updated my answer
    – GnP
    Aug 30 '16 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.


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 '16 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.