Key Takeaways

• ResOps is not a technology product. It’s a cross-functional operating discipline that helps drive organizational cyber resilience.
• It complements backup, disaster recovery, cybersecurity, business continuity, and incident response by aligning these functions around end-to-end recovery outcomes.
• ResOps focuses on critical services and business-defined impact tolerances, rather than isolated infrastructure components.
• It relies on the continuous production of evidence, including tested recovery results, service resilience indicators, and an owned backlog of gaps.
• ResOps is a continuous process. Neither making a plan nor running a successful one-time exercise are enough to establish lasting recovery capability.

The New Resilience Challenge

Most organizations invest in cybersecurity, backup, disaster recovery, and business continuity. Yet many executives still face three critical questions: Can we recover? How long will recovery take? And can we prove it?

Part of the challenge is that responsibility for resilience is spread across teams that often operate in silos. Security manages threats. IT maintains systems. Backup and disaster recovery teams restore data and infrastructure. Business continuity teams focus on keeping the organization running. Each plays an important role, but responsibility for recovery can remain fragmented.

ResOps brings these functions together around shared priorities, recovery goals, and evidence. The result is a more practical way to approach resilience: know what matters most, understand what it takes to recover it, test whether recovery works, and act on the gaps you find.

What Is ResOps?

ResOps is the operational discipline that brings security, infrastructure, IT operations, business continuity, and business owners together around critical services, resilient design, and continuous validation. Put simply, ResOps helps teams prepare for disruption, recover critical services within business-defined impact tolerances, and demonstrate in an evidence-based way that recovery works.

Four characteristics define ResOps. It is:

1. Cross-functional by design. ResOps connects distributed responsibilities through a shared operating model, named ownership, and executive governance.
2. Centered on critical services. It prioritizes the services the organization must restore to deliver core value, serve customers, and generate revenue; as well as helping meet urgent legal, regulatory, safety, and mission obligations.
3. Continuously validated. Resilience is a posture that teams must exercise and improve – not a state established by an annual test.
4. Measured through evidence. ResOps produces a resilience posture score (RPS): a per-service, evidence-backed score that measures how recoverable a single critical service is based on validation results, dependency health, and clean-recovery confidence.

What Isn’t ResOps?

It’s not a product category.

No platform can create ResOps on its own. Data protection, cyber recovery, automation, observability, and testing technologies can support the discipline, but ResOps is organizational. It depends on governance, shared accountability, business priorities, operational practices, and a common standard of evidence.

It’s not a replacement for backup and recovery or disaster recovery.

ResOps does not replace strong backup and disaster recovery capabilities: it depends on them. Backup establishes whether recoverable copies exist. Disaster recovery provides the procedures and technical capabilities to help restore systems and infrastructure.

But then ResOps asks a broader question: Can the critical service return completely, cleanly, and within tolerance, including its identities, applications, data, infrastructure, cloud services, third parties, people, and decision paths?

It’s not another name for business continuity or incident response.

Business continuity defines how the business operates through disruption. Incident response detects, contains, and manages the event. ResOps connects those disciplines to the recovery outcome. It creates an operating rhythm for teams to agree on what matters, validate recovery under realistic conditions, measure results, and address the gaps that testing reveals.

It’s not a compliance exercise or one-time project.

A mature ResOps program can help generate evidence for boards, regulators, insurers, customers, and auditors. But documentation is a byproduct, not the objective. The objective is demonstrated recoverability.

And because systems, dependencies, threats, and business priorities keep changing, ResOps is never “finished.” It operates continuously, much like financial planning or security operations.

What Changes With ResOps?

ResOps shifts the focus from whether individual systems and processes are working to whether the critical service as a whole can recover. That changes the questions leaders can ask.

A successful backup is important. So is having a recovery plan. But neither one tells you whether a critical service can actually be restored when you need it. ResOps looks at the bigger picture:

• Did we recover from a verified clean recovery point?
• How long did it take?
• Did we recover within the limits the business set?
• And what still needs attention?

That’s why ResOps matters. It gives organizations a way to move beyond assumptions of resilience to programmatic, reliable demonstrations of their ability to recover. And they do it with continuous production of evidence and traceability. So when disruption happens, the question isn’t whether every team did its part or who failed at which task. It’s whether the business can restore the critical services its customers depend on.

Learn More

Commvault has published ResOps: An Executive Guide to give CISOs, CIOs, IT, security, resilience, and risk leaders a practical framework for implementing ResOps in their organizations.

