Veröffentlicht am 1. Oktober 2026

AGOV im Business Continuity Management: Authentisierung für den Krisenfall

Eine hochverfügbare Authentisierungslösung ist wichtig. Für besonders kritische staatliche Aufgaben reicht Hochverfügbarkeit allein jedoch nicht aus. Siehe dazu auch das Video «AGOV-Degradation für Anforderungen ausserhalb der normalen Lage».

Wenn eine Fachanwendung auch in einer schweren Krise weiterbetrieben werden muss, muss nicht nur geklärt sein, wie zuverlässig ihre Authentisierung funktioniert. Es muss ebenso geklärt sein, was geschieht, wenn:

• inzelne Kommunikationsinfrastrukturen ausfallen,
• AGOV selbst nicht mehr verfügbar ist oder
• schliesslich auch das Zielsystem nicht mehr betrieben werden kann.

Bei AGOV lässt sich deshalb ein mehrstufiges Resilienzmodell aufbauen.

Das Grundprinzip ist einfach:

AGOV soll kritische Zielsysteme unter widrigen Umständen möglichst lange mit einer sicheren Authentisierung versorgen. Gleichzeitig dürfen besonders kritische Zielsysteme nicht davon abhängig sein, dass AGOV jederzeit verfügbar bleibt.

Damit wird AGOV nicht zum Single Point of Failure, sondern zu einem Bestandteil einer umfassenderen IT-Service-Continuity- und Business-Continuity-Architektur.

Zuerst muss klar sein, was tatsächlich kritisch ist

Nicht jede Anwendung benötigt eine solche Architektur. Ausgangspunkt ist deshalb die Schutzbedarfs- und Kritikalitätsanalyse des Zielsystems. Für jeden Dienst muss geklärt werden:

• Wie lange kann auf den Dienst verzichtet werden?
• Welche Konsequenzen hätte ein längerer Ausfall?
• Welche Abhängigkeiten müssen auch in einer Krisensituation weiterhin funktionieren?

Daraus ergeben sich unterschiedliche Anforderungen.

Bei vielen Fachanwendungen genügt es, dass AGOV selbst hochverfügbar betrieben wird. Bei einzelnen besonders kritischen Systemen muss hingegen davon ausgegangen werden, dass auch zentrale Infrastrukturkomponenten ausfallen können.

Erst für diese Systeme ist die nachfolgend beschriebene mehrstufige Architektur erforderlich.

Mehrstufiges Resilienzmodell

Stufe 1: AGOV selbst möglichst lange verfügbar halten

Die erste Verteidigungslinie ist die Resilienz von AGOV selbst.

Eine zentrale Authentisierungsinfrastruktur darf nicht von einem einzigen Rechenzentrum oder einer einzigen Infrastrukturdomäne abhängen.

Das Zielbild sieht deshalb einen geografisch und infrastrukturell getrennten Aktiv-Aktiv-Betrieb vor, bei dem ein Teil der AGOV-Infrastruktur ausserhalb der regulären Infrastruktur der Bundesverwaltung betrieben werden kann.

Damit soll ein Ausfall einer Infrastrukturdomäne nicht automatisch zum Ausfall der Authentisierung führen.

Dieser Ansatz schützt gegen klassische technische Störungen, hat aber auch eine sicherheitspolitische Dimension: Zentrale Bundesinfrastrukturen können in einer ausserordentlichen Lage selbst zum Ziel eines Cyberangriffs werden.

Resilienz bedeutet deshalb nicht nur Redundanz innerhalb derselben Umgebung, sondern möglichst auch die Vermeidung gemeinsamer Ausfallursachen.

Stufe 2: Die Authentisierung darf nicht vom Mobiltelefon abhängen

AGOV wird im Normalbetrieb häufig mit einem persönlichen Mobilgerät verwendet. Für besonders kritische Funktionen sollte dieses jedoch nicht der einzige verfügbare Authentisierungsweg sein.

Die dafür vorgesehenen Personen registrieren deshalb zusätzlich einen physischen FIDO-Sicherheitsschlüssel in ihrem AGOV-Konto.

Damit bleibt die Anmeldung beispielsweise auch dann möglich, wenn:

