Users might lose access to their EFS private keys through cases, like corrupted user profiles, hard disk failure, OS reinstall etc. Now here are some important facts about EFS Keys before we start the comparison

1-      A time valid certificate and private keys needs to be available for encryption/decryption of data

2-      The client will only check for revocation status of the certificate, in the case of Encryption, or adding users to the EFS ACL. In the case of decryption or data access, revocation checking is not checked. Accordingly, revoking a certificate does not mean that the user has lost access to data; it only means that he/she cannot encrypt more files with it. The only way for it to become unusable is if it expires

Key Recovery Agent (KRA)

Key Recovery Agent is I would say the most systematic and controlled key fault tolerance method available. The reason for this, is that for key Recovery to occur the following conditions need to be fulfilled

1-      One or more users need to have a valid KRA certificate and private key

2-      Key archival needs to be enabled on the Issuing CA and on the Certificate template

3-      By default the Certificate manager needs to approve the issuance of the KRA certificate

4-      The CA manager(s) needs to manually extract a file from the CA Database that contains the intended private key using the command Cetutil –getkey

5-      The KRA need to take that file and decrypt it using his/her KRA private key

From an operational perspective, it is easy to apply governance to the KRA process especially if proper segregation of duties is applied. However, it is definitely the most time consuming method, and practically speaking, it might take the EFS Key owners too long to access files when they don’t have access to their private keys. The downside of KRA is that, data encrypted with old EFS keys cannot be recovered since they are not archived in the CA.

Data Recovery Agent (DRA)

The DRA is a shadow user that has access to EFS encrypted data, along with data owners and the designated users who have access to the data.

The issue with a DRA is that it is hard to govern the data recovery process. Practically speaking, if the DRA has access to the data location, he/she can access it maliciously. One way to govern DRA is use Forefront Identity Manager or to use smart card n to m authentication for the DRA user. The upside of DRA is that it provides the fastest recovery time.

Credential Roaming (CR)

Credential Roaming could be in a way looked at as a key fault tolerance option, because it allows for replicating the local key store from the user profile located on the computer to the user object on the ADDS. This is a good option and involves very fast key recovery time. However the downside of it is that it does not help when key deletion is intentional, since the local key store will replicate the deletion action. However in cases of hard disk failure or profile corruption (if the local profile is corrupted), there’s a big chance that they key on the user object will be retained since the deletion would most probably not be replicated.