Cyber resilience is getting harder to define by the boundaries of an organization.
Enterprises increasingly rely on technologies, services and systems they don't fully control. Software runs on third-party code and cloud infrastructure. AI agents are being connected to enterprise applications, data and identities. Operational technology is increasingly integrated with traditional IT systems. A disruption in any one of those environments can quickly spread across systems, organizations and business processes.
For security leaders, that creates a different kind of resilience challenge. Knowing that a vulnerability, compromised supplier or poorly governed AI system presents a risk is one thing. Understanding what the organization depends on, how those dependencies connect and what happens when one fails is another.
The issue isn't simply that organizations have more technology to secure. It's that the relationships among those technologies are becoming more complex, and responsibility for managing the resulting risks is often spread across security, IT, technology teams, business units and third parties.
AI creates dependencies security teams may not see
AI is a good example of how quickly those relationships can change.
Organizations are moving beyond standalone generative AI tools toward AI systems and agents capable of interacting with enterprise applications and taking actions on behalf of users. To do that, agents may need identities, permissions and access to corporate data, APIs and business systems.
At the same time, attackers are using AI to accelerate their own operations. LevelBlue research illustrates the gap between the speed of that change and organizations' ability to respond. Just 20% of CIOs surveyed by LevelBlue said their organizations were highly effective at defending against AI-enabled adversaries. While 51% believed AI-powered attacks were likely within the next 12 months, only about one-third said their organizations were prepared to manage the threat.
Those findings point to a broader resilience issue. AI isn't simply introducing another attack vector. It is changing both how attackers operate and how enterprises themselves connect users, data and systems.
An agent connected to a customer database, for example, isn't simply another application to protect. Security teams need to understand what information it can access, which systems it can interact with, what actions it is authorized to take and what other business processes depend on its output.
The questions become particularly important as organizations give AI systems greater autonomy. Who approved the agent's access? Who is responsible for monitoring its activity? Can its permissions be revoked quickly? And if an agent takes an incorrect or malicious action, who has the authority to stop it?
Recent incident-response work cited by LevelBlue demonstrates how those connections can be exploited. In one case, an attacker used a malicious OAuth application and legitimate Microsoft Graph APIs to access millions of files across SharePoint. In another, an attacker used the victim organization's own AI assistant to identify spreadsheets containing usernames and passwords.
The tools themselves weren't necessarily compromised. Instead, attackers took advantage of access and permissions that already existed.
Those aren't exclusively AI security or identity questions. They are resilience questions because the answers determine whether an organization can contain a problem before it affects other systems or business processes.
Organizations don't necessarily need an entirely separate resilience program for AI. But they do need to make sure AI systems and agents are incorporated into existing identity, risk, incident response and business continuity processes.
Software supply chains extend resilience beyond the enterprise
Software supply chains present a different version of the same challenge.
Few organizations build or operate their technology environments independently. Applications depend on open-source components, third-party libraries, SaaS providers, cloud infrastructure and external technology partners. Those dependencies can make it difficult for security teams to determine where exposure originates — or how an incident involving one supplier could affect critical business operations.
A security team may have strong controls around its own environment and still be disrupted by a vulnerability, compromise or outage elsewhere in its technology ecosystem.
That makes third-party risk more than a vendor-management exercise. Organizations need to understand which external providers and technologies their most important business processes depend on and what happens if those services become unavailable or compromised.
LevelBlue data suggests many organizations have yet to make that connection operational. Fewer than 9% have business continuity plans scoped to their critical third parties, according to research cited by the company, and fewer than 10% include third parties in continuity testing. Organizations that conduct third-party incident-response planning and maintain formal contingency plans, however, report roughly 42% to 43% improvements in effectiveness.
Not every dependency carries the same risk. A vulnerability affecting a peripheral application is different from a compromise involving software embedded across critical systems. Similarly, an outage at a provider supporting a single department is different from disruption at a cloud or identity provider used throughout the enterprise.
The resilience challenge is determining which dependencies have the potential to create cascading consequences.
That requires security teams to look beyond lists of vendors and vulnerabilities and connect technical risk to business impact. Which systems depend on a particular supplier? Which business processes rely on those systems? What alternatives exist if the provider becomes unavailable? And who makes the decision to isolate, replace or shut down a critical service during an incident?
Those questions are difficult to answer during a crisis if no one has answered them beforehand.
IT and OT convergence raises the stakes
The dependency problem becomes even more consequential when cyber risk reaches operational environments.
Manufacturing systems, utilities, transportation networks and other critical infrastructure increasingly rely on connections between traditional IT and operational technology. Those connections can improve efficiency and visibility, but they can also create pathways through which a cyber incident moves beyond enterprise data and applications.
AI is also changing the threat environment surrounding those systems. LevelBlue researchers have documented how state-backed groups are incorporating AI-assisted tools into reconnaissance, phishing and other attack activity. The company's research into recent geopolitical conflicts has highlighted attacks against energy, telecommunications and other critical infrastructure as examples of how cyber operations can contribute to broader operational disruption.
The result is a resilience problem with consequences that may extend well beyond the security organization.
For organizations operating critical systems, understanding connectivity is therefore as important as identifying vulnerabilities. Security teams need visibility into which IT and OT systems communicate, which third parties can access those environments and which business or physical processes depend on them.
They also need response plans that reflect the operational consequences of security decisions. Disconnecting a system may contain a cyberattack, for example, but it can also interrupt production or another critical service.
Those decisions require input from people who understand both the security risk and the operational impact.
Visibility is only the beginning
Across AI, software supply chains and IT/OT environments, visibility remains an essential first step. Organizations cannot manage dependencies they don't know exist.
But inventories, asset maps and risk assessments alone don't create resilience.
Organizations also need to determine which dependencies matter most and establish who is responsible for managing the risks associated with them.
That means moving beyond a model in which security identifies a risk and hands it to another part of the organization. An AI agent may be deployed by a business unit but governed by enterprise security policies and identities managed by IT. A critical application may be operated internally but depend on several external providers. An OT system may be owned by operations but connected to infrastructure managed by IT.
In each case, ownership crosses organizational boundaries.
This is where cyber resilience becomes as much an operating-model challenge as a technology challenge.
Security leaders can provide information about threats, vulnerabilities and controls. Technology teams understand architecture and system dependencies. Business and operational leaders understand which processes cannot tolerate disruption. Procurement and third-party risk teams may have insight into external suppliers.
Resilience requires bringing those perspectives together before an incident occurs.
Move from awareness to coordinated action
For security leaders, the goal isn't to eliminate every dependency. Modern enterprises couldn't operate that way.
Instead, organizations need to identify the dependencies that could create the greatest business consequences and build plans around them.
That starts with several practical questions: What systems and services support the organization's most critical operations? What technologies, identities, suppliers and data do those systems depend on? Where could one failure affect multiple parts of the business? And who has the authority to make decisions when those dependencies are disrupted?
Organizations can then use those answers to prioritize controls, develop contingency plans and test how teams would respond when critical systems or suppliers fail.
LevelBlue CISO Kory Daniels has argued for a similar approach to resilience: identify the minimum operations the business must maintain, understand the systems and dependencies supporting them, develop alternatives before a disruption and test those plans as incidents rather than treating them as compliance exercises.
The same approach can help organizations address emerging technologies without building a separate security program every time the technology landscape changes.
AI agents, software supply chains and connected IT and OT environments create different technical risks. But from a resilience perspective, they expose a common weakness: Organizations increasingly depend on interconnected systems while responsibility for managing those dependencies remains fragmented.
Closing that gap requires more than greater awareness of emerging threats. It requires security, technology and business leaders to understand what the organization depends on, agree on who owns the associated risks and be prepared to act together when something goes wrong.
That may ultimately be the more useful measure of cyber resilience: not whether an organization can prevent every disruption, but whether it understands the dependencies that matter most — and knows what to do when one of them fails.
