Cybersecurity has spent decades trying to keep bad things out.

That work still matters. Firewalls matter. Identity controls matter. Patch management matters. Secure software design matters. But the modern threat landscape has made one thing harder to ignore: prevention is not enough.

The systems that matter most now are too connected, too dependent on third parties, too exposed to software supply chains, and too important to treat security as a wall around a single machine. When something breaks, the question is no longer only whether the breach could have been prevented. The question is whether the mission can keep going.

That is the shift behind a new paper in the Journal of Cybersecurity by Ryan P. Hilger, which introduces the Cyber Resilience Cube, a framework for thinking about cybersecurity as a broader resilience problem instead of a narrow control checklist.

The core idea is simple and useful: cybersecurity should not only ask whether an organization can block an attack. It should ask whether the organization can plan for disruption, absorb the shock, recover from it, and adapt afterward.

The old model is too narrow

Traditional cybersecurity frameworks tend to focus on prevention, protection, control implementation, and compliance. Those are necessary, but they are not enough for the kind of incidents organizations actually face now.

SolarWinds, Colonial Pipeline, Storm-0558, and the XZ Utils backdoor are not just stories about individual vulnerabilities. They are stories about trusted systems, supply chains, identity infrastructure, public services, and institutional dependencies.

That is the important pattern. The most serious cyber incidents no longer stay neatly inside one technical boundary. They move across vendors, agencies, operators, cloud providers, open-source projects, and users. They exploit the connective tissue.

A defensive posture built only around component-level controls will miss that.

Resilience is not the same as security

Security usually focuses on protection: confidentiality, integrity, availability, accountability, and assurance. Resilience is broader.

Hilger uses a four-phase definition of resilience: the ability to prepare and plan for adverse events, absorb them, recover from them, and adapt afterward. That last phase matters most because it is often the weakest.

Many organizations are reasonably good at planning. Some are good at absorbing disruption. Fewer are good at recovery. Even fewer are good at adaptation, meaning they actually learn, reorganize, change incentives, and improve after failure.

That gap is where resilience becomes more than a buzzword.

A company that restores a compromised system to its previous state may have recovered operationally. But if it does not change the structure that allowed the incident to matter so much in the first place, it has not really become more resilient.

The Cyber Resilience Cube

The Cyber Resilience Cube organizes resilience across three dimensions.

The first dimension is time: Plan and Prepare, Absorb, Recover, and Adapt.

The second dimension is scale: Component, System, Organization, and Ecosystem.

The third dimension is capacity domain: Technical, Human, Organizational, and Social or Institutional.

Together, those dimensions produce 64 possible intersections. That sounds abstract, but the practical value is obvious once applied.

A team might be strong at Absorb, Component, Technical: patching, hardening, segmentation, and redundancy. But it may be weak at Adapt, Ecosystem, Institutional: learning across vendors, regulators, partners, and public-sector dependencies after a failure.

That distinction matters because real incidents are not only technical events. They are organizational events. They are human events. They are institutional events.

The blind spot is adaptation

The paper’s most useful argument is that current cyber policy and standards overemphasize planning and absorption while underdeveloping adaptation.

That tracks with how many organizations behave. They buy tools. They implement controls. They build playbooks. They satisfy audits. Then, when something goes wrong, they restore service and move on.

But adaptation asks harder questions.

  • Did the incident reveal a bad dependency?
  • Did decision authority fail under pressure?
  • Did the organization learn anything beyond the immediate fix?
  • Did the vendor relationship need to change?
  • Did the recovery process expose a workforce gap?
  • Did the board or leadership team understand the real mission impact?

These questions are harder to measure than whether a patch was applied. They are also closer to the point.

Cyber resilience is not just the ability to keep systems online. It is the ability to improve after stress.

Why this matters now

The timing matters because software systems are becoming more automated, more interconnected, and more important to daily operations.

AI will accelerate this. More code will be generated. More agents will operate inside workflows. More infrastructure will be abstracted behind APIs. More organizations will depend on cloud platforms, model providers, identity brokers, package registries, and managed services they do not fully control.

That is not an argument against AI acceleration. It is the opposite. Acceleration makes resilience more important.

The faster systems evolve, the more organizations need resilience models that can handle change. A static checklist cannot keep up with a dynamic environment. A resilience framework has a better chance because it treats uncertainty as part of the operating condition.

The right question is not whether organizations can freeze the risk landscape. They cannot. The right question is whether they can build systems, teams, and institutions that keep functioning as the landscape changes.

Compliance is not enough

The Cyber Resilience Cube also exposes a common weakness in cybersecurity governance: compliance can make an organization look more prepared than it actually is.

A compliance framework can prove that controls exist. It cannot always prove that the organization can coordinate under pressure, recover across dependencies, or adapt after a systemic failure.

This does not make compliance useless. Baselines matter. Standards matter. Controls matter. But they should be treated as inputs into resilience, not proof of resilience.

A mature security program should know which parts of the Cube it covers and which parts it neglects. It should know whether investment is concentrated at the technical component layer while human, organizational, and ecosystem-level capabilities remain thin.

That is the kind of visibility security leaders need.

The ecosystem layer is where things get serious

The most interesting part of the Cube is its ecosystem layer.

Modern organizations do not operate alone. They depend on cloud providers, software vendors, open-source maintainers, payment processors, logistics partners, regulators, managed service providers, and sector-specific coordination bodies.

Many cyber incidents become serious because they move through those dependencies. A compromised update channel, a cloud identity failure, a poisoned open-source package, or a vendor outage can create impact far beyond the original technical fault.

That means resilience cannot be built entirely inside the organization. Some of it has to be negotiated across the ecosystem.

This is where trusted relationships, shared playbooks, public-private coordination, disclosure norms, vendor transparency, and cross-sector response planning become part of cybersecurity itself.

The useful version of cyber resilience

Cyber resilience can easily become empty language. Every vendor wants to sell resilience. Every policy document wants to invoke it. The value of the Cyber Resilience Cube is that it makes the term harder to fake.

It asks where resilience exists, at what scale, in which domain, and at what point in the incident lifecycle.

That gives leaders a practical way to see gaps. Maybe recovery is strong at the system level but weak at the ecosystem level. Maybe technical controls are mature but human decision-making under stress is not. Maybe the organization can absorb a known attack but cannot adapt after a novel one.

Those distinctions are useful because they turn resilience from a slogan into a map.

The next security advantage is adaptive capacity

The strongest organizations will not be the ones that believe they can prevent every failure. They will be the ones that can keep operating, recover intelligently, and get better after being hit.

That is the direction cybersecurity is moving. Not away from defense, but beyond defense.

Prevention remains necessary. But in a world of supply-chain compromise, cloud concentration, AI-accelerated development, critical infrastructure dependencies, and persistent adversaries, the serious question is whether an organization can adapt.

Cybersecurity is becoming a resilience discipline.

The organizations that understand that first will be harder to break, faster to recover, and better positioned for the next wave of technological acceleration.

Sources