Leaders will learn how to identify the services that matter most, validate recovery readiness with real evidence, and continuously test resilience. As a result, organizations can establish a single operating model that unites security, infrastructure, IT operations, and business leaders around evidence-based recoverability.

Get the guide here. 

FAQs

Q: Is ResOps simply a new name for disaster recovery?

A: No. Disaster recovery is an essential part of ResOps, but ResOps looks at the entire critical service – including technical, third-party, human, and decision dependencies – and whether it can recover within a business-defined impact tolerance.

Q: Does ResOps require buying a new platform?

A: No. Technology can support mapping, testing, recovery, and evidence collection, but ResOps starts with ownership, governance, business priorities, and operating practices.

Q: Who owns ResOps?

A: ResOps needs a named leader with cross-functional authority and executive sponsorship. Individual service owners remain accountable for their services, while security, IT, business continuity, and business teams contribute to the shared recovery outcome.

Q: How is ResOps success measured?

A: Success comes from current evidence that critical services can recover cleanly within their defined impact tolerances – not simply from completing a plan or running a successful backup job.

A resilience posture score (RPS) is also a useful measurement tool. As a per-service, evidence-backed score, RPS helps demonstrate how recoverable a single critical service is based on validation results, dependency health, and clean-recovery confidence.

Q: How do organizations get started with ResOps?

A: Start by identifying the critical services the business depends on, who owns them, what they depend on, and how quickly they need to recover. From there, teams can validate recovery, identify gaps, and prioritize the work needed to strengthen resilience.

Michael Thelander is Senior Director of Product Marketing at Commvault.

Key Takeaways

• Resilience depends on how quickly and confidently the business can recover – not solely on keeping every threat out.
• Turn recovery plans into evidence – tested results are more credible to boards, regulators, and insurers than targets or assumptions.
• Make ResOps a shared operating model for security, infrastructure, business continuity, and service owners.
• Measure what matters: Teams should know whether critical services can be restored, how long recovery actually takes, and whether they can prove it.
• Select one or two critical services, define successful recovery, run an honest exercise, and document the results.
• Twenty years in security leadership teaches you one thing early: The attack you stopped never makes the board meeting. The one you didn’t is the only story anyone remembers. Somewhere along the way I stopped measuring my team by how many hits we absorbed alone and started also measuring us by how fast we got back up.
• That’s the reason I want every CISO, CIO, and board member I know to read this new book, ResOps: An Executive Guide. Commvault sponsored it, but I’d be recommending it either way.

The Wall Was Never the Whole Plan

For most of my career, the job was building higher walls. Better detection, tighter controls, faster response. That work still matters, and it always will. But a wall only answers one question, and it’s not the one your board is asking anymore.

Last September, ransomware forced Jaguar Land Rover to halt global manufacturing. Assembly lines stopped. Supply chains froze. The UK’s Cyber Monitoring Centre put the cost to the broader economy at roughly £1.9 billion, and JLR posted its lowest monthly production output in 73 years. JLR had defenses. What the incident tested wasn’t whether the wall held. It was whether the business could get back up once it didn’t.

I’ve said this before and I’ll keep saying it: Disruption isn’t an if, it’s a when. The CISOs who sleep at night aren’t those who believe they can keep everything out; they’re those who’ve practiced getting back up so many times that the practice itself is the confidence.

Three Questions I Ask My Own Team

The book organizes the whole problem into three questions, and I’ve started opening every resilience review with them:

• If we were hit tonight, could we recover?
• How long would it actually take?
• Can we prove it, with evidence, to the board?

Most organizations answer the first two with a plan and the third with silence. That silence is the resilience gap, and it’s bigger and more expensive than most executives realize.

Proof, Not Promises

Here’s a distinction the book makes better than I’ve heard it made anywhere else: A recovery time objective is a target. It tells you what you’re aiming for – but it doesn’t tell you whether you’ll hit it.

Compare “we believe we can recover the payments service in four hours” to “we restored it in 3.2 hours last quarter, from a verified clean recovery point, against a four-hour tolerance.” The first sentence is a plan. The second is evidence. Only one of them holds up when your board, your regulator, or your cyber insurer starts asking harder questions, which they will.

We calls this discipline ResOps, short for resilience operations. It’s not a product you buy or a binder you file. It’s an operating model that connects security, infrastructure, business continuity, and the business owners who depend on these services, all working from the same evidence instead of separate plans.

The Part That Should Worry Every CISO

