We have removed support for Transport Layer Security (TLS) 1.0 and 1.1, as they are no longer used in any way by the File Protection service.

In rare cases, a missing or corrupted Windows Registry value could cause File Protection to prompt the user for a password, but not accept a correct entry. The problem has been resolved.

A customer reported a security alert related to Log4j. It was a false alarm and there was no vulnerability, but since we were already examining our logging platform, we elected to exchange log4net for NLog, which we already use elsewhere in the product. This will not result in any changes to your File Protection experience.

In a recent release, we added code that streamlines backup scans. Under rare circumstances, consecutive scans that completed very quickly resulted in the creation of two scan files with the same timestamp-based name. The issue has been resolved by switching to an increment-based naming convention.

An startup process caused an extended logging setting to turn on, which is expected behavior. The process did not, however, turn this setting off upon completion, resulting in excessive content in the disk space check log. The issue has been resolved.