Points clés à retenir

• Years of reasonable technology decisions can accumulate into operational complexity that makes resilience harder to manage, govern, test, and maintain.  
• Fragmented tools, policies, workflows, and ownership can create inconsistent recovery models and make business-wide recovery difficult to predict.  
• Unified data protection can help reduce operational friction by simplifying control and standardizing protection across increasingly diverse environments.  
• Cyber resilience depends not only on safeguarding individual workloads but also on building security into recovery processes and continuously proving recovery readiness.  
• As cloud, SaaS, edge, and AI environments expand faster than teams, simplifying resilience architecture becomes increasingly important for reliable, repeatable recovery. 

One advantage of having spent part of my career on the operational side of backup and recovery is that I still can’t help looking at resilience through the eyes of the people who have to run it every day. 

Years ago, the job was complicated, but it was generally clear. Most critical systems lived within a relatively defined set of boundaries. Protection strategies were comparatively standardized. Recovery planning focused on a known set of applications, databases, and infrastructure. The technology wasn’t simple, but the operating model was understandable. 

Today, those boundaries have largely disappeared. 

Business processes span SaaS applications, cloud-native services, multiple clouds, edge environments, AI initiatives, and traditional infrastructure. Different teams own different parts of the stack. New technologies arrive faster than old ones are retired. And every addition introduces new dependencies that may not become obvious until something breaks or needs to be recovered. 

I recently joined Michael Thelander, Senior Director of Product Marketing at Commvault, for a webinar on how to address this very issue. You can watchUnified Data Protection as the Foundation for Resilience on demand now.   

Why Data Protection Keeps Getting Harder

What’s interesting is that most organizations didn’t intentionally design this complexity into their resilience architecture. They accumulated it over time. 

Cloud teams adopted native protection capabilities. Application owners implemented processes that made sense for the platforms they supported. Acquisitions brought inherited technologies and operating models. Business units optimized around their own requirements. Most of those decisions were reasonable and, in many cases, necessary. The challenge is that every one of those decisions carried a cost. 

There’s the obvious cost of software, infrastructure, and storage. More significant, though, is the operational cost that accumulates quietly over the years. Every new protection method introduces another policy framework to manage, another workflow to document, another exception to troubleshoot, another recovery process to test, and another set of skills the organization must maintain.  

Eventually, teams spend as much time managing the complexity surrounding resilience as they do improving resilience itself. 

On its own, that might sound like an efficiency problem. But over time, it evolves into a resilience problem. The more moving parts an organization introduces, the harder it becomes to maintain consistency. Recovery procedures evolve differently across teams. Policies drift. Ownership fragments. Knowledge becomes concentrated in a handful of people who understand how everything fits together. 

Eventually, the challenge stops being whether individual workloads can be protected and becomes whether the organization can consistently govern, test, and recover across everything it supports. Most organizations understand how individual systems recover. Far fewer can confidently explain how the business recovers. 

Unerecent cyber resilience survey found that nearly half of organizations identify IT complexity as their biggest cyber resilience challenge. That finding isn’t particularly surprising. Most enterprises aren’t struggling because they lack protection technologies. In many cases, they have more protection technologies than ever before.  

The challenge is understanding how all of those technologies come together when the organization actually needs them. 

AI is making this reality even more visible. Models depend on training data, pipelines, infrastructure, repositories, identities, and services that often span multiple teams and environments. Protecting those individual components is one challenge. Recovering the ecosystem they collectively support is another. 

That’s one reason Michael and I spent so much time discussing complexity. 

On the surface, unified data protection sounds like a conversation about backup architecture. In reality, our discussion centered on a much broader challenge: how organizations reduce the operational burden created by years of accumulated complexity while creating a more consistent foundation for resilience.  

Because the goal isn’t consolidation for consolidation’s sake. It’s all about reducing operational friction. Creating consistency where consistency matters. And making recovery more predictable, repeatable, and trustworthy. 

From Fragmented Tools to a Unified Foundation

During the webinar, Michael and I explored four practical ways organizations can begin reducing complexity and strengthening resilience: simplifying control, standardizing protection, building cyber resilience directly into the recovery process, and continuously proving recovery readiness.  

While the tactics differ, the objective is the same. The less effort organizations spend stitching together fragmented tools, policies, and workflows, the more confidence they can have in their ability to recover when it matters most.  

What stayed with me long after the conversation ended was the recognition that resilience has become as much an operational and architectural challenge as a technical one. Organizations are being asked to support more applications, more clouds, more services, more data, and more AI initiatives than ever before. Yet few have the luxury of expanding teams at the same pace. That reality makes simplicity increasingly valuable.  

If I were running backup and recovery operations today and I were re-evaluating my organization’s approach, I wouldn’t start by asking whether we have enough protection tools. I’d start by asking how much complexity we’re carrying and what it’s costing us. Because those costs extend far beyond software licenses and infrastructure. They’re reflected in operational effort, fragmented processes, inconsistent recovery models, and ultimately in an organization’s ability to recover when it matters most. 

FAQ

