We have HP notebooks here at work, and it is policy to have HP's hard drive encryption turned on to protect client databases and IP in the case of loss/theft.

I was wondering if there was any evidence of a performance hit in this situation? The machines are primarily used as development workstations. Anecdotal evidence here suggests that the machines are slower.

Should we be using another approach (i.e. only encrypting the sensitive data as opposed to the entire disk)?

  • 4
    "Should we be using another approach (i.e. only encrypting the sensitive data as opposed to the entire disk)?" This violates the KISS principle of system administration. If you want people to remember to preform an action to protect themselves it probably will not happen. Your mileage will vary but the less I have to ask my users to do the better results I get. May 19, 2009 at 13:21
  • 1
    Also, if you handle customer's personal info, you will not be covered unless you can prove that their data was encrypted. (Including temp files) Full-disk is the only reasonable way to do this. May 19, 2009 at 21:51
  • This thread is a bit old (and that is the source aswell), but according to this link there is quite a lot of performance loss when using FDE. Overhead and Performance Impact when Using Full Drive Encryption with HP ProtectTools and SSD
    – timss
    Oct 24, 2013 at 20:53

9 Answers 9


The "HP Protect Tools" is a rebadged McAfee/Safeboot FDE product. The performance impact shouldn't be too bad -- I'm assuming that you're using AES.

We encrypted about 5,000 laptops three years ago, and our folks didn't report any significant performance issues. A few older boxes blue-screened, that's about it. You may be experiencing slowdowns immediately after enabling encryption... encrypting the disk can take 8-20 hours depending on the vintage of the equipment and size of the disk.


We've used Safeguard Easy for years and Truecrypt's whole disk encryption since it came out, and neither has caused a big performance hit; even the older notebooks run development and database software without a noticeable difference in speed. Some people will even tell you that whole disk encryption software makes some operations run considerably faster due to compression, improved drive read routines, pipelining and the like. I wouldn't go that far, but as with most things, the truth is probably somewhere in between.

The peace of mind from encrypting your disk, particularly if you have any kind of regulatory/compliance threshold in your industry (or are just paranoid) is worth the minimal hit of the encryption software we've used for this purpose.

  • 1
    I have been using truecrypt for about a year now and don't really even know it is there. I have also had my sales team tell me their machines are faster after we encyrpted them. May 19, 2009 at 13:19

To answer this question, we need to know: is your app disk bound, CPU bound, or something else? Traditionally disk encryption involves a minor hit to performance; disk is usually slow that the decryption overhead is miniscule. However, if CPU is a concern, this can get hairy.

Development workstations are usually CPU powerful, to improve productivity. Faster build times, autocompletion/intellisense, automated unit tests, etc. Normally a laptop's compromises in the name of portability hinder the idea; giving developers a laptop suggests you've already run out of ideas for spare CPU cycles and might be able to afford disk encryption.

What you need to do as an IT professional is build a model of what developers need computational power for, and benchmark how those tasks fare under proposed conditions: no encryption, full disk encryption, and partial encryption.


The only proof is to measure. Take timings on a laptop with no encryption and compare with one that does. Of course there will be overhead in the encryption, but don't rely on a subjective "feels slower". What encryption are you using? Bitlocker? 3rd party app?

As to the final question, it is too easy to accidentally miss (or even define) what is sensitive data. So I would keep the whole disk encryption if possible.

  • We're using the built in HP encryption - "Drive Encryption for HP Protect Tools"
    – csjohnst
    May 19, 2009 at 3:30

My own experience is that ca 30% of the CPU will be dedicated to crypto, and a 50% hit in disk performance. I've tried several encryption alternatives - SafeGuard, OSX FileVault, PGP WholeDisk.. the same rule of thumb seems to apply. The CPU-use is particularly annoying though, as it affects battery time too.

A quick google search revealed this test which seems to verify my gut-feeling: http://www.isyougeekedup.com/full-hard-disk-drive-encryption-benchmarks-and-performance/

  • Note that the benchmark on isyougeekedup.com (which has a different address) is a synthetic benchmark. It's not clear how this relates to real usage.
    – sleske
    Feb 26, 2010 at 2:28

Linked here are a blogger's measurements from 2012. On an SSD the impact is huge.

Write speed has roughly been quartered whilst read speed is a little over half

The CPU is the bottleneck but if you have plenty of physical threads or even Intel Hyperthreads this might not bother many users. The difference is less on an hard disk drive which is slower than an SSD to begin with. The results for both devices are shown at the link.

Link to measurements of read and write speeds before and after encryption


For the love of God and all that is pure and right, stay away from Credant!!

It is used in our (non-technology) company and virtually all the developers have a special security waiver to not have it installed on their PCs nor laptops. It suffers from horrible performance when accessing many files at once, like when compiling code. We also had an issue where we had a service that would read the registry and other configuration files, which started up before user login. Well, as the files were not unencrypted until after the user logged in, the service would die an early, horrible death.

Also, once this steaming pile of code is installed, it is supposedly as hard to uninstall as IE, but this has not been verified in a non-lab environment because it has usually resulted in hosing the system requiring a reimage. YMMV


Not sure if you can do this (maybe in a lab?) but can you try rerunning these tests with AV uninstalled (or at least disabled). The reason I suggest this is because we had a customer with a similar issue as yours (except they had more delay writing to the drive then deleting; they also had the write cache support issues that you have) and we reran our benchmark tests with AV removed from the system and found that Win2008 (before R2 was released) out preformed Win2003 by alot. Turned out that the AV was responsible and we had to find a different AV provider.) Not sure that it will help you or not but it's something to check if you have the option.


I would avoid and do not use the Drive Encryption for HP protecttools. I recently purchased an HP elitebook 8440w running windows 7 professional 64-bit. I thought I was doing the right thing by enabling drive encryption as this user would be traveling a bunch with sensitive documents. That was a great idea until the software would not let him login anymore. The drive encryption software uses a Mcafee Endpoint Encryption login prior to the hard drive being accessed to start booting the operating system.

I encountered several errors including Token file not found and token is not logged in. I attempted to login using the drive encryption backup file saved to USB to authenticate. After that, Windows 7 was stuck in the "Startup and Recovery" mode and would not boot normally no matter what option of safe mode, last known good configuration, boot logging or repair options were chosen.

In summary, this software is not ready for use in the business world. It is a great idea to use drive encryption, but if you encounter an issue or hard drive corruption, there is no method to decrypt the hard drive even with the appropriate authentication. Stay away, stay very far away from Drive encryption for HP ProtectTools!

(your mileage may vary but mine was abominable)

  • 1
    While I accept that you had a problem with the product the poster mentioned, this 'answer' doesn't really have anything to do with the question about FDE performance.
    – Zoredache
    Dec 16, 2010 at 19:08

You must log in to answer this question.

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