A WordPress backup is one of the largest exfiltration targets on any site. A full backup contains the database (which holds user accounts, password hashes, content, and any sensitive plugin data), the uploads directory (which holds media that may include personally identifying information), and the configuration (which may include API keys depending on how they were stored). A backup that is stolen is, in practical effect, the site itself stolen. This is a different threat model from the more familiar "the site is compromised" threat, and it is the threat model that backup encryption exists to address.
Most WordPress backup plugins support encryption in some form. The quality of the support varies. Some plugins encrypt backups before they leave the server. Others encrypt only the connection used to upload the backup to a remote storage location, leaving the resulting backup decrypted at rest in the destination. A few plugins claim encryption support but in practice store the encryption key alongside the backup, which is the security equivalent of locking a door and taping the key to it. This piece walks through what backup encryption actually needs to do, what the major plugins actually do, where the key management decisions sit, and how the restore workflow works for encrypted backups. The goal is to give site operators a working playbook for the question "is my backup actually safe if it leaves my control?"
The threat model that backup encryption addresses
The threat model for backup security is different from the threat model for site security in three important ways.
The first difference is that backups are not active code, so the protections that work for active code (web application firewalls, runtime hardening, authentication boundaries) do not apply. A backup is a passive blob. Its security comes from controlling who can read it.
The second difference is that backups are frequently outside the operational perimeter. A backup is typically transmitted off the production server (to an offsite location, a cloud bucket, a developer’s laptop for staging restore) and may sit there for weeks, months, or years. Each location where a backup sits is a potential exposure. The perimeter that protects the live site does not extend to all of those locations.
The third difference is that backups have a long lifetime relative to a session or a database connection. A site key rotation that is routine for the live site (rotating an API key, a database password, an admin user password) does not propagate to existing backups. A backup taken six months ago still has the database state from six months ago, including credentials that have since been rotated.
These three differences together mean that backup security is primarily about controlling who can read a backup throughout its full lifetime, including in places the operations team does not directly control. The mechanism for this is encryption at rest, with key management that keeps the keys separate from the backups they encrypt.
What "backup encryption" actually means
A WordPress backup plugin that says it supports encryption can mean any of several things, in declining order of actual security value:
The strongest meaning is "the backup is encrypted with a key that is held outside the WordPress install, the encrypted backup can be stored anywhere without leaking content, and the only way to decrypt it is to access the key from its separate storage." This is end-to-end backup encryption and it is what backup security should mean.
A weaker meaning is "the backup is encrypted with a password set by the site administrator, the password is required to decrypt, and the encrypted backup can be stored anywhere." This is password-based backup encryption. It is meaningfully secure if the password is strong, is not stored anywhere alongside the backup, and is recoverable through some out-of-band channel. It is meaningfully less secure if the password is weak, is stored in the WordPress database (where any database leak would expose it), or is forgotten and unrecoverable.
A weaker meaning still is "the backup is transmitted over a TLS connection to the remote storage, so it is encrypted in transit." This is transport encryption. It protects against passive network eavesdropping but does nothing for the backup once it reaches the destination. A backup that is encrypted in transit and decrypted at rest in S3 is no more secure than the S3 bucket policies make it.
The weakest meaning, sometimes called "encryption" by marketing-light backup plugins, is "the backup file is obfuscated with a recoverable algorithm that prevents casual inspection but is not cryptographically secure." This is not encryption. Sites whose backup plugin claims encryption support should check whether the encryption is actually a recognized algorithm (AES-256 in a recognized mode like GCM) with a key derivation function (typically PBKDF2 or Argon2id) rather than an obfuscation scheme.
When evaluating a backup plugin’s encryption support, the question to ask is which of the four meanings applies. The marketing copy usually does not distinguish, but the plugin documentation typically does if you read carefully.
Plugin-by-plugin support in 2026
The major WordPress backup plugins have different support levels for encryption. The summary as of mid-2026:
UpdraftPlus, the most-installed backup plugin, supports password-based encryption for both the database and file backups. The encryption is AES-256 with PBKDF2 key derivation. The password is set per-backup-destination and is stored in the WordPress database. This is a meaningful improvement over no encryption but inherits the limitation that a database compromise exposes the encryption password.
BackupBuddy supports password-based encryption with a similar architecture: AES-256, password-set-per-destination, password stored in the database. BackupBuddy’s pro tier additionally supports an "encryption key file" mode where the encryption key is held outside the database, which is a meaningful security improvement for sites that can manage the key file separately.
BlogVault uses a different model. The encryption is end-to-end with a key held in the BlogVault service. Backups are encrypted on the WordPress server before transmission and decrypted only when explicitly restored. The model has the security advantage that the encryption key is not in the WordPress database, but it has the dependency cost that BlogVault is in the trust chain for backup access. This is the right tradeoff for many sites and the wrong tradeoff for sites whose threat model includes BlogVault itself as an untrusted party.
Jetpack Backup (formerly VaultPress) uses the same general model as BlogVault: end-to-end encryption with the key held in Jetpack’s service. The trust chain through Jetpack is meaningfully shorter for sites already using other Jetpack features, but it is a trust chain nonetheless.
ManageWP supports encryption through its premium "secure backup" feature, with the key held in the ManageWP service. The architecture is similar to BlogVault and Jetpack Backup.
BackWPup supports password-based encryption in the pro tier. The free tier does not support encryption.
WP Time Capsule supports end-to-end encryption with the key held by the site administrator, similar to the BackupBuddy pro tier mode. This is the most operationally flexible model: the key is not in the WordPress database and not in a third-party service.
For sites running on managed hosts, the host’s native backup features should also be considered. Pantheon, WP Engine, Kinsta, and similar managed hosts take backups as part of the hosting service. These backups are encrypted at rest in the host’s storage with the host’s keys. The host has the ability to restore from these backups but the host’s storage is not accessible to anyone else without the host’s authorization. The trust model is "trust the host with the keys" which is the same trust model that already applies to the running site, so it does not extend the trust chain.
The key management decision
The single most important decision in backup security is where the encryption key lives. There are five common options, with declining operational convenience and increasing security strength.
Option 1: Key in the WordPress database. This is the default for most plugin-based password encryption. The convenience is high (the plugin can encrypt and decrypt without external dependencies). The security weakness is that a database compromise exposes the encryption key, which means the backups are no better protected than the database itself.
Option 2: Key in a WordPress configuration file (wp-config.php). The convenience is lower (the key must be deployed alongside the code) but the security is meaningfully better (a database compromise does not expose the key). This is the right pattern for sites whose configuration is managed through a deployment process rather than through the WordPress admin.
Option 3: Key in environment variables. The convenience is similar to wp-config.php with the additional benefit that environment variables are generally not committed to version control. This pattern fits naturally with the credential-resolution waterfall pattern that the WordPress 7.0 Connectors API and Pantheon Secrets use.
Option 4: Key in a managed secrets backend (Pantheon Secrets, WP Engine secrets manager, HashiCorp Vault, AWS Secrets Manager). The convenience is comparable to environment variables with the additional benefit of centralized key management, rotation support, and audit logging. This is the right pattern for organizations with multiple sites or multiple environments where centralized key management has operational value.
Option 5: Key in the operator’s offline storage (a password manager, an encrypted file on a removable drive, a hardware security module). The convenience is lowest (the operator must produce the key for every restore) but the security is strongest (the key is never present in any system the attacker can compromise). This pattern is appropriate for sites with the highest sensitivity, like sites handling regulated data or sites whose threat model includes sophisticated attackers.
The right choice depends on the threat model and the operational tolerance for friction. The honest reality is that most WordPress sites use Option 1 (key in the database) by default and that this is meaningfully better than no encryption but meaningfully worse than the other options. Sites considering their backup security should at minimum move from Option 1 to Option 2 or 3, which the major plugins support without requiring a different plugin.
The transmission and storage path
Encryption-in-transit and encryption-at-rest are different protections that combine in a backup workflow. A typical workflow has three stages: the backup is created on the WordPress server, the backup is transmitted to the storage destination, and the backup is stored at the destination.
The right encryption posture is: the backup is encrypted on the WordPress server before any transmission, the encrypted backup is transmitted over a TLS connection, and the encrypted backup is stored at the destination. The destination’s own at-rest encryption (e.g., S3’s server-side encryption with S3-managed keys) is then a defense-in-depth layer on top of the plugin’s encryption, not a substitute for it.
The wrong posture, which several backup plugins quietly default to, is: the backup is transmitted in cleartext over TLS, and the destination’s at-rest encryption is the only encryption applied. This is meaningfully weaker because the backup is decrypted at every layer where the destination’s keys are accessible. An S3 bucket with server-side encryption protects against an attacker stealing the underlying disks but does not protect against an attacker with access to the AWS account.
For sites uploading backups to S3, B2, Wasabi, Google Cloud Storage, or similar object storage, the practical posture is to use the plugin’s own encryption (so the backup is encrypted before it leaves the WordPress server) and to also enable the storage destination’s server-side encryption (as defense in depth) and to use restrictive bucket policies that prevent public access (as the third layer). The combination is harder to compromise than any single layer.
A consideration for sites uploading to multiple destinations is that the encryption key must be available at every destination that may need to restore from the backup. For sites with a single restore-source destination, this is automatic. For sites with multiple destinations (e.g., primary in S3, secondary in B2, tertiary on a developer’s laptop for staging restores), the encryption key needs to be available to whoever is operating the restore at each location. This is the operational reason that key management is often the hardest part of backup security.
The restore workflow
A backup that cannot be restored is not a backup. The restore workflow for encrypted backups has one specific failure mode that has bitten enough teams that it deserves explicit mention: the password-recovery problem.
The password-recovery problem is that the encryption password for the backup is stored in the WordPress install that the backup is meant to restore. When the production install is compromised, lost, or otherwise unavailable, the encryption password is also unavailable, which means the backup cannot be decrypted to restore. This is the inverse of the security benefit of encryption: the same separation that protects the backup from unauthorized access also blocks legitimate access when the WordPress install is gone.
The mitigation is to ensure that the encryption password is available outside the WordPress install in a recoverable form. The options:
- Store the password in a password manager (1Password, Bitwarden, LastPass) that is accessible to the operations team independent of the WordPress install.
- Store the password in a managed secrets backend (Pantheon Secrets, AWS Secrets Manager) that is similarly accessible.
- Print the password and store a physical copy in a secure location (a safe, a safety deposit box).
- Document the password in the disaster-recovery runbook that the team would consult during a major incident.
The wrong mitigation is to not encrypt the backup at all. Several teams have ended up with unencrypted backups specifically because they were worried about the password-recovery problem. The right mitigation is to encrypt and to ensure password availability, not to skip encryption.
For sites using the plugin-managed encryption with the key in a managed service (BlogVault, Jetpack Backup, ManageWP), the password-recovery problem is the third-party service’s responsibility. Restore works as long as the service is operating and the site can authenticate to it. This is one of the reasons the third-party-managed backup model is attractive for sites without strong key management practices.
Retention and rotation
A backup security posture that is correct at the moment of backup creation can degrade over time if retention and rotation are not managed. Two specific concerns:
Long-retained backups outlast credential rotations. A backup taken six months ago has the database state from six months ago, including any admin passwords, API keys, or session tokens that were valid at that time. If those credentials have been rotated, the rotated credentials are also valid in the old backup. A restore from the old backup would either bring back stale credentials (a security issue if the rotation was because of a compromise) or fail (a usability issue if the rotation was routine). The mitigation is to limit the retention of backups to a meaningful window and to plan for credential rotation as part of restore.
Long-retained backups also outlast encryption-algorithm changes. AES-256 is appropriate for backups taken in 2026, and is expected to remain appropriate for the foreseeable future, but the same was once said of MD5 and SHA-1. Backups taken with weaker historical algorithms are worth re-encrypting with stronger algorithms periodically. For most sites the practical implication is that backups older than two or three years should either be re-encrypted or destroyed rather than left in their original form indefinitely.
The retention policy should also consider that backups are subject to data-protection regulations. A site subject to GDPR holds personal data in its backups for as long as the backups are retained. The retention policy should consider GDPR’s data-minimization principle and should not retain backups longer than the operational need justifies.
Validation testing
A backup that has never been restored has never been validated. The single best practice for backup security is to do a periodic restore drill: take a recent backup, restore it to a staging environment, confirm that the site comes up and that the data is intact. The drill catches three classes of issues that pure backup integrity checks miss.
The first class is encryption issues. A backup that was encrypted with a password that the operations team no longer has is undetectable from the backup file alone. The drill catches this because the restore will fail at the decryption step.
The second class is data-integrity issues. A backup that was taken during a transaction in flight may have an inconsistent database state. The drill catches this because the restored site will exhibit specific symptoms (orphaned rows, missing relationships, page errors).
The third class is operational issues. A backup that was supposed to include the uploads directory but did not, or a backup that excluded a critical wp-config.php override, will produce a restored site that runs but behaves differently from the original. The drill catches these by comparing the restored site to the production site.
A reasonable drill cadence is monthly for high-criticality sites, quarterly for typical sites, and annually for the lowest-criticality sites. Drills should rotate among backups (not always testing the most recent backup) and among destinations (not always testing the primary backup destination).
Frequently asked questions
Should I encrypt my WordPress backups even if my host already encrypts at rest? Yes, if the backup leaves the host’s storage. The host’s at-rest encryption protects against threats inside the host’s storage layer. It does not protect against the backup being downloaded to a developer’s laptop, uploaded to a third-party service, or otherwise leaving the host’s control.
Is a password-protected ZIP file sufficient encryption for a backup? It depends on the ZIP encryption algorithm. ZIP supports two encryption modes. The older "ZipCrypto" mode is cryptographically weak and should not be considered encryption. The newer "AES" mode (used by WinZip’s encryption and by 7-Zip) is meaningful encryption if the password is strong. The practical guidance is to confirm which algorithm the backup tool uses before relying on ZIP-based encryption.
Can I encrypt my backup at the storage layer instead of in the plugin? You can layer storage-level encryption on top of plugin-level encryption (defense in depth) but storage-level encryption alone is not as strong as plugin-level encryption. The storage-level encryption key is typically held by the storage provider, which means anyone with access to that account has access to the decrypted backup.
What happens to my encryption password if my backup plugin is uninstalled? It depends on the plugin. Some plugins store the password in plugin-specific tables that are removed on uninstall, which would lock the user out of their own backups. Other plugins store the password in the WordPress options table, which persists across uninstalls. Before uninstalling a backup plugin, confirm where the password is stored and back it up to a safe location.
Should I encrypt my staging environment backups the same way as production? Yes. Staging environments often contain copies of production data, which means a staging backup is as sensitive as a production backup. The encryption and key management posture for staging should match production.
Does encrypting backups affect their compressibility? Yes. Encryption produces output that is statistically indistinguishable from random, which is incompressible. The practical guidance is to compress the backup before encrypting it (which is what most backup plugins do automatically) rather than encrypting first and trying to compress after.
What encryption algorithm should I look for in a backup plugin? AES-256 in a recognized mode (GCM, CBC, or CTR) with PBKDF2 or Argon2id key derivation. These are the current best-practice algorithms for password-based encryption. Earlier algorithms (3DES, RC4, MD5 for key derivation) are not appropriate for new use.
How does the WordPress 7.0 Connectors API relate to backup security? The Connectors API uses the same credential-resolution waterfall (env vars, constants, secrets backends, database) that the right backup-encryption key management pattern uses. A site that has the Connectors API configured to read keys from Pantheon Secrets has the same infrastructure available for storing backup encryption keys, and the configuration patterns transfer.
