Resilience of the State

A state that leaves around 80 percent of its administrative decisions to software is exactly as reliable as that software. In our book "Der selbstfahrende Staat" (Springer Gabler 2024, in German) we therefore treat resilience as a dimension in its own right, alongside autonomy, sustainability, and a human focus. This article answers the three questions administrations ask us most often on the subject: What happens in an outage? How is manipulation prevented and detected? And what fallback level remains if both occur?

The analog state is not the safe option

The most common objection to the self-driving state goes like this: paper does not go down. That is true, and it misses the point. In the book we describe the case of a Viennese municipal department reported by the Austrian broadcaster ORF on August 17, 2021: the phones ring all day and are almost never answered; of roughly 450 emails a day, at most 120 could be processed; employees suffered burnout or had themselves transferred. Legally and administratively, extending a residence permit is a simple procedure. It failed on volume, not on technology. Add to this what we note in the book with reference to reporting by the newspaper "Die Presse" in 2022: in Austria, around 45 percent of federal civil service staff will retire by the mid-2030s, in IT even earlier, and that number of skilled professionals cannot be replaced.

The analog state fails quietly. Backlogs grow, inquiries go unanswered, and there is no record of what was not processed. The digital state fails differently: visibly, all at once, and measurably. Resilience, then, is not a property of the medium but of the architecture. Whoever puts the state on software trades a creeping risk for an abrupt one and has to design for the abrupt risk. That is why, in the article Four Dimensions for the State, I described resilience as an architectural decision that cannot be bolted on afterward.

Outage: when the software stops

On July 19, 2024, a faulty update of a security product took down around 8.5 million Windows devices according to Microsoft; airports, hospitals, and public authorities were among those affected. The incident is instructive for administrations because there was no attack behind it, only a monoculture: the same software on every workstation, distributed from a single source, with no stage in between. I consider this dependence on individual vendors and components the underestimated risk of digital government.

In the book we answer the outage question with three architectural decisions. First, the self-driving state rests on a small number of digital basic services: registers, the digital file, communication, identity, payment. Registers must guarantee that critical data is always accessible and up to date, because they are essential to the functioning of the administration and the legal system. The availability question therefore does not arise separately for each of the hundreds of specialized procedures but for these few services, and a failed procedure must not take the register down with it.

Second, the self-driving state is indifferent to whether a register is kept centrally by the federal government or decentrally by the municipalities. Decentralized data pools can be virtually aggregated into a central pool, and a central pool can be made available decentrally through regionally restricted views; all that is needed is interfaces and a legally regulated authorization system. From a resilience perspective, federalism thus becomes redundancy: a municipality's register of residents keeps working when a federal component fails, and vice versa, as long as the interfaces are standardized and no level holds the only copy. Estonia operates a data embassy in Luxembourg that holds copies of critical registers outside its own territory. The European Blockchain Services Infrastructure, in which, according to our book, around 25 nodes were already active in 2023, one of them at the Austrian Federal Computing Center, follows the same principle of distributed infrastructure.

Third, the book relies on openness for the rule sets themselves: an open-source tax calculation core whose program code the state publishes free of charge, and digital twins of legislation that the legislature makes freely accessible to everyone. For resilience, what matters here is less the transparency than the independence: a rule set that belongs to the state and is openly available can be executed again by another provider, on another platform, and in emergency operation. A rule set that exists only inside one manufacturer's product fails together with the manufacturer.

Manipulation: prevent, detect, prove

There is no complete protection against manipulation, and the book does not claim one. What it says is this: logging and historization together do not make external manipulation impossible, but extremely difficult; if the logging were manipulated, this would be immediately detectable through the historization, and vice versa. That is a design principle, not a product. Two independent records that check each other must be kept separately, ideally by different bodies, so that nobody can alter both at the same time. The same idea underlies the article Explainability as a Principle of the Rule of Law: what is documented without gaps can also be defended against manipulation.

The second safeguard is the separation of powers, which we deliberately read as an architectural principle in the book. The formal rule sets, algorithms, and decision-making software applications are developed, operated, audited, and maintained completely separately by the legislature, the executive, and the judiciary. The judiciary audits the software platforms, the interfaces, and the data structures used for decisions, and it continuously analyzes the decisions made, including error and exception cases, so that decisions do not change over time and no unwanted bias or deviation from the law creeps in. A manipulation would therefore have to deceive three independent organizations at once.