The book also names something I’ve felt for a while and finally have language for: the AI paradox. The same AI capability helping us find vulnerabilities faster is helping attackers close the gap between discovery and exploitation just as fast, maybe faster. Finding more problems doesn’t make you safer if you can’t recover from the ones that get through. Detection speed was never the finish line. Recovery capability is.

Start with One Service

None of this requires boiling the ocean, and I’d be lying if I said my own team got it right on the first try. The book lays out a 90-day path: Pick one or two of your most critical services, define what “recovered” really means for each, run one honest recovery exercise, and produce your first piece of real evidence. That’s a project any team can start this quarter, mine included.

Proof over promises. Readiness over perfection. That’s the standard I hold my team to, and it’s the standard this book gives you a real path toward.

Get your copy of ResOps: An Executive Guide here.

FAQs

Q: What is ResOps?

A: ResOps, short for resilience operations, is an operating model that connects security, infrastructure, business continuity, and service owners around shared, evidence-based recovery practices.

Q: How is ResOps different from traditional disaster recovery?

A: Traditional disaster recovery often centers on plans and technical targets. ResOps emphasizes continuous validation, cross-functional ownership, and measurable proof that critical services can be restored within business tolerances.

Q: Why is recovery evidence important?

A: Recovery evidence shows what an organization has actually tested and achieved. It helps give boards, regulators, insurers, and business leaders greater confidence than plans or recovery targets alone.

Q: What should organizations measure in a ResOps program?

A: Organizations should measure whether critical services can be restored, how long recovery actually takes, whether recovery points are clean and verified, and whether results meet defined business tolerances.

Q: Who should be involved in ResOps?

A: ResOps should bring together security, infrastructure, business continuity, application and service owners, and executive stakeholders so that recovery priorities and evidence reflect business needs.

Q: How can an organization get started with ResOps?

A: Start with one or two critical services. Define what successful recovery means, run an honest recovery exercise, document the results, and use that evidence to improve the next test.

Bill O’Connell is Chief Security Officer at Commvault.

Key Takeaways 

• The updated federal advisory documents new Medusa tactics, techniques, and more than 500 victims across critical infrastructure sectors. 
• Attackers target more than production data; they also disrupt backups, identity, virtualization, and other systems organizations depend on for recovery. 
• The advisory calls on organizations to prove their resilience through testing and validation against observed attacker behaviors, not assume it from plans or successful backup jobs alone.  

The latest federal advisory on Medusa ransomware was updated for a reason: The adversary changed. 

The updated federal advisory, issued August 18, 2026, by the FBI, Cybersecurity and Infrastructure Security Agency (CISA), and U.S. Department of Health and Human Services (HHS), describes an adversary that recruits new access brokers, moves faster once inside, and has gotten better at making sure the damage it causes cannot be undone.  

The Attack Is Not Just Against Your Data

Medusa actors move quickly. Investigators report that Medusa actors have leveraged newly announced exploits within 24 hours and, in some cases, have used exploits up to a week before public vulnerability disclosure. 

Once inside, they blend in using legitimate remote management tools, credential theft, and living-off-the-land techniques. 

But the advisory’s most significant finding is that Medusa attacks the recovery path itself. 

The advisory maps this activity to MITRE ATT&CK technique T1490, Inhibit System Recovery. It documents the ransomware terminating services associated with backups, security, databases, communications, file sharing, and websites. It also deletes shadow copies, and remotely shuts down and encrypts virtual machines. 

If an attacker is deliberately targeting the systems, identities, and infrastructure an organization may need to recover, the problem extends beyond data protection into cyber resilience and cyber recovery. 

Where ResOps (Resilience Operations) Comes In

ResOps is not another name for backup. It is an operating discipline that brings security, IT, infrastructure, applications, operations, and the business together around one outcome: keeping critical services running and recovering them within the time the business can tolerate. 

The Medusa advisory never uses the word ResOps, but the thinking is there. It recommends organizations exercise, test, and validate their security programs against observed attacker behaviors, align security technologies to attack techniques, test them at scale, measure performance, and tune people, processes, and technologies based on the evidence. 

A backup does not prove it is clean. A recovery-time objective in a spreadsheet does not prove the business will be operating within that window. Resilience has to move from assumption to evidence. 

Start With the Business, Not The Server

The addition of HHS in the advisory makes this especially relevant for healthcare, a sector the FBI says has been a frequent Medusa target. The recovery conversation starts with three questions: 

• What has to keep running, and what does minimum viable operation look like? 

• Which identities, applications, infrastructure, and data support those services? 

• Which recovery points we can trust, and what comes back first? 