Q: Why has data protection become more complex for organizations?R :Business processes now span SaaS applications, cloud-native services, multiple clouds, edge environments, AI initiatives, and traditional infrastructure. As teams adopt different protection methods for these environments, organizations accumulate policies, workflows, skills, and dependencies that increase the operational burden of resilience. 
Q: How can technology complexity affect cyber resilience?R :More tools and processes can make it harder to maintain consistent policies, ownership, testing, and recovery procedures across an organization. Over time, this fragmentation can turn what initially appears to be an efficiency challenge into a resilience challenge. 
Q: What is unified data protection intended to accomplish?R :Unified data protection is about more than consolidating backup technologies. Its broader purpose is to reduce operational friction, create consistency where it matters, and make recovery more predictable, repeatable, and trustworthy. 
Q: What practical steps can organizations take to reduce resilience complexity?R :Organizations can focus on simplifying control, standardizing protection, building cyber resilience directly into recovery processes, and continuously proving recovery readiness. Together, these practices can reduce the effort required to coordinate fragmented tools, policies, and workflows. 
Q: Why does AI make resilience complexity more visible?R :AI initiatives can depend on interconnected training data, pipelines, infrastructure, repositories, identities, and services spanning multiple teams and environments. Protecting each component individually does not necessarily address the larger challenge of recovering the complete ecosystem those components support. 
Q: What should organizations consider when reevaluating their data protection strategy?R : Rather than starting with whether they have enough protection tools, organizations should examine how much operational complexity they are carrying and what it costs them. That includes the impact of fragmented processes, inconsistent recovery models, administrative effort, and the organization’s overall ability to recover when it matters most. 

Jason Gizais Senior Manager, Partner Solutions Marketing, at Commvault. 

Points clés à retenir

• ResOps is not a technology product. It’s a cross-functional operating discipline that helps drive organizational cyber resilience.
• It complements backup, de 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,de 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 de 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.

Qu’est-ce que ResOps ?

ResOpsis 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 de Recovery.

ResOps does not replace strong backup and de 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.

En savoir plus

Commvault has publishedResOps: 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. 

FAQ

Q: Is ResOps simply a new name for de 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.

Points clés à retenir

• 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.
• Faites de ResOps un modèle opérationnel partagé pour les responsables de la sécurité, de l’infrastructure, de la continuité d’activité et des services.
• Mesurez ce qui compte : les équipes doivent savoir si les services critiques peuvent être rétablis, combien de temps la Recovery prend réellement et si elles sont en mesure de le prouver.
• Sélectionnez un ou deux services critiques, définissez ce qu’est une Recovery réussie, menez un exercice réaliste et consignez les résultats.
• 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. Somewici 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.

Le mur n’a jamais été le seul objectif

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.

Trois questions que je pose à ma propre équipe

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

• Si nous étions touchés ce soir, pourrions-nous nous remettre sur pied ?
• Combien de temps cela prendrait-il réellement ?
• Pouvons-nous le prouver, avec des preuves, au conseil d’administration ?

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.

Des preuves, pas des promesses

Here’s a distinction the book makes better than I’ve heard it made anywici 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.

Ce qui devrait inquiéter tout RSSI

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.

Commencez par un seul 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 ici.

FAQ

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.

Points clés à retenir 

• Le document d’orientation fédéral mis à jour fait état des nouvelles tactiques et techniques de Medusa, ainsi que de plus de 500 victimes issues de secteurs d’infrastructures critiques. 
• Attackers target more than production data; they also disrupt backups, identity, virtualization, and other systems organizations depend on for recovery. 
• Leadvisory 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.  

Lelatest federal advisory on Medusa ransomware was updated for a reason:Leadversary changed. 

Leupdated 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.  

LeAttack 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. 

Leadvisory 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. 

LeMedusa 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 LeServer

Leaddition of HHS in the advisory makes this especially relevant for healthcare, a sector the FBI says has been a frequent Medusa target. Lerecovery 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. 

FAQ

Q: What is Medusa ransomware? 

R :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? 

R : LeAugust 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? 

R :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? 

R :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? 

R : 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? 

R :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 Bevilis 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 lagrader.  
• Immutable, isolated backups alone are insufficient: Organizations need a validated, trustworthy recovery point before restoring to production. 

Leforensic reports are finally here, and they changed laway I think about this incident. 

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

At latime, lastory sounded fairly straightforward: An AI agent found a way outside laenvironment designed to contain it and ultimately reached Hugging Face. 

That is not really what happened. 

LeStory Is Bigger Than One Rogue Agent 

Leforensic 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. Leagents 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 lanew 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. 

LeReward-Hacking Problem 

Leindependent 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 lagrader would inspect how they completed latask. Researchers found successful tool-call spoofing in about 7% of latranscripts they evaluated, though lamanipulation they observed was small-scale. 

Lefinding 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 laoutcome it has been optimized to achieve. 

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

What Happens When Containment Fails 

Most of laconversation 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 laplan for when a single compromised workload does lasame in your environment? 

OpenAI’s own conclusion points at laanswer: 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 ladata was clean when it was captured. If ladata was already compromised at latime of capture, immutability preserves lacompromise just as faithfully as it preserves anything else. 

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

We cover this operating model underResOps (resilience operations) on laReadiverse. 

LeLesson for Every Organization 

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

FAQ 

Q: What was laOpenAI-Hugging Face incident? 

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

Q: How did supposedly isolated agents communicate? 

R :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 laagents instructed to attack Hugging Face? 

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

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

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

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

R : Immutability prevents stored data from being altered, but it does not prove ladata 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? 

R :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 Bevilis Principal Portfolio Marketing Manager at Commvault. 

Points clés à retenir

• 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 bymore 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 byintroducing 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 berenewing 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 withautomated 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 issuedExecutive 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 Outlookfound 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 platformaddresses 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. Followingguidance 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.