EFS utilizes industry-standard algorithms and public key cryptography to ensure strong encryption. The files that are encrypted are therefore always confidential. Even though logon authentication and NTFS file permissions are geared at protecting confidential data, you can use EFS to add an additional layer of security. EFS encrypts data as the data is written to disk, and when users open a file, it is decrypted by EFS as data is read from disk. Users are basically unaware of this process, and need not take any action to initiate EFS encryption and decryption.
Cannot share files that have multiple EFS certificates
let us say that you would like users to share files that were encrypted by using multiple Encrypting File System (EFS) certificates. Users A1 and A2 have valid EFS certificates. File F1 exists on a computer on which EFS is enabled, and users A1 and A2 have read and write permissions on the file. User A1 follows these steps to encrypt file F1: User A1 creates file sharing for file F1 by adding the appropriate EFS certificate for user A2 to file F1. Users A1 and A2 follow these steps to access file F1: User U1 or user U2 makes changes to file F1. In this scenario, EFS metadata is not maintained, and only the current user can decrypt the file. However, you expect that EFS metadata will be maintained and that the user whom you added in step 7 is still there. According to Microsoft, this behavior is by design – currently, you can’t share files in this way. The underlying cause for this behavior is that, if an application opens and saves a file by using the replacefile() API, and if that file was encrypted by using EFS when more than one certificate was present, the resulting file will contain only the certificate of the user who saved the file. I hope you find the information contained in this post clarifying!
