What’s the issue?
SQL Server historically supported a PASSWORD and MEDIAPASSWORD option on the BACKUP command, allowing administrators to require a password before a backup file could be restored. Beginning with SQL Server 2012, Microsoft discontinued the ability to create new password protected backups, although existing password protected backup files can still be restored.This finding flags backup files that rely on password protection rather than proper encryption.
Why is this a problem?
The password protection on native SQL Server backups is weak by design and was never intended as real security. Microsoft itself documents that the protection is weak and explicitly recommends against relying on it. The password only blocks restore operations through the RESTORE command interface; the backup file itself is not encrypted, meaning anyone with access to the file can extract data using third party tools or by parsing the file format directly. As a result, password protected backups create a false sense of security: administrators may treat them as protected and store them in less secure locations, when in reality the underlying data is fully exposed.Beyond the security weakness, the feature is deprecated and unavailable for new backups in supported versions, so any reliance on it is also a maintenance and migration liability.
What should you do about this?
Identify backup processes that still use password protection and migrate them to backup encryption, which has been available since SQL Server 2014 and provides genuine cryptographic protection of the backup contents. Backup encryption uses a server certificate or asymmetric key along with a chosen algorithm (AES 128, AES 192, or AES 256, with AES 256 recommended) and is specified using the WITH ENCRYPTION clause on the BACKUP command.Before encrypting backups, create a database master key in the master database, then create a certificate or asymmetric key, and critically, back up the certificate and its private key to a secure offsite location separate from the backup files themselves. Without that certificate backup, encrypted backups cannot be restored, so the certificate management process is as important as the encryption itself.
For existing password protected backup files, restore them using the documented PASSWORD clause, then take fresh encrypted backups going forward and retire the password protected files according to your data retention policy. For environments that need additional protection at the file system or storage level, consider combining backup encryption with secured backup storage locations, file system encryption, or vendor backup tools that integrate with enterprise key management systems.