Resilience Instead of Availability: What Executives Need to Know About Modern Networks

Availability Measures the Wrong Kind of Disruption

Availability metrics such as 99.9 percent or MTBF figures answer a specific question: how likely is it that a single component will function correctly within a defined period? The underlying assumption is random, mutually independent failure: a faulty power supply, a disrupted cable, a crashed device. Redundancy is effective against precisely this class of fault: if one component fails, a second one takes over.

The failures that actually bring companies to a standstill today do not follow this assumption. A ransomware incident, a faulty firmware update, a defective configuration change rolled out centrally, or the failure of a central service such as a directory service, DNS or DHCP, affects both redundant paths simultaneously, because both paths share the same software, the same configuration and the same dependencies. Two core switches in a cluster are doubly protected against a hardware defect, but exactly singly protected against a configuration error or a compromised management plane: the fault replicates along with them.

In practice, this means a network can be highly available on paper and still fail completely in a single event. Availability describes the absence of minor disruptions. It says nothing about how the organisation copes with a major event.

What Resilience Actually Means for a Network

Resilience is not a soft concept, nor is it a rebranding of high availability. From a network architecture perspective, it consists of three verifiable properties: contained failure domains, a defined emergency mode of operation, and a planned recovery process.

Containing Failure Domains

The central question is not "how do we prevent failure?" but "how far is a failure allowed to spread?". A flat, fully routed network has exactly one failure domain: the entire organisation. Segmentation by site, by functional area, and, in production, by zone and cell, establishes boundaries at which a disruption stops. This concerns not only firewalls between office and manufacturing environments, but also less visible layers: separate broadcast domains, self-contained Layer 2 areas per cell, controlled routing transitions, and a management plane that is not tied to the same thread as the production network.

For senior leadership, the relevant metric is the so-called blast radius: what proportion of operations comes to a halt if any single segment is compromised or shut down? In a resilient network, the answer is "one segment". In many organically grown networks, the honest answer is "everything".

Continuing to Operate in a Degraded State

The second property is the ability of individual areas to keep working without central services. This is particularly critical in production: a manufacturing cell that requires a connection to the central data centre or the cloud for every work step will fail with every disruption to that connection, regardless of how redundantly the cell itself is built. Resilient architectures keep the services required for immediate operation, such as time servers, name resolution, local control and visualisation systems, and, where applicable, local authentication, available within the relevant zone. The goal is a defined emergency mode of operation: what must function locally so that the plant keeps producing, even if the corporate network is dark? This question cannot be answered retroactively in a crisis team meeting. It is an architectural decision.

Recovery as a Design Goal

The third property is the most frequently overlooked: the ability to rebuild the network in a controlled manner from a degraded state. This includes an out-of-band management plane through which network components remain reachable even when the production network can no longer be trusted, offline-secured, versioned configurations for all network components, a documented "known-good" state, and a defined recovery sequence that accounts for dependencies: first core network services, then infrastructure services, then applications, then production. Organisations that first have to work out which VLANs, routes and firewall rules constituted the last working state after an incident lose days instead of hours. In practice, recovery time is almost never limited by hardware, but by missing documentation, lack of rehearsal, and unresolved sequencing.

Legislators Have Already Shifted Their Perspective

The fact that resilience is more than availability is now also enshrined in regulation. Since 6 December 2025, Germany's NIS2 Implementation Act has been in force without a transition period. Among other things, it obliges affected organisations to implement risk management, backup and crisis management, supply chain security, and a tiered reporting procedure for significant security incidents. The registration deadline with the BSI already expired in March 2026. Since 17 March 2026, the KRITIS Umbrella Act has explicitly extended these obligations for operators of critical infrastructure to include physical resilience, that is, resistance to sabotage, natural events and infrastructure failures.

What is notable is the direction of both laws: what is required is not proof that nothing fails, but proof that operations can cope with incidents, through detection, response, reporting and recovery. This is precisely the difference between availability thinking and resilience thinking. There is also a personal dimension: executive management is legally required to approve risk management measures and monitor their implementation. Whether an organisation's network can withstand a major incident is therefore no longer a purely technical question, but a governance issue with liability implications.

Five Questions That Reveal the Level of Maturity

Executives do not need to be able to read network diagrams to assess the state of their infrastructure. Five questions to their IT and OT organisation are enough, provided the answers are specific and evidenced:

• What exactly comes to a standstill if our central data centre, directory service or internet connection fails, and what demonstrably keeps running?
• How many separate failure domains does our network have, and where does the boundary lie between office IT and production?
• Can our sites and production areas operate independently for a defined period, and has this ever been tested in practice?
• How long does a complete network recovery from secured configurations take, and when was it last rehearsed?
• Can we still reach our network components even if the production network is compromised?

Answers such as "that's designed to be redundant" or "we have a concept for that" are warning signs. Only answers backed by figures, test data and documented exercises are credible. A recovery process that has never been rehearsed does not exist in a real emergency.

Implications for Investment Decisions

The shift from availability thinking to resilience thinking changes where budget flows. Availability is typically purchased through hardware: a second device, a second cable, a second power supply. This is visible, easy to procure, and in many cases still sensible. However, it only addresses the smallest class of faults. Resilience, by contrast, arises predominantly from architecture and operations: from segmentation, from locally provisioned core services, from a clean management plane, from well-maintained configuration backups, and from regularly rehearsed recovery procedures. These items are less conspicuous than a redundant core pair, but in a real emergency they alone determine whether the downtime lasts hours or weeks.

Meaningful control metrics at management level are therefore not availability percentages, but rather: the maximum blast radius of a single event, the demonstrated period of independent operation for critical areas, and the most recently measured, rather than estimated, recovery time per business process. Organisations that know these three figures and have them reviewed regularly have their network's resilience under control. Organisations that only track an availability figure in their reporting know only the probability of minor disruptions and nothing about the event that would genuinely affect the business.