AGOV in Business Continuity Management: authentication for crisis situations
A highly available authentication solution is important. For particularly critical government functions, however, high availability alone is not enough. See also the video «AGOV degradation for requirements outside normal operations».
If a specialist application must continue to operate during a severe crisis, it is not sufficient to determine how reliably its authentication works. It must also be clear what happens when:
- individual communications infrastructures fail;
- AGOV itself is no longer available;
- ultimately, the target system can no longer be operated either.
AGOV therefore lends itself to a multi-layer resilience model.
Its basic principle is simple:
AGOV should provide critical target systems with secure authentication for as long as possible under adverse conditions. At the same time, particularly critical target systems must not depend on AGOV being available at all times.
This means that AGOV does not become a single point of failure, but rather a component of a broader IT Service Continuity and Business Continuity architecture.
First determine what is truly critical
Not every application requires such an architecture.
The starting point is therefore an assessment of the target system’s protection requirements and criticality. For every service, it must be clear:
- how long it can be dispensed with;
- what the consequences of a prolonged outage would be;
- which dependencies must continue to function even during a crisis.
This results in different requirements.
For many specialist applications, it is sufficient for AGOV itself to be operated with high availability. For a small number of particularly critical systems, however, it must be assumed that central infrastructure components may also fail.
Only these systems require the multi-layer architecture described below.
Multi-layer resilience model
Level 1: keep AGOV available for as long as possible
The first line of defence is the resilience of AGOV itself.
A central authentication infrastructure must not depend on a single data centre or a single infrastructure domain.
The target architecture therefore provides for a geographically and infrastructurally separated active-active setup in which part of the AGOV infrastructure can be operated outside the regular infrastructure of the Federal Administration.
A failure of one infrastructure domain should therefore not automatically result in a failure of authentication.
This approach protects against conventional technical outages, but it also has a security-policy dimension: in an extraordinary situation, central federal infrastructure may itself become a target of cyberattacks.
Resilience therefore means not only redundancy within the same environment, but also, wherever possible, avoiding common causes of failure.
Level 2: authentication must not depend on the mobile phone
In normal operation, AGOV is often used with a personal mobile device. For particularly critical functions, however, this should not be the only available authentication path.
The persons designated for these functions therefore also register a physical FIDO security key in their AGOV account.
This preserves the ability to log in, for example, if:
- mobile telecommunications are disrupted;
- the personal mobile device can no longer be used;
- the mobile authentication path is unavailable for other reasons.
Technical registration alone is not sufficient.
The security key must actually be:
- present;
- locatable;
- functional.
Organisational control is therefore an essential part of such a concept.
In periodic exercises, the persons concerned log in using their security key. A key that was registered years ago but can no longer be found or is defective today has no value in BCM.
Level 3: the target system must also be able to authenticate without AGOV
This is the decisive architectural step.
For particularly critical target systems, it is not enough for AGOV to be highly available. The target system must additionally have its own authentication layer that is independent of AGOV.
One option is to support FIDO directly in the target system.
Normal operation
During normal operation, authentication continues to take place through AGOV.
At the same time, the FIDO security key registered for the person concerned is also registered in the target system’s FIDO layer.
The target system therefore also knows the association between the person and the security key.
Operation when AGOV is unavailable
If AGOV becomes unavailable, the same person can use the same physical key directly with the target system.
The key principle is:
During normal operation, AGOV already prepares the conditions required for operation without AGOV.
The central identity infrastructure therefore does not merely create a dependency; it actively helps to make its own absence manageable.
Level 4: the fallback must actually be used on a regular basis
A fallback layer that technically exists is not yet an operational fallback layer.
Direct login to the target system must therefore be tested periodically in practice.
At the same time, the following must be recertified regularly:
- authorised persons;
- permissions;
- registered security keys.
A fallback that has never been tested is not a fallback.
A BCM test should therefore not merely check whether a server is reachable. It should cover the full process:
- person;
- physical security key;
- available end device;
- network connection;
- direct authentication;
- access to the specialist function that is actually required.
Only when this entire chain works is the fallback dependable.
Level 5: the public Internet can fail as well
Independence from AGOV alone is not sufficient.
If the target system can authenticate directly using FIDO but can only be reached through the public Internet, a central dependency still remains.
Correspondingly critical systems may therefore require dedicated or otherwise particularly resilient network connections.
In a crisis, the objective is to reduce the technical chain to as few components as possible:
end user → FIDO security key → end device → special-purpose network → target system
The fewer components are required, the fewer components can fail.
Power supply is also part of BCM
Power supply must also be included in the analysis.
A highly redundant data centre is of little use if neither the end device nor the communications infrastructure can be powered at the intended place of use.
BCM therefore does not end at the boundary of the data centre.
Level 6: severe crises require prepared emergency identities
An additional fallback layer goes one step further.
In the direct FIDO layer of a particularly critical target system, a limited number of physical security keys can be preregistered without assigning them permanently to a specific person.
These keys are stored in a decentralised, controlled and secure manner.
If, during a crisis, an authorised person is no longer able to act using their regular electronic identity, one of these prepared keys can be issued in accordance with a defined emergency process.
The association between the actual person and the technical emergency identity is then established outside the system, for example by means of paper-based documentation.
Requirements for emergency identities
Such a mechanism must of course not become an improvised master key.
It requires, in particular:
- a precisely defined scope of use;
- a clearly defined group of authorised persons;
- secure and, where possible, geographically distributed storage;
- an inventory of security keys;
- regulated issuance and return;
- four-eyes control wherever possible;
- traceable documentation of each assignment;
- regular testing;
- a binding process for subsequent reconciliation.
Once normal operation has been restored, the temporary assignments are reconstructed from this documentation and reconciled in the target system.
The process is deliberately analogue.
That is precisely its purpose: it should also work when the usual digital dependencies are no longer available.
Level 7: at some point it must also be possible to dispense with the target system
IT Service Continuity Management addresses how an IT service can continue to operate or be restored despite severe disruption.
Business Continuity Management must go further.
There must also be a scenario in which not only AGOV, but the target system itself is no longer available.
At that point, the solution cannot be yet another authentication method. The underlying business processes themselves must be able to switch to other means.
The final fallback layer may include, for example:
- autonomous means of communication;
- independent power supplies;
- physically available information;
- paper-based processes;
- previously defined competencies and decision-making powers.
Ultimately, government must remain capable of acting even without:
- AGOV;
- the relevant target systems;
- the Internet;
- mobile telecommunications;
- the regular power supply.
Four operating states instead of a single emergency solution
For practical implementation, the model can be reduced to four clearly distinguishable operating states.
1. Normal operation
The person authenticates normally through AGOV.
AGOV provides central authentication and supplies the target system with:
- the required identity;
- the required information.
2. Degraded operation
Parts of the infrastructure – for example mobile telecommunications – are unavailable.
Particularly important persons can continue to use AGOV with their physical FIDO security key.
3. Operation without AGOV
AGOV itself is unavailable.
The particularly critical target system is reached through an alternative network connection and directly authenticates the previously registered FIDO security keys.
For exceptional cases, prepared emergency identities can be used in accordance with a strictly controlled procedure.
4. Operation without the target system
The specialist system itself is also unavailable.
The predefined BCM process takes over.
The organisation continues to operate using the:
- technical;
- organisational;
- analogue
means that were prepared for precisely this situation.
This distinction prevents the most radical emergency mode from having to be activated immediately for every disruption.
The real strength lies in decoupling
The decisive idea behind this model is not a particular technical product.
It is the controlled decoupling of dependencies.
During normal operation, a central solution such as AGOV offers major advantages:
- centralised identity proofing;
- strong authentication;
- standardised processes;
- a shared trust infrastructure.
These functions therefore do not have to be built separately by every specialist application.
For a small number of particularly critical systems, however, this centralisation is complemented by targeted fallback layers.
This does not create a second parallel IAM for everyday operation.
The additional FIDO layer remains a deliberately restricted emergency function. Identities, security keys and permissions are prepared and reviewed regularly during normal operation, but are used directly only in the defined disruption scenario.
This avoids two opposite errors:
- not every specialist system once again becomes a complete IAM system in its own right;
- at the same time, it is not assumed that a central authentication platform can be guaranteed to remain available under every conceivable circumstance.
Resilience must be anchored organisationally
Technology alone is not enough.
For every particularly critical target system, at least the following must therefore be defined:
- responsibilities;
- activation criteria;
- exercise intervals;
- recertification;
- key management;
- communications channels;
- return to normal operation.
The final point is often underestimated.
After a crisis, the following must be brought back into the regular state in a controlled manner:
- temporary identities;
- exceptional permissions;
- manual assignments.
BCM therefore needs not only a path into emergency operation, but also a controlled path out of it.
Conclusion
AGOV can play a central role in the resilience of critical government services. The correct approach, however, is not to treat AGOV as indestructible.
The more robust model accepts from the outset that every technical component can fail.
Therefore:
- AGOV itself is designed for high availability and infrastructure redundancy;
- particularly important persons have a FIDO factor that is independent of the mobile phone;
- selected critical target systems can, where necessary, authenticate the same security keys directly;
- network and power dependencies are reduced;
- prepared emergency identities and documented manual processes are provided for severe crises;
- a final BCM layer also works without the digital target system.
Understood in this way, resilience is not a single replacement solution.
It is a chain of deliberately prepared degradation levels, with each level requiring less infrastructure than the one before it.
That is precisely why AGOV can be both a central authentication infrastructure and part of an architecture designed to continue functioning, if necessary, even without AGOV.