• die Mobiltelefonie beeinträchtigt ist,
• das persönliche Mobilgerät nicht mehr verwendet werden kann oder
• der mobile Authentisierungsweg aus anderen Gründen nicht verfügbar ist.

Entscheidend ist dabei nicht nur die technische Registrierung.

Der Sicherheitsschlüssel muss:

• tatsächlich vorhanden,
• auffindbar und
• funktionsfähig sein.

Deshalb gehört zu einem solchen Konzept zwingend eine organisatorische Kontrolle.

In periodischen Übungen melden sich die betroffenen Personen mit ihrem Sicherheitsschlüssel an. Ein Schlüssel, der vor Jahren registriert wurde, heute aber nicht mehr auffindbar oder defekt ist, besitzt im BCM keinen Wert.

Stufe 3: Das Zielsystem muss auch ohne AGOV authentisieren können

Hier liegt der entscheidende architektonische Schritt.

Bei besonders kritischen Zielsystemen genügt es nicht, dass AGOV hochverfügbar ist. Das Zielsystem muss zusätzlich über eine eigene, von AGOV unabhängige Authentisierungsschicht verfügen.

Eine Möglichkeit besteht darin, FIDO direkt im Zielsystem zu unterstützen.

Normalbetrieb

Im Normalbetrieb erfolgt die Authentisierung weiterhin über AGOV.

Gleichzeitig wird der für die betreffende Person registrierte FIDO-Sicherheitsschlüssel zusätzlich in der FIDO-Schicht des Zielsystems hinterlegt.

Damit kennt auch das Zielsystem selbst die Zuordnung zwischen Person und Sicherheitsschlüssel.

Betrieb bei Ausfall von AGOV

Fällt AGOV aus, kann dieselbe Person denselben physischen Sicherheitsschlüssel direkt gegenüber dem Zielsystem verwenden.

Das zugrunde liegende Prinzip lautet:

AGOV richtet im Normalbetrieb bereits die Voraussetzungen für einen Betrieb ohne AGOV ein.

Die zentrale Identitätsinfrastruktur schafft damit nicht nur Abhängigkeit, sondern hilft aktiv dabei, ihre eigene Abwesenheit beherrschbar zu machen.

Stufe 4: Der Fallback muss regelmässig wirklich benutzt werden

Eine technisch vorhandene Rückfallebene ist noch keine betriebsfähige Rückfallebene.

Die direkte Anmeldung am Zielsystem muss deshalb periodisch praktisch getestet werden.

Gleichzeitig müssen regelmässig rezertifiziert werden:

• berechtigte Personen,
• Berechtigungen und
• registrierte Sicherheitsschlüssel.

Eine Rückfallebene, die nie getestet wurde, ist keine Rückfallebene.

Ein BCM-Test sollte deshalb nicht nur prüfen, ob ein Server erreichbar ist. Er sollte den vollständigen Ablauf umfassen:

• Person
• physischer Sicherheitsschlüssel
• verfügbares Endgerät
• Netzwerkverbindung
• direkte Authentisierung
• Zugriff auf die tatsächlich benötigte Fachfunktion

Erst wenn diese gesamte Kette funktioniert, ist der Fallback belastbar.

Stufe 5: Auch das öffentliche Internet kann ausfallen

Die Unabhängigkeit von AGOV allein genügt nicht.

Wenn das Zielsystem zwar direkt mit FIDO authentisieren kann, aber ausschliesslich über das öffentliche Internet erreichbar ist, besteht weiterhin eine zentrale Abhängigkeit.

Für entsprechend kritische Systeme können deshalb dedizierte oder anderweitig besonders resiliente Netzanbindungen erforderlich sein.

Das Ziel ist, die technische Kette im Krisenfall auf möglichst wenige Komponenten zu reduzieren:

Endbenutzer → FIDO-Sicherheitsschlüssel → Endgerät → Spezialnetz → Zielsystem

Je weniger Komponenten benötigt werden, desto weniger Komponenten können ausfallen.

Auch die Stromversorgung gehört zum BCM

Neben der Netzwerkverbindung muss auch die Stromversorgung berücksichtigt werden.

Ein mehrfach redundantes Rechenzentrum ist wenig hilfreich, wenn am vorgesehenen Einsatzort weder das Endgerät noch die Kommunikationsinfrastruktur mit Energie versorgt werden können.

