Most security conversations about quantum computing start the same way. Someone asks when a quantum computer will break today’s encryption, and the room splits into two camps. One camp says it is years away, so it is not urgent. The other camp says it will arrive suddenly and everything will be exposed.
Both camps miss the real point.
Post-quantum cryptography (PQC) is not about preparing for a quantum computer accessing your data center tomorrow. It is about protecting long-lived data from adversaries who can capture it today and wait for the technology to decrypt it later.
If an attacker can access encrypted information today and store it, they do not need quantum computing right now. They only need it later. That is the logic behind the “harvest now, decrypt later” cyberattack strategy, and it changes the timeline from a future problem into a present-day planning decision.
NIST makes this risk explicit, and that is why PQC has moved from theory to standardization.
The Uncomfortable Truth About Backup Data
Backup is a promise you make to your future self. When everything goes wrong, backup is the system you trust to restore operations, validate recovery points, and return the business to a known-good state. It contains the most complete version of your business, often spanning years of history, and was retained specifically because it remains valuable.
That is why quantum readiness and backup belong in the same sentence.
When people ask whether backup data is secure now and in the future, the most useful answer is not a yes or no. Rather, the answer should be separated into three parts, focusing on:
- Data at rest, meaning the confidentiality of stored backup data.
- Data in flight, meaning the security of the transport paths that move data between components and locations.
- Key custody and governance, meaning who can access encryption keys, who can change settings, and whether the security design survives a real incident.
Separating the problem this way brings clarity quickly.
What Is Secure Today and Why?
For data at rest, modern backup encryption relies on strong symmetric cryptography such as AES. This matters because the quantum threat is asymmetric. Quantum is most disruptive to public key algorithms used for key exchange and digital signatures. Symmetric encryption is not in the same category of breakability.
In practical terms, if you are encrypting backup data at rest using strong symmetric encryption and you are managing keys correctly, you are doing one of the most important things you can do for long-lived confidentiality today.
For most organizations, the bigger near-term risks are not advanced cryptographic attacks. They are everyday operational failures:
- Keys stored where attackers can reach them.
- Backup infrastructure that is not isolated from the production blast radius.
- Permissions that allow ransomware to encrypt or delete repositories.
- Recovery plans that have never been tested under stress.
Quantum readiness should not distract from these realities. It should motivate better discipline because the transition ahead will not be kind to environments that already struggle with security basics.
Where PQC Matters First
If quantum changes one thing immediately, it is how we think about data in transit. For many systems, the most sensitive moment is when they establish a secure connection and exchange keys. That is where traditional public key cryptography has been used for decades, and that is where “harvest now, decrypt later” becomes a real concern.
Even if the data ends up encrypted at rest, intercepting traffic can still be valuable to an adversary if it includes credentials, session material, metadata, or anything that can be decrypted later once quantum capability matures.
That is why the industry is moving to hybrid approaches that combine classical cryptography with post-quantum techniques for key establishment. It is a pragmatic way to reduce future risk without pretending the world can change overnight.
The Standards Are Real Now
A key inflection point happened in 2024, when NIST finalized the first PQC standards as the Federal Information Processing Standards, specifically FIPS 203, FIPS 204, and FIPS 205. That is the moment PQC stopped being a research project and became a migration program.
This does not mean every product in your environment can adopt PQC tomorrow. It means the direction and algorithms are set, and the planning window is open.
Why Compliance Makes This Harder Than It Looks
If you work in regulated industries or in environments where FIPS validation is required, there is an additional reality that many gloss over.
You cannot simply say you are using strong cryptography. In a FIPS context, you must be able to tie your claim to a specific, validated cryptographic module. That is the purpose of the NIST Cryptographic Module Validation Program, or CMVP.
Here is why that matters for PQC: Even if PQC algorithms exist in a crypto library, they are not considered FIPS-approved for your product until they are part of the validated boundary of a CMVP-certified module operating in Approved mode. That certification cycle takes time, and it is one of the reasons PQC adoption must be staged for customers who need both innovation and compliance.
For regulated organizations, PQC readiness is not just an algorithm decision. It is also a validation, governance, and adoption-planning decision.
That is why we view PQC as additive, not disruptive. Customers can maintain their required FIPS-posture and introduce PQC where it fits their risk model and operational constraints, rather than being forced into a one-size-fits-all transition.
Where Veeam Is Today and Where We Are Headed
Veeam has long supported customers that require FIPS-aligned deployments. That posture is tied to validated cryptographic modules, such as certificates #4872 or #5156, that can be independently verified through NIST.
This matters because it anchors trust in something concrete. You are not taking a vendor’s word for it. You can validate it externally.
At the same time, the PQC ecosystem is still maturing. We believe the right path is to adopt PQC using upstream standard implementations rather than proprietary crypto. That keeps us aligned with NIST standards and reduces the long-term risk of vendor-specific cryptographic design.
This is also not a new direction for Veeam. We have already been working with partners in the cyber recovery ecosystem to strengthen quantum readiness, including our collaboration with Entrust.
The Veeam and Entrust work reinforces an important point: PQC is most valuable when it is integrated into real operational workflows, especially around recovery, key custody, and resilience, and not treated as a standalone cryptography exercise.
For example, Veeam and Entrust have publicly outlined how we are strengthening cyber recovery with PQC, demonstrating that our approach is grounded in practical implementation, not just future roadmap language.
What Veeam Backup & Replication 13.1 Represents in the Journey
Veeam Backup & Replication 13.1 is not a marketing checkbox, and it is also not a science experiment. It is a deliberate step toward quantum readiness for the environments customers run, where security outcomes must be balanced with interoperability, operational continuity, and regulatory compliance.
Veeam Backup & Replication 13.1 is designed to introduce hybrid PQC on key transport paths to help reduce exposure to “harvest now, decrypt later” risks for data in transit, while keeping the platform stable and manageable.
Just as importantly, PQC adoption is not forced. Customers who require strict compliance can continue to operate in FIPS-approved mode, which remains part of our design point. PQC is introduced as an option for customers who want to start reducing quantum-driven transport risk now, while the broader ecosystem of validated modules continues to mature.
How Veeam Is Approaching PQC Adoption
Veeam’s approach is built around crypto agility, standards alignment, and operational practicality. Customers should not have to rebuild their backup architecture just to modernize cryptography. The platform must be able to evolve as standards mature, validated cryptographic modules become available, and customer requirements change.
That is why Veeam is focused on standard, widely-reviewed implementations rather than proprietary cryptography. PQC is still moving quickly, and long-term trust comes from transparency, review, and alignment with NIST direction.
We also take compliance realities seriously. Many organizations cannot simply enable an algorithm in a library and call it compliant. The industry is still working through validated module scope for PQC in FIPS-approved mode, so adoption must be staged, explicit, and practical.
In practice, that means we design so customers are not forced into an either-or decision. If you need FIPS-approved mode, you keep it. If you want to begin adopting PQC on selected paths to reduce quantum exposure, you can do that intentionally, with clear understanding of the operational and compliance context.
Veeam Backup & Replication 13.1 reflects that discipline through a focused implementation across contained transport components and backed by real-world validation. Our goal is to help customers adopt stronger protections without unnecessary operational disruption.
Finally, we are being honest about the tradeoffs. PQC generally costs more in CPU, memory, and sometimes latency, because many PQC schemes use larger keys and handshake messages than classic algorithms. That is not a reason to avoid PQC, but it is absolutely a reason to introduce it thoughtfully, measure it, and apply it where it delivers the most risk reduction first.
What Customers Can Do Now
A common question from customers is, “Where do we start if parts of the technology ecosystem are still moving toward PQC readiness?” The answer is to focus on actions that reduce risk today and make future PQC adoption easier as the standards, products, and validated cryptographic modules mature. These proactive steps can include:
- Encrypting backup data at rest with strong symmetric encryption and treat keys as crown jewels.
- Reducing exposure of management planes and transport paths through segmentation and least privilege.
- Using immutability and hardened repository patterns so ransomware cannot rewrite history.
- Running the recovery drill on a Tuesday before the incident chooses the timing for you. Validate that the business can recover cleanly, quickly, and confidently under realistic conditions.
- Taking inventory around where public key cryptography is used across your environment, then prioritizing migration based on data longevity and business impact.
- Pushing vendors for crypto agility and clear statements on standards alignment and validation roadmaps.
These steps matter, whether quantum arrives in eight years or eighteen. They reduce today’s attack surface and prepare you for tomorrow’s cryptographic transition.
Closing Thought: Quantum Readiness Is a Discipline
Quantum readiness is not a single switch you flip. It is a discipline you build.
Your backups are not just data storage. They are your last line of defense and your most durable record of truth. That makes them an obvious place to start thinking about post-quantum protections, not because you are afraid of the future, but because you intend to be ready for it.
From our perspective as Field CTOs, the goal is simple. Keep your data safe today, recoverable tomorrow, and evolve cryptography in a way that respects both engineering reality and compliance truth.
If you’d like to learn more about Veeam’s preparations for the quantum future, check out this blog post.
