Why End‑to‑end Encryption Matters Now

When people talk about encryption in backup architectures, they tend to focus on the wrong things. You’ll hear about encryption in flight, encryption at rest, point‑to‑point encryption—terms that sound reassuring but don’t answer the only question that matters: was the data ever unencrypted at any point between production and the final backup storage? If the answer is yes, even briefly, you’ve introduced security risk.  

End-to-end encryption eliminates this architectural weakness. The moment Veeam reads data from production storage, it encrypts it when backup file encryption is turned on. From that point forward, the data never returns to an unencrypted state until Veeam restores it. It doesn’t matter how many data movers, gateways, or networks it passes through. It doesn’t matter how many copies you make. The data is encrypted once, and it stays encrypted, until Veeam restores it. 

That’s the gold standard. Everything else is a compromise on security. This is why end-to-end encryption is required by various regulations, oversight bodies, and insurance contracts.

Defining end-to-end encryption 

 

 

 

 

In an end‑to‑end encryption model, encryption happens immediately at the source. Veeam reads the production data, generates a unique session key for that backup to run, and encrypts the data at the source proxy. That key is never shared with networks, storage devices, Object First, or anyone else in the chain. If someone intercepts the data, all they get is ciphertext. 

This is also why dedupe appliances struggle with end‑to‑end encryption. They require unencrypted data to perform pattern matching. But the moment you allow unencrypted data outside of the source production system, you’ve broken the security model. You’ve created window(s) where attackers can see or manipulate your data. That’s why dedupe is the most flagrant violator of end‑to‑end principles: it requires you to assume nothing bad happens during those unencrypted states. 

That’s not a trust model anyone should rely on today. 

Why end-to-end encryption is essential for ransomware resilient backups 

Ransomware resilient design is about eliminating weak points. Any moment where data is unencrypted, or mutable, are moments an attacker can exploit. If you encrypt here, decrypt there, re‑encrypt somewhere else, you rely on a patchwork of protections and assumptions. There are similar challenges if you allow mutable data.  You’re creating a complex system with multiple points of failure. You’re also creating more keys to manage, more states to track, and more opportunities for misconfiguration and complexity during recovery. 

When data is encrypted end‑to‑end, the security model becomes dramatically simpler. If someone intercepts the data at any point, they only see encrypted objects. If someone compromises storage or bucket credentials, they can read the bucket—but all they’ll ever see is encrypted data. If someone breaches an intermediate server or gateway, they still can’t decrypt anything. Encryption never stops protecting you. 

This is the same logic behind our principle of Zero Time to Immutability. You want the data to be immutable the moment it lands on storage and to be encrypted the moment it leaves production. Every gap between those two states expands the risk surfaces. End‑to‑end encryption reduces that surface. 

How end-to-end encryption works between Veeam and Object First 

The lifecycle starts with enabling job encryption in Veeam. That’s the feature that turns on end‑to‑end encryption. When a backup job starts, Veeam generates a new session key—unique for that run—and encrypts the data as it reads it. Even if you back up the exact same data another time, the encrypted output will look completely different because it’s encrypted with a different key. That rotating, non-reuseable key model is important because it prevents pattern analysis and strengthens cryptography. If you kept encrypting the same data with the same key, attackers could start pattern matching. Rotating keys shuts that down. 

Once encrypted, the data travels through the Veeam infrastructure—proxies, gateways, networks—and eventually lands at your backup repository. At no point does anyone other than Veeam have the key. Storage devices don’t have it. The network doesn’t have it. The proxies don’t have it. If someone intercepts the data, all they get is ciphertext. 

When the objects arrive at Object First (or Veeam Data Cloud Vault), we store them exactly as we receive them. We don’t know whether it’s encrypted or unencrypted, and we don’t need to. It doesn’t help us to see unencrypted data, and it doesn’t hurt us to store encrypted data. 

Integrity is preserved through multiple layers. Veeam, prior to encryption, compresses single instances and embeds checksums and metadata into every object, so if anything is tampered with, Veeam knows immediately. Through this Veeam creates a chain of custody of the backup data and copies. We run our own integrity checks and scans as well. And because the data is immutable, attackers can’t modify or delete it even if they gain storage credentials. 

During restoration, our role is intentionally minimal. We don’t rehydrate, decrypt, or transform anything. We simply return the object. Veeam handles decryption, decompression, and rehydration. That separation keeps the encryption boundary clean and matches the ZTDR model of separating backup software from backup storage. 