BCM endet deshalb nicht an der Grenze des Rechenzentrums.

Stufe 6: Für den schweren Krisenfall braucht es vorbereitete Notfallidentitäten

Noch weiter geht eine zusätzliche Rückfallebene.

In der direkten FIDO-Schicht eines besonders kritischen Zielsystems kann eine begrenzte Anzahl physischer Sicherheitsschlüssel bereits im Voraus registriert werden, ohne sie dauerhaft einer bestimmten Person zuzuordnen.

Diese Schlüssel werden dezentral, kontrolliert und sicher aufbewahrt.

Ist im Krisenfall eine berechtigte Person nicht mehr mit ihrer regulären elektronischen Identität handlungsfähig, kann ihr ein solcher vorbereiteter Schlüssel nach einem definierten Notfallprozess ausgegeben werden.

Die Zuordnung zwischen der tatsächlichen Person und der technischen Notfallidentität erfolgt dann ausserhalb des Systems, beispielsweise mittels papierbasierter Dokumentation.

Anforderungen an Notfallidentitäten

Ein solches Verfahren darf kein improvisierter Generalschlüssel sein.

Erforderlich sind insbesondere:

• ein exakt definierter Kreis von Anwendungsfällen,
• ein klar definierter Kreis berechtigter Personen,
• sichere und möglichst geografisch verteilte Aufbewahrung,
• Inventarisierung der Sicherheitsschlüssel,
• geregelte Ausgabe und Rücknahme,
• soweit möglich Vieraugenkontrolle,
• nachvollziehbare Dokumentation jeder Zuordnung,
• regelmässige Tests und
• ein verbindlicher Prozess zur nachträglichen Bereinigung.

Nach Wiederherstellung des Normalbetriebs werden die temporären Zuordnungen anhand dieser Dokumentation nachvollzogen und im Zielsystem bereinigt.

Das Verfahren ist bewusst analog.

Genau darin liegt sein Zweck: Es soll auch dann funktionieren, wenn die üblichen digitalen Abhängigkeiten nicht mehr verfügbar sind.

Stufe 7: Irgendwann muss auch das Zielsystem aufgegeben werden können

IT Service Continuity Management beantwortet die Frage, wie ein IT-Service trotz schwerer Störungen weiterbetrieben oder wiederhergestellt werden kann.

Business Continuity Management muss noch weitergehen.

Es muss auch ein Szenario geben, in dem nicht nur AGOV, sondern das eigentliche Zielsystem nicht mehr zur Verfügung steht.

Dann kann die Lösung nicht ein weiteres Authentisierungsverfahren sein. Dann müssen die fachlichen Prozesse selbst auf andere Mittel ausweichen können.

Als letzte Rückfallebene kommen beispielsweise infrage:

• autarke Kommunikationsmittel,
• unabhängige Energieversorgung,
• physisch verfügbare Informationen,
• Papierprozesse und
• zuvor definierte Kompetenzen und Entscheidungsbefugnisse.

Am Ende muss staatliche Handlungsfähigkeit auch ohne folgende Komponenten möglich bleiben:

• AGOV,
• die betreffenden Zielsysteme,
• öffentliches Internet,
• Mobiltelefonie und
• reguläre Stromversorgung.

Vier Betriebszustände statt einer einzigen Notfalllösung

Für die praktische Umsetzung lässt sich das Modell auf vier klar unterscheidbare Betriebszustände reduzieren.

1. Normalbetrieb

Die Person authentisiert sich regulär über AGOV.

AGOV übernimmt die zentrale Authentisierung und liefert dem Zielsystem:

• die benötigte Identität und
• die erforderlichen Informationen.

2. Degradierter Betrieb

Teile der Infrastruktur – beispielsweise die Mobiltelefonie – sind nicht verfügbar.

Besonders wichtige Personen können AGOV weiterhin mittels ihres physischen FIDO-Sicherheitsschlüssels verwenden.

3. Betrieb ohne AGOV

AGOV selbst ist nicht verfügbar.

Das besonders kritische Zielsystem wird über eine alternative Netzanbindung erreicht und authentisiert die zuvor registrierten FIDO-Sicherheitsschlüssel direkt.

Für ausserordentliche Fälle können vorbereitete Notfallidentitäten nach einem streng geregelten Verfahren eingesetzt werden.