No authority, no actor, no process may become so powerful that it overrides this principle. This also applies to the software that makes decisions.

The third safeguard concerns the rules themselves. In his guest contribution on the self-driving parliament, Jörn von Lucke points to hacker attacks on data centers and workstations in various parliaments and to the fact that language models can deliver distorted results, inadvertently or as a result of deliberate manipulation by antidemocratic forces at home or abroad. His conclusion is also ours: in legislation, decision-support systems at most, with approval remaining with people. For enforcement, a second principle follows that I consider central: the decision itself is made by a deterministic, versioned, and certified rule set, not by a continuously learning system. A manipulated version can then be proven by comparison with the version audited by the judiciary; with a constantly changing model there would be nothing to compare against.

Then there are the practical measures the book lists: encryption in transit and at rest to high standards, reviewed regularly by experts; strict access restrictions with two-factor authentication or biometric procedures; regular audits by independent specialists; software that recognizes typical patterns of misuse and reports them immediately; and limiting data storage to what is necessary for the state's tasks. That last point is underestimated: what is deleted automatically can be neither stolen nor falsified. The legal framework is now catching up. The AI Act, Regulation (EU) 2024/1689, in force since August 1, 2024, requires record-keeping (Art. 12), human oversight (Art. 14), and accuracy, robustness, and cybersecurity (Art. 15) for high-risk systems, which include many public administration applications. The NIS 2 Directive (EU) 2022/2555 explicitly counts public administration among the essential entities; its transposition deadline expired on October 17, 2024, and the national laws in Germany and Austria are still pending.

The fallback level: people, exceptions, analog paths

What remains if outage or manipulation occurs anyway? The book's answer is unspectacular and therefore sound: people. From the outset, the self-driving state provides that analog alternatives are offered or maintained for those who have no technical or cognitive access to digital services, and it lists analog assistance as a user interface in its own right alongside the public service wallet and the public service platforms. The fallback level is thus not an emergency plan in a drawer but part of regular operations. The same people who support citizens every day keep the administration capable of acting when the systems are down.

The same logic applies to the exceptional cases we described in the article Where Autonomy Reaches Its Limits. In the corporate tax example in the book, we expect that in 2035 more than 95 percent of cases will be calculated fully automatically; for the remaining 5 percent, human decisions become necessary, and these can be appealed through the classic chain of instances. What matters is the principle behind it: if a case meets no codified rule, the system must not invent one. It declines automated processing and routes the case to a person. That path is precisely the fallback level. What goes to people as an exception in normal operation goes to people as a whole in a crisis, through the same channel, with the same roles.

For this level to hold, three conditions must be met:

1. Defined, not improvised. For every basic service it is specified which service continues in which reduced form: the certificate of residence on paper, payment according to the last known status, identity verification at the counter.
2. Practiced, not merely described. Case workers must know the emergency mode. The example of the municipal department shows what happens when the only fallback level is overload.
3. Recordable afterward, not lost. What was decided manually in emergency mode is subsequently entered into the logging and historization. Otherwise the fallback level creates exactly the gap that a manipulation could exploit.

The following overview summarizes which architectural principles the book provides for the three questions and what administrations can check today.

What administrations can do today

None of these measures presupposes the self-driving state. They can be anchored in any digitalization project we currently support:

• Take inventory of basic services. Which five to ten services carry all specialized procedures, and what availability has actually been agreed for each of them?
• Name the monocultures. Which component sits in every workstation, every pipeline, every procedure, and what happens if exactly that one fails? The incident of July 2024 is a usable exercise scenario for this.
• Separate logging and historization. The decision log and the decision history are kept by different bodies and regularly checked against each other.
• Define automation boundaries per procedure. Decide automatically when all statutory conditions are met and all required data is present; route everything else to people. This boundary belongs in the specification, not in operations.
• Describe and practice the fallback level. Half a day of emergency operation per year reveals more than any concept paper, and it turns analog assistance into what it is in the book: a permanent component of the state.

In the state, resilience is not a technical side constraint but the precondition for citizens to trust an automated administration. A state that can show it survives an outage, proves a manipulation, and keeps a person reachable in every case may permit itself autonomy. One that cannot should stay with the digital form.

The next step

How basic services, registers, logging, and the separation of powers work together in the overall picture of the self-driving state is described in our book Der selbstfahrende Staat. How we support administrations in taking inventory of critical services, specifying automation boundaries, and building a robust fallback level is described on the page Public Administration.