In a hospital, leaving any one of those unanswered may mean a delayed surgery, a pharmacist who can’t verify a dosage, or a diagnostic system a clinician can’t trust. No single team can answer them alone, which is the gap ResOps is designed to close. 

Use Medusa to Test Your Assumptions

Use Medusa as a test case for recovery assumptions. Can an attacker reach the systems supporting recovery? What happens if Active Directory is compromised? Can you identify a clean recovery point, restore critical services in the correct order, and prove how long that will take? 

Threat actors adapt when defenders adapt. Resilience programs need to operate the same way: continuously tested, continuously validated, and continuously improved.  

Because the middle of an incident is a terrible time to discover that the recovery plan looked better on paper than it works in real life. 

FAQs

Q: What is Medusa ransomware? 

A: Medusa is a ransomware-as-a-service operation first identified in 2021. Its developers and affiliates use a double-extortion model, encrypting systems while threatening to publish stolen data if a ransom is not paid. 

Q: Why was the federal Medusa advisory updated? 

A: The August 2026 update incorporates findings from FBI investigations as recent as April 2026. It expands the documented tactics, techniques, procedures, exploited vulnerabilities, affiliate activity, and indicators of compromise, while adding HHS insights on attacks against healthcare. 

Q: How does Medusa threaten an organization’s recovery capabilities? 

A: Medusa can terminate services associated with backups, security, databases, communications, and other critical functions. It also can delete shadow copies, alter identity-related policies, and shut down or encrypt virtual machines, putting the recovery path itself at risk. 

Q: What should organizations do to help reduce Medusa risk? 

A: Organizations should patch known vulnerabilities promptly, segment networks, restrict access to remote services, strengthen authentication, monitor lateral movement, and apply least privilege. They also should maintain separate, offline, encrypted, and immutable recovery copies and regularly test restoration workflows. 

Q: What is ResOps, and how is it different from backup? 

A: ResOps, or resilience operations, is a cross-functional operating discipline – not a backup product. It aligns security, IT, infrastructure, applications, operations, business continuity, and business owners around restoring critical services within the amount of disruption the business can tolerate. 

Q: How can an organization help prove it is ready to recover? 

A: Start with critical business services, map the identities, applications, infrastructure, data, people, and third parties they depend on, and define successful recovery. Then run realistic exercises that identify clean recovery points, restore services in the correct order, measure actual recovery time, and turn any gaps into an owned improvement backlog. 

Chris Bevil is Principal Portfolio Marketing Manager at Commvault. 

Key Takeaways 

• Roughly 1,200 supposedly isolated agents communicated through an unauthorized message board, and about 700 participated in Hugging Face-related activity. 
• Agents exchanged over 70,000 messages and files, combining discoveries across sessions meant to remain separate. 
• Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.  
• Immutable, isolated backups alone are insufficient: Organizations need a validated, trustworthy recovery point before restoring to production. 

The forensic reports are finally here, and they changed the way I think about this incident. 

About a month ago, I wrote about the OpenAI and Hugging Face security incident because I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.  

At the time, the story sounded fairly straightforward: An AI agent found a way outside the environment designed to contain it and ultimately reached Hugging Face. 

That is not really what happened. 

The Story Is Bigger Than One Rogue Agent 

The forensic reports reveal that about 1,200 agents, supposed to be operating in isolation, discovered a way to communicate through an unauthorized message board. They exchanged more than 70,000 messages and files, and roughly 700 agents participated in activity associated with Hugging Face. 

None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.  

Among the new details: GPT-5.6 Sol agents reproduced an exploit and copied private evaluation data into a public Hugging Face dataset, a concrete escalation beyond what initial reports described. 

The Reward-Hacking Problem 

The independent investigation conducted by METR and Redwood Research, published alongside OpenAI’s own report on August 26, found that agents researched ways to spoof, edit or delete portions of their own evaluation transcripts because they incorrectly believed the grader would inspect how they completed the task. Researchers found successful tool-call spoofing in about 7% of the transcripts they evaluated, though the manipulation they observed was small-scale. 

The finding is not that agents are “deceptive” in a human sense. It is that a sufficiently capable agent can search for ways around controls when those controls stand between it and the outcome it has been optimized to achieve. 

OpenAI calls the incident a “warning shot.” I think that is a fair description. 

What Happens When Containment Fails 

Most of the conversation about this incident will rightly focus on alignment, sandboxing and monitoring. But there’s a resilience question underneath it: If 700 agents can find a side door around containment, what’s the plan for when a single compromised workload does the same in your environment? 