4. Betrieb ohne Zielsystem

Auch das Fachsystem steht nicht mehr zur Verfügung.

Der vorab definierte BCM-Prozess übernimmt.

Die Organisation arbeitet mit denjenigen:

• technischen,
• organisatorischen und
• analogen Mitteln

weiter, die für genau diesen Fall vorbereitet wurden.

Diese Trennung ist wichtig. Sie verhindert, dass für jedes Störungsszenario sofort der radikalste Notfallmodus aktiviert werden muss.

Die eigentliche Stärke liegt in der Entkopplung

Der entscheidende Gedanke dieses Modells ist nicht ein einzelnes technisches Produkt.

Es ist die kontrollierte Entkopplung von Abhängigkeiten.

Im Normalbetrieb bietet eine zentrale Lösung wie AGOV grosse Vorteile:

• zentrale Identitätsprüfung,
• starke Authentisierung,
• einheitliche Prozesse und
• eine gemeinsame Vertrauensinfrastruktur.

Diese Funktionen müssen dadurch nicht von jeder Fachanwendung selbst aufgebaut werden.

Bei wenigen besonders kritischen Systemen wird diese Zentralisierung jedoch durch gezielte Rückfallebenen ergänzt.

Dadurch entsteht kein zweites paralleles IAM für den Alltag.

Die zusätzliche FIDO-Schicht bleibt eine bewusst eingeschränkte Notfallfunktion. Identitäten, Sicherheitsschlüssel und Berechtigungen werden im Normalbetrieb vorbereitet und regelmässig überprüft, aber erst im definierten Störungsfall direkt verwendet.

Damit werden zwei gegensätzliche Fehler vermieden:

• Nicht jedes Fachsystem wird wieder zu einem vollständigen eigenen IAM-System.
• Gleichzeitig wird nicht davon ausgegangen, dass eine zentrale Authentisierungsplattform unter allen denkbaren Umständen garantiert verfügbar bleiben kann.

Resilienz muss organisatorisch verankert sein

Technik allein genügt nicht.

Für jedes besonders kritische Zielsystem müssen deshalb mindestens folgende Punkte festgelegt werden:

• Verantwortlichkeiten,
• Aktivierungskriterien,
• Übungsintervalle,
• Rezertifizierung,
• Schlüsselverwaltung,
• Kommunikationswege und
• Rückkehr in den Normalbetrieb.

Gerade der letzte Punkt wird häufig unterschätzt.

Nach einer Krise müssen:

• temporäre Identitäten,
• besondere Berechtigungen und
• manuelle Zuordnungen

wieder kontrolliert in den regulären Zustand überführt werden können.

BCM benötigt deshalb nicht nur einen Weg in den Notbetrieb, sondern ebenso einen kontrollierten Weg aus dem Notbetrieb.

Fazit

AGOV kann eine zentrale Rolle in der Resilienz kritischer staatlicher Dienste übernehmen. Der richtige Ansatz besteht jedoch nicht darin, AGOV für unzerstörbar zu erklären.

Das robustere Modell akzeptiert von Anfang an, dass jede technische Komponente ausfallen kann.

Deshalb wird:

• AGOV selbst hochverfügbar und infrastrukturell redundant aufgebaut,
• besonders wichtigen Personen ein vom Mobiltelefon unabhängiger FIDO-Faktor bereitgestellt,
• ausgewählten kritischen Zielsystemen ermöglicht, dieselben Sicherheitsschlüssel bei Bedarf direkt zu authentisieren,
• die Abhängigkeit von Netzwerk und Stromversorgung minimiert,
• für schwere Krisen mit vorbereiteten Notfallidentitäten und dokumentierten manuellen Prozessen vorgesorgt und
• eine letzte BCM-Stufe vorgesehen, die auch ohne das digitale Zielsystem funktioniert.

So verstanden ist Resilienz keine einzelne Ersatzlösung.

Resilienz ist eine Kette bewusst vorbereiteter Degradationsstufen, bei der jede Stufe weniger Infrastruktur voraussetzt als die vorhergehende.

Genau deshalb kann AGOV gleichzeitig eine zentrale Authentisierungsinfrastruktur sein und Teil einer Architektur, die darauf vorbereitet ist, notfalls auch ohne AGOV weiterzufunktionieren.