This model also extends cleanly into the 3-2-1 Backup Rule. When Veeam copies data from primary backup to a SOBR capacity or archive tier or via a copy job, the data remains encrypted with the original session key. It’s never decrypted and re‑encrypted along the way. That’s the beauty of doing it right from the start. 

Encryption and Absolute Immutability: reducing the blast radius of ransomware 

Encryption and Absolute Immutability are hand‑in‑glove parts of data resilience and security. They reinforce each other in a way that fundamentally changes what an attacker can and cannot do inside your backup environment. 

End-to-end encryption ensures that every component between production and backup storage only ever sees encrypted data. Even if someone intercepts it or gains access to the bucket, all they get is ciphertext. And because Veeam rotates keys for every backup session, even identical data never looks the same twice. There’s no pattern to analyze, no foothold to reverse‑engineer. 

Absolute Immutability picks up where encryption leaves off. In Object First, immutability is instantaneous the moment the object is written, thanks to S3 Object Lock. Once that retention is set, no one—not even an administrator—can modify or delete the object.  

Encryption prevents attackers from understanding the data; Absolute Immutability prevents them from altering or destroying it. One protects confidentiality; the other protects integrity and enforces a chain of custody. Together, they shut down the two avenues ransomware actors rely on most: data corruption and data exfiltration. 

This combination is especially important in an Assume Breach mindset. You must assume someone or some rogue software will get elevated credentials. You must assume the bucket will be read. You must assume defenses will fail—that’s why both layers are required. If an attacker compromises storage credentials, Absolute Immutability stops them from modifying or deleting backups. If they try to use the compromise to exfiltrate data, encryption ensures they can’t use anything they steal. They quickly realize it’s a fool’s errand and shift their attention to easier targets. 

The practical outcome is a simple and yet highly effective data protection and security model that dramatically reduces risk. Even in a worst‑case scenario—where your VBR server is gone, storage credentials are compromised, and attackers have full visibility into your storage—you can still recover your entire backup software environment from scratch and resume operations. End‑to‑end encryption ensures the data is unusable except by Veeam. Absolute Immutability ensures the data is intact. And because Veeam maintains the encryption boundary and chain of custody, the restore process remains clean and controlled. 

This is the architecture that keeps organizations resilient during catastrophic events. When encryption and immutability work together, backups stop being another liability and become the most secure and least complex part of your environment.

Common misconfigurations and pitfalls 

Most failures aren’t technical—they’re operational decisions and processes.  

The biggest mistake is simply not enabling encryption everywhere. This adds your backup environment to your data exfiltration threat matrix. With Veeam, you can turn encryption on for backup jobs and receive the benefits of end-to-end encryption; or you can configure encryption at multiple locations, repositories, and storage devices. In the latter, forget or misconfigure any step and you’ve broken the end‑to‑end chain. 

Another common issue is failing to separate backup software from backup storage. If attackers compromise one, they shouldn’t automatically compromise the other. Zero Trust and ZTDR principles apply here. 

The most catastrophic mistake is mismanaging recovery encryption passwords/keys. If you lose the passwords that bootstrap Veeam’s encryption, neither Veeam nor Object First can help you. Those keys must be stored redundantly, physically, and securely. It is a good idea to share and maintain these with several senior staff and not online.  Encrypted configuration backups must be run regularly. This is the cost of end‑to‑end encryption—not the encryption itself, but the operational discipline required to manage it, and to ensure in case of catastrophe, you can re-create your Veeam environment and provide it with the initial encryption passwords to complete the configuration restore. 

The future of encrypted, immutable backup storage 

Ransomware is evolving, and so is encryption. Post-quantum safe encryption migration has begun by Veeam and is architecturally aligned to NIST IR 8547 “Transition to Post-quantum cryptographic standards” report, and the shift toward post-quantum encryption will continue to shape how backup data is protected.  

Looking ahead, the architectural principles that matter most are the same ones that matter today. Create and maintain a secure and simple environment with the following: Zero Trust Data Resilience principles, an Assume Breach mindset, separation of backup software from storage, Absolute Immutability, the 3‑2‑1 Backup Rule, and regular testing. These are the practices that ensure you can recover your data no matter what happens.  

The broader trend is that organizations must secure all data, not just production data. Backups are the last line of defense—and increasingly the first attack targets. End‑to‑end encryption, combined with immutability, are key parts of how you stay ahead of ransomware.