Resilience is a property a system retains.

The word "resilience" has been overloaded in European policy to the point of uselessness. Cybersecurity people use it to mean withstands attack. Continuity planners use it to mean recovers from disruption. Procurement uses it to mean passes the framework. None of those is wrong, none is sufficient, and none is the same thing as what a citizen needs when the lights go out, the payment terminal fails, or the identity service is down for thirty-six hours.

A working definition: digital resilience is the property of a system that lets the function it provides continue — at full capacity or in defined degraded modes — through a disruption to the components that provide it. Function survives component failure. That property has to be measurable, operationally testable, and procured for, not assumed.

From principle to measurement

Finland's 2026 ministerial report I authored for the Ministry of Transport and Communications takes that definition and builds an operational framework around it. The framework has four moves, in this order. Identify the function — settlement, communication, identity, navigation, healthcare access. Inventory the technology stack that delivers it, end to end, including the dependencies the operator does not own. Define a stress scenario the function has to survive — from a single-supplier failure to a regional blackout to a state-level cyber operation. Specify what acceptable degraded operation looks like during that scenario, and the maximum time the function can spend in degraded mode before it counts as a failure.

This is unfashionably boring. It also turns "resilience" from a virtue into a number — the kind of number a regulator can require, a supervisory authority can audit, and a board can be held accountable for missing.

Four technology vectors that will define the next decade

The 2026 report focuses on four. Each has been treated either as too speculative or too technical to merit ministerial attention. Each will define a category of national resilience by the end of the decade.

Blockchain and distributed settlement. Not as a speculative asset class, but as a settlement infrastructure that survives the failure of any individual intermediary. Underused in EU public infrastructure; overused as a slogan in the venture press. The interesting use cases — cross-institution clearing, evidence chains, machine-to-machine settlement in IoT environments — are operationally close, and procurement-ready in narrow domains.

Edge computing. Moving compute closer to where the data is generated, so that a network outage at the centre does not blank a region. Critical for emergency services, for connected vehicles, and for any IoT-dense environment in which the round trip to a central cloud is a single point of failure.

The Internet of Things. The most failure-prone layer in critical infrastructure right now, and the layer with the weakest security baseline. NIS2 covers it on paper; in practice the regulatory perimeter ends at the first device that nobody patched.

Post-quantum cryptography. The migration deadline is 2030 in NIST guidance and the work that has to start now is the inventory — every TLS endpoint, every signed object, every long-lived key. Most operators have not done the inventory. The first organisations to complete it will be the ones still standing on the other side of the transition.

Continuity planning that survives contact with reality

Recovery time objectives mean nothing if the recovery procedure was last tested before COVID. Annual continuity drills are valuable only if they include the organisational parts (who has authority to declare a degraded mode, and how is that decision communicated upward and outward) and not only the technical (does the secondary site spin up in 90 minutes).

The Finnish framework asks operators of essential services to run a documented, end-to-end resilience drill at least once every twelve months, and to publish the structure (not the content) of the drill. The publication requirement is the part that does the work — it forces the drill to actually happen, because the absence of a recent published drill becomes a supervisory matter.

Resilience as a procurement category

For too long resilience lived in business-continuity binders and security committees. It now belongs in procurement, and on the same line of the budget as availability and performance.

Every infrastructure RFP for an essential service should include a stress scenario in the technical requirements, not in an annex. Every cloud-services tender should require evidence of cross-region failover that has been tested in the last twelve months, with the test report attached. Every IoT deployment should be procured against a defined patch cadence and end-of-support date, with both written into the contract.

These are not exotic clauses. They are the procurement consequence of taking the function-survives-component-failure definition seriously.

What I work on

Authoring and advising on the ministerial framework for Finnish digital resilience. Advisory work for operators of essential services on continuity planning, post-quantum migration inventory, and edge-computing strategy. Briefings for boards and supervisory authorities on how the resilience landscape is moving. The technical companion to the 2026 report lives at the Digital Resilience Hub.

For specific engagements — resilience reviews, board briefings, post-quantum readiness assessments, or speaking — please get in touch.