Encryption

Encryption keeps data unreadable to anyone without the keys, even if it is intercepted in transit, copied without authorization, or exfiltrated outright. It does not prevent a breach. It limits the damage, because data an attacker can reach stays unusable without the keys, regardless of which other controls have failed. Two scenarios make this concrete for backup infrastructure: ransomware operators who exfiltrate data before encrypting production and threaten disclosure (“double extortion”), and repositories themselves being targeted for theft, since they typically hold the most complete copy of an organisation’s sensitive data.

End-to-End Encryption

“End-to-end” means encryption covers the whole backup lifecycle.

In-transit. Traffic between agents, proxies, gateways, the backup server and repositories should be unreadable to anyone intercepting it, whether from a compromised network device or a man-in-the-middle position.

  • Veeam Backup & Replication encrypts backup traffic between public networks by default (“public” meaning any range outside RFC1918 and unique local addresses), and network traffic rules can extend that encryption to private networks.
  • Verify encryption in transit on paths between environments (on-premises to cloud, or cloud to cloud) as well as within each environment.
  • Backup infrastructure components use TLS 1.3 with mutual TLS by default, with TLS 1.2 also supported. TLS covers both the management connections between components and the backup data transfer itself, subject to the default above: private-network traffic needs an explicit rule.
  • In-transit encryption complements the isolation of backup traffic (see Micro-Segmentation).

At-rest. Repository data (on-premises disk, hardened repository, tape, object storage or cloud) should be encrypted so that direct access to the underlying medium does not expose usable data, whether through a stolen disk, a misconfigured bucket or an insider with storage-level access.

  • Audit encryption coverage on a schedule across every repository, cloud target and copy, and treat any unencrypted target as drift to be corrected. Detecting that drift is covered in Proactive Validation.

  • Gaps appear as environments grow (new cloud targets, acquisitions, capacity tier extensions), and leaving secondary or offsite copies in the clear “for performance” is the most common one.

    Note: Do not enable Veeam-based at-rest encryption for jobs targeting to deduplication storage appliances as this has a negative effect on the deduplication ratio. Instead, enable encryption at-rest on the deduplication appliance. Be aware that this does not protect from data exfiltration, but only protects the data in case the physical device is stolen.

Configuration Backup Veeam uses built-in operating system mechanisms to protect the configuration database. When enabling Configuration Backups, you should enable Configuration Backup File Encryption to protect Veeam configuration, including all the sensitive data that contains, even when you backup this configuration.

Across every tier and location. Encrypt on-premises, cloud and hybrid repositories consistently. Treating it as optional for certain targets (“we’ll encrypt the offsite copy but not the local one”) creates a predictable weak point.

Use Strong, Current Cryptography

Veeam encrypts backup data with AES-256 in CBC mode, and AES-256 protects everything written to block, tape, cloud and object storage repositories. Where an external KMS is used, the data encryption keys themselves are wrapped with RSA-4096. Post-Quantum Considerations explains why that wrapper is the exposed part.

Veeam does not expose algorithm selection, so you cannot weaken the cipher, and there is no place to substitute custom cryptography. The choices that remain are in the layers around it.

  • TLS and SSH algorithms are inherited from the operating system (Microsoft Crypto API on Windows, OpenSSL on Linux). Hardening the OS cipher configuration and disabling legacy TLS versions is where this decision actually gets made. For Linux components, confirm the host’s SSH ciphers, key-exchange and MAC algorithms are ones Veeam supports; see Supported Cipher Suites and Protocols.
  • FIPS mode constrains the estate to validated algorithms. See the note under Post-Quantum Considerations, since “enable FIPS” and “enable PQC” are two separate decisions.
  • Where encryption is delegated to a deduplication appliance, object storage or an external KMS, the vendor chooses the algorithm and you are responsible for reviewing it. Review all of the above periodically, since what counts as strong evolves.

Manage Keys and Passwords Properly

Encryption is only as strong as the protection around its keys.

  • Inventory where public-key cryptography is used across the backup estate (TLS endpoints, KMS integrations, certificates) and prioritise by data longevity and business impact.
  • Store keys and passwords separately from the systems and data they protect. A key kept alongside what it unlocks, or a password in a spreadsheet, provides little real protection.
  • Beyond small deployments, prefer an external KMIP-compliant KMS.
    • Veeam requests an asymmetric key pair from the KMS, stores only the public key in the configuration database and uses it to wrap the data encryption keys.
    • The private key never leaves the KMS and is only called on at restore.
    • Protect an on-premises KMS with the same rigour as the backup infrastructure itself, since a compromised KMS undermines encryption everywhere it is used.
  • Own key rotation explicitly:
    • Keys never rotated because rotation is cumbersome are exactly the ones most exposed to harvest now, decrypt later.
    • Rotation is the strongest practical argument for a KMS as Veeam does not rotate password-based job keys automatically. Automatic rotation exists only where the external KMS provides it.
    • If you stay on password-based keys, rotation is a manual process that has to be scheduled and owned, or it will not happen.
    • Rotate keys immediately on any sign of compromise or when people with key access change role or leave.
  • Enable Password Loss Protection in case you lose or forget the password or you cannot use KMS keys due to a KMS server failure,
  • Make key recovery a controlled, deliberately difficult process. An easy bypass for administrators is usually an easy bypass for an attacker.
  • Limit how many people and systems can reach the keys, applying least privilege as elsewhere.

What Encryption Does and Does Not Protect

Encryption protects confidentiality only. It does not protect availability: an encrypted backup can still be deleted or corrupted, which is why immutability is needed alongside it. Nor does it stop an attacker holding valid credentials with access to the keys, which is why MFA, least privilege and four-eyes approval matter (see Least Privilege Access).

A lost password, an unreachable KMS, or a wrong key selection is also invisible until restore. Encryption is therefore one of the controls that scheduled recovery verification actually tests: a check confirming a backup is restorable is also confirming it is decryptable, which no amount of reviewing the encryption configuration will tell you. See Continuous Activity Monitoring. Encryption is one essential layer among several.

Post-Quantum Considerations

Encryption decisions must hold for as long as the data must stay confidential, and for archive tiers that can be years or decades. That makes harvest now, decrypt later especially relevant for backup data: an attacker who stores what they take today benefits from a quantum computer later.

The relevant distinction is between symmetric and asymmetric cryptography, and asymmetric cryptography appears both at rest and in transit.

  • Symmetric encryption is the strong part. Grover’s algorithm weakens AES-256 but does not break it, and parallelises poorly, so the practical margin remains substantial. NIST’s proposed transition timeline does not place AES-256 or the SHA-2 and SHA-3 families on the public-key deprecation schedule. Keep AES-256 as the symmetric baseline; it is what makes long retention defensible.
  • Asymmetric key establishment is the weak part, in transit. TLS handshakes and key exchange rely on algorithms that Shor’s algorithm would break outright. Because TLS carries the backup data transfer as well as management connections, that exposes the backup stream itself if the backup data isn’t encrypted at job level. Credentials, session material, metadata and backup data, all worth decrypting years later.
  • Asymmetric key wrapping is the weak part, at rest. Where KMS keys are used, Veeam wraps data encryption keys with RSA-4096. The payload is AES-256, but an attacker holding the backup file and its wrapped DEK only needs to break the wrapper. That makes the wrapper a single point of failure for at-rest confidentiality.
  • Know which asymmetric layers you actually have. Data encryption keys are wrapped with AES-256 on the password-based path and with RSA-4096 on the KMS path, so a KMS adds an asymmetric layer in exchange for the rotation recommended above. Password Loss Protection adds another, since Enterprise Manager keys are also an RSA pair. The KMS trade is still worth taking: lack of rotation is a present, certain risk, while the wrapper is a future, conditional one. Take it knowingly, and count how many asymmetric layers you actually have.

NIST proposes deprecating quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035. Treat that as the planning horizon for every asymmetric layer above. Use the inventory mentioned in the Manage Keys and Passwords Properly for planning and prioritization.

What Veeam Backup & Replication v13.1 Provides

v13.1 introduces hybrid approach: Veeam protects the in-transit traffic with PQC, while retaining FIPS-certified encryption for data at rest

  • Post-quantum encryption is used for the TLS handshake and key exchange, using an algorithm aligned with NIST FIPS 203 (ML-KEM).
  • FIPS-compliant AES continues to handle the data encryption itself.
  • No re-architecture is required. PQC can be adopted without redeploying backup infrastructure.

Note what this does and does not cover. PQC applies to the TLS handshake, which closes the in-transit exposure above. The KMS wrapping layer is not a TLS operation, so data encryption keys remain wrapped with RSA-4096 until your KMS offers post-quantum key types.

NOTE: FIPS and PQC are not yet the same thing. A PQC algorithm is not FIPS-approved for a product until it sits inside the validated boundary of a CMVP-certified module operating in Approved mode. Regulated organisations must treat “enable PQC” and “remain FIPS-validated” as two separate decisions to plan explicitly. On the Veeam Software Appliance, FIPS-certified operation is a supported configuration of the platform, which makes it the practical place to make that decision explicitly.

References

Back to top

Copyright © 2019 - 2026 Solutions Architects, Veeam Software.
Please note that information provided in this guide is not produced or verified by Veeam R&D but is a result of community effort based on the field observations.