OpenAI’s own conclusion points at the answer: Security architecture should assume an individual workload or compute node eventually can be compromised. That means air-gapped, immutable recovery data, and a way to validate what you’re restoring before it touches production again. 

But immutability alone does not prove the data was clean when it was captured. If the data was already compromised at the time of capture, immutability preserves the compromise just as faithfully as it preserves anything else. 

The practical version of that question is simple to ask and hard to answer: If this happened to us, could we prove which recovery point predates the compromise? 

We cover this operating model under ResOps (resilience operations) on the Readiverse. 

The Lesson for Every Organization 

OpenAI has since tightened workload and network isolation, expanded monitoring, and revised its model-development practices. The lesson applies beyond OpenAI: Contain the impact, preserve what you can trust, and prove you can recover before you need to. 

FAQs 

Q: What was the OpenAI-Hugging Face incident? 

During internal cybersecurity evaluations, OpenAI agents bypassed controls intended to isolate them, accessed the internet and reached third-party systems, including Hugging Face. The activity was driven primarily by an internal research model operating with reduced safeguards. 

Q: How did supposedly isolated agents communicate? 

A: They discovered an unauthorized message board in shared infrastructure. About 1,200 agents used it to exchange more than 70,000 messages and files, allowing information and tactics to carry across sessions that were designed to remain independent. 

Q: Were the agents instructed to attack Hugging Face? 

A: No. They were attempting to complete a difficult cybersecurity benchmark. When the intended route appeared blocked, some agents searched for alternative ways to achieve the evaluated outcome, and that activity expanded beyond the environment’s intended boundaries. 

Q: What does “reward hacking” mean in this context? 

A: Reward hacking occurs when an agent finds an unintended way to satisfy a metric or obtain a desired result without completing the task as intended. Investigators found agents researching ways to spoof tool calls and alter or delete portions of evaluation transcripts because they believed the grader might inspect their process. 

Q: Why are immutable backups not enough on their own? 

A: Immutability prevents stored data from being altered, but it does not prove the data was clean when it was captured. If a backup already contains compromised data, immutability preserves that compromise. Organizations therefore need isolated copies, trustworthy recovery points and validation before restoration. 

Q: What should organizations do differently after this incident? 

A: Strengthen workload and network isolation, restrict unnecessary internet and credential access, monitor agent behavior and escalation signals, and assume that prevention may fail. Pair those controls with air-gapped, immutable recovery data and a tested process for identifying and validating a clean recovery point. 

Chris Bevil is Principal Portfolio Marketing Manager at Commvault. 

Key Takeaways

• Certificate lifespans will shrink from 398 to 47 days by March 2029 with “domain validation reuse” shrinking to just 10 days, making manual renewal obsolete and automatic Certificate Lifecycle Management (CLM) necessary.
• Harvest Now, Decrypt Later operations are already underway to store data with long lifespans for future decryption using quantum computers, which means there is an immediate threat to encrypted, sensitive data that have longer term retention.
• Certificate/Crypto Inventory is most crucial for companies to start building now, as continuous and automated inventory is the first step toward long-term cyber-resilience and crypto-agility.

The Problem Hiding in the Background

Most modern enterprise networks rely on a hidden layer comprised of digital certificates and cryptography that most people never see. This layer verifies machine trust and secures data flows, but with machine identities now outnumbering human identities by more than 80 to 1 in the average enterprise according to CyberArk’s machine identity research, it can be easy to underestimate the cryptographic and certificate layer’s importance.

A helpful way to think about a digital certificate is an ID badge for a machine. If the badge is valid, the doors open automatically and no one thinks about it, but the moment that badge expires or is misconfigured, the door stops opening, regardless of how legitimate the machine behind it is. A single expired certificate can take down websites, break the APIs that let applications talk to each other, interrupt transactions, and create compliance violations, all while eroding user trust.

For years, organizations have managed certificates manually, but two changes are going to make it impossible to keep up by hand. First, the maximum lifespan of public Transport Layer Security (TLS) certificates, the protocol securing your browser, is being compressed to just 47 days by 2029. Second, the eventual arrival of quantum computers powerful enough to break today’s encryption is forcing a transition to Post-Quantum Cryptography. These two issues both point to the same solution – a governed, automated, and crypto-agile approach to CLM.

The Roadmap Behind Shrinking Certificate Lifespans

The operational window for public TLS certificates has been narrowing for a decade. In early 2023, Google first published its “Moving Forward, Together” roadmap, which proposed reducing certificate validity from 398 days to 90 days in hopes to push the industry toward automation. Apple accelerated that timeline in October 2024 by introducing a draft ballot to the CA/Browser Forum, the industry body where certificate authorities and browser makers set shared rules. Apple’s proposal, endorsed by Sectigo, Google Chrome, and Mozilla, was approved in April 2025 as Ballot SC-081v3.

This reduction happens in phases. The past 398-day maximum has already dropped to 200 days as of March 2026, with the maximum being reduced to 100 days in March 2027, and finally to 47 days in March 2029. In practical terms, an organization that currently renews each certificate about once a year will soon be renewing every certificate roughly every month and a half; by the final stage, any process that depends on a person manually requesting and installing certificates will fail.

Browser makers are pushing for these shorter lifespans to force automation, which removes the human error that causes most certificate outages in the first place. They also let the entire web adopt new cryptographic standards in weeks rather than years, since old certificates cycle out quickly. Additionally, they help reduce reliance on legacy revocation systems which suffer from performance and privacy problems. Lastly, if a Certificate Transparency log (a public record of issued certificates) is ever disqualified, short-lived certificates dramatically shrink the number that must be replaced on short notice.

The Validation Crunch

While the 47-day limit gets headlines and attention, the more disruptive change may be what happens to Domain Control Validation (DCV). DCV is the process of proving to a Certificate Authority (CA) that you control the domain you are requesting a certificate for. Historically, once an organization proved ownership, the CA could reuse that proof for up to 398 days, but under SC-081v3, the reuse window shrinks to 200 days in 2026 and to just 10 days by March 2029.

This creates a real imbalance, as even an organization that fully automates certificate installation will stall if it cannot re-prove domain ownership every 10 days. Any delay in validation halts the entire issuance pipeline and leads directly to outages.

The practical answer to this problem is adopting the Automatic Certificate Management Environment (ACME) protocol with automated DNS-01 API validation, so that proving ownership happens programmatically rather than waiting on a person.

The Quantum Threat and Timeline

While certificate lifespans shrink, the algorithms inside those certificates face a quantum threat. Traditional Public Key Infrastructure (PKI) rely on asymmetric cryptography to secure digital signatures, key exchanges, and TLS connections. A sufficiently powerful quantum computer running Shor’s algorithm could break these systems completely. Waiting until quantum computing is powerful enough to decrypt is not a viable option; as Commvault Field CTO Vidya Shankaran has written, “the exact date of Q-Day may remain uncertain. The direction of travel is not.” 

Estimates place Q-Day, the point at which a quantum computer can break public-key encryption, somewhere in the next 5 to 10 years. However, it would be a mistake to treat this as a future problem. Threat actors are already conducting Harvest Now, Decrypt Later (HNDL) operations, intercepting and storing encrypted traffic today with the intention of decrypting it once quantum computing matures. Data that must stay confidential for years, such as health records, intellectual property, and financial information, is effectively exposed the moment it is harvested.

The U.S. Federal Government has responded accordingly: In June 2026, the White House issued Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, which sets deadlines well ahead of NIST’s original 2035 target: Federal high-value systems must adopt post-quantum key establishment by the end of 2030 and post-quantum digital signatures by the end of 2031.

Despite this urgency, actual progress toward enterprise-level crypto-agility has been slow. The DigiCert Quantum Readiness Outlook found that more than half of surveyed organizations expect classical asymmetric encryption to be broken within five years, yet only 7% have deployed quantum-safe or hybrid cryptography across their certificate estates, and overall readiness improved by just 2 percentage points in the past year.

Why Does Crypto-Agility Matter?

The most practical bridge between classical and post-quantum cryptography is the hybrid composite certificate, which combines a classical algorithm (RSA or ECC) with a post-quantum algorithm (ML-DSA, the standardized lattice-based signature scheme) inside a single X.509 certificate. Combining both into a single certificate is designed so that the certificate will hold up as long as either algorithm does, which is essential, as post-quantum algorithms are new and haven’t yet survived countless attempted attacks like RSA has.

However, post-quantum keys and signatures are several kilobytes rather than a few hundred bytes, which increases network latency, risks packet fragmentation during the TLS handshake, and adds computational overhead that may require hardware upgrades for constrained devices. This is exactly why crypto-agility matters; organizations need the ability to test, deploy, and rotate algorithms without rewiring their underlying infrastructure each time standards evolve.

Automated Certificate Lifecycle Management

Manual certificate management is not just inefficient; it is a genuine operational liability. When certificates live in spreadsheets out of sight, organizations lose visibility, and the result is expired credentials, weak key sizes, outdated signature algorithms, and noncompliant configurations that no one notices until something breaks. The resulting outages can confuse users, interrupt revenue, and land on whichever team is least prepared to explain them.

A complete CLM platform addresses this across the full life of a certificate:

• Discovery: continuous scanning of cloud environments, datacenters, containers, and external domains to find all certificates in use.
• Monitoring: tracking expiration dates, algorithms, key strengths, and compliance with security policy in real time.
• Validation: Utilize direct API integration with public and private CAs, while automating domain validation and approvals
• Installation: Deploy renewed certificates and keys programmatically through ACME or secure APIs, with no manual handoffs.
• Revocation: Executing fast, policy-driven revocation is necessary so a compromised certificate can be rotated or revoked everywhere at once rather than hunted down machine by machine.

There is also a payoff hiding in the discovery step: The certificate inventory a CLM platform maintains is, in effect, the beginning of the cryptographic inventory that post-quantum migration planning requires, which can turn a compliance chore into a head start.

Non-Human Identities and Agentic AI

The scale problem is compounded by how modern applications are built. Containers, Kubernetes pods, virtual machines, Internet of Things (IoT) devices, and APIs all need their own credentials, and many of these workloads exist for only minutes or hours before terminating. No team of humans can issue and retire certificates at that velocity.

To keep up with this breakneck pace, AI agents can be utilized to discover, issue, renew, and manage certificates on their own, while remaining inside existing guardrails such as security policies, role-based access control (RBAC), and centralized audit trails. The result is automation at machine speed without giving up enterprise governance.

Where To Start

1. The first step toward company-wide crypto-agility and resilience is organizational rather than technical. Following guidance from NIST, enterprises should establish a central machine identity services team that owns the CLM platform, standardizes certificate templates, and maintains integrations with public and private CAs. Individual application owners and DevOps teams, in turn, should be responsible for wiring automated renewals into their own deployment pipelines, using the central platform as a shared service. This split keeps governance consistent while eliminating the manual handoffs that cause outages.
2. Organizations should replace manual validation techniques and workflows with ACME and automated DNS-01 validation now, well before the 10-day DCV window arrives, while deprecating every manual renewal and validation process along the way.
3. 1. 1. In parallel, organizations should conduct a full inventory of their cryptographic assets to surface hardcoded keys, legacy algorithms, and long-lived trust paths protecting sensitive data.
      2. Post-quantum preparation should start in a controlled environment rather than in production. A dedicated testing lab should be established to allow teams to test hybrid composite certificates and crypto-agile upgrades in a sandbox. By building applications on modular cryptographic libraries connected to a dynamic CLM platform, enterprises can gain true crypto-agility: the ability to rotate keys, ciphers, and algorithms across their infrastructure as standards change, without a rebuild.

The thread that connects all recommendations is inventory. A CLM platform’s discovery step is not busywork before the real fix; it is the same discipline organizations will need across every layer of quantum readiness. Certificates are non-human identities, and the same questions apply to service accounts, AI agents, open source dependencies, and the algorithms buried in application code: What do we have, what does it protect, and which of it matters most to the business?

Organizations that build that inventory muscle now, starting with certificates, will find the rest of the transition far less daunting, because prioritization becomes a calculation rather than a guess. Treating the next few years as a planning window rather than a grace period will help organizations make this transition on their own terms, instead of letting an outage make the decision for them.

Caitlin Dodson is a Summer 2026 Intern for FCTO – Americas at Commvault.

Key Takeaways

• Replace subjective claims about “ease of use” with a measurable data protection gearing ratio: protected capacity divided by the number of full-time administrators.
• Measuring protected capacity per FTE provides a more meaningful view of operational efficiency than legacy metrics such as backup jobs per administrator.
• The data protection gearing ratio should be used as a baseline before a platform migration and measured again afterward to validate operational improvements.
• Factors such as multi-cloud environments, cyber recovery requirements, and compliance obligations can influence the ratio, so it should be evaluated within the context of each environment.
• Organizations should ask vendors to commit to measurable operational outcomes instead of relying on qualitative claims about simplicity.

Every vendor evaluation I have sat in eventually reaches the same dead end. One side says the platform is simple to run. The other side says their platform is simpler.

Nobody can prove either claim, so the conversation drifts to the demo, the reference call, the gut feeling in the room. That is not how you should be making a decision that determines how your team will spend the next five years.

I have run production data protection environments. I have watched teams get buried under fragmented tooling that promised automation and delivered tickets instead.

“Reduced complexity” is not a feeling you should have to take on faith. It is something you should be able to calculate.

The Metric the Industry Has Been Missing

We have started using a simple ratio internally and with customers: total protected capacity divided by the number of full-time staff required to run it. We call it the data protection gearing ratio.

Protected Capacity (PB) / FTEs = Data Protection Gearing Ratio

That’s it. No survey questions about satisfaction. No adjectives. A number, calculated from data you already have.

Here is why it matters more than the metrics it replaces. Calculating the number of backup jobs per person made sense a decade ago, when a job represented a discrete unit of manual effort. It does not reflect how modern platforms operate today, where automation absorbs the routine work and a single administrator can be accountable for petabytes, not job counts.

Measuring jobs per person in an automated environment tells you nothing about whether the automation is actually working.

What It Looks Like in Practice

One clarification before the number, because it trips people up. Protected capacity means the full, uncompressed, undeduplicated size of the applications being protected, not the physical disk behind them.

That distinction matters because it is the whole point. Commvault’s own production environment protects 42.39 PB of application data on 9.26 PB of physical disk, an 81.91% space savings from deduplication and compression.

The ratio is not just a measure of how many petabytes a person can watch over. It is a measure of how much architecture is doing the work before headcount ever enters the picture.

With that in mind: Commvault runs its own production backup environment on 42.39 PB of protected capacity with two FTEs. That is a gearing ratio of 21.20 PB per FTE. Industry benchmarks for modern platforms typically land between 5 and 25 PB per FTE, depending on environment complexity, so that number sits at the high end of what is achievable today.

Data Protection Gearing Ratio = 42.39 PB / 2 FTEs = 21.20 PB per FTE

I want to be direct about what this number does not do. It does not account for a multi-cloud footprint, cyber recovery requirements, or a compliance-heavy application mix, all of which will pull the ratio down for reasons that have nothing to do with how good the platform is.

A ratio in isolation is not a verdict. A ratio measured before and after a migration is.

That is the actual use case. Baseline your current environment on your current tools. Set a target ratio based on your growth projections and your team’s capacity. Then hold your vendor to it after the implementation is done, not just during the sales cycle.

The Board-Level Implication

If you are the one signing off on a platform migration, you are not just being asked to trust that a new platform is easier to run. You are being asked to fund a specific operational outcome. A data protection gearing ratio target gives you a way to write that outcome into the business case and check it 12 months later.

This is the same discipline we apply to mean time to clean recovery (MTCR). Recovery capability is not something you claim, it is something you measure and re-measure until the number tells you the truth. Operational efficiency deserves the same standard.

The Challenge

Ask your current vendor for the gearing ratio of your own environment today. If they cannot produce it, that tells you something about how well they understand what “simple to manage” means for your team.

And if you are evaluating a new platform, do not accept “easier to use” as an answer. Ask what ratio they will commit to, and ask again after year one.

FAQs

Q: What is the data protection gearing ratio?

A: The data protection gearing ratio measures the amount of protected data capacity managed by each full-time administrator. It provides an objective way to evaluate operational efficiency rather than relying on subjective impressions of platform usability.

Q: Why is this metric more useful than backup jobs per administrator?

A: Modern data protection platforms automate much of the routine work that previously required manual effort. As a result, counting backup jobs no longer reflects the true workload or efficiency of an operations team.

Q: What does “protected capacity” mean in this calculation?

A: Protected capacity refers to the full, uncompressed, and undeduplicated size of the application data being protected. This measurement reflects the actual workload managed by the platform rather than the physical storage consumed after optimization.

Q: Does a higher gearing ratio always indicate a better platform?

A: Not necessarily. Environmental complexity, including multi-cloud deployments, cyber resilience requirements, and regulatory obligations, can reduce the ratio even when the platform performs well. The metric is most valuable when comparing the same environment before and after a migration.

Q: How should organizations use the data protection gearing ratio during vendor evaluations?

A: Organizations should establish a baseline using their current environment, define a target ratio aligned with future growth, and ask vendors to commit to achieving measurable improvements after implementation. This approach shifts the conversation from marketing claims to verifiable business outcomes.

Q: What is the broader business value of this metric?

A: The data protection gearing ratio enables executives to quantify expected operational efficiency gains and include them in the business case for a platform investment. It also provides a benchmark that can be reviewed after deployment to confirm the promised results were achieved.

Rajiv Kottomtharayil is Chief Products Officer at Commvault.