OZG 2.0 & EfA: The Technical Architecture for the Digital State

The goal of the Online Access Act is ambitious: all administrative services should be digitally available. However, the implementation often failed in the first phase due to the fragmented federal structure. The solution for the second phase (OZG 2.0) is the EfA principle. One state develops a service (e.g., the parental allowance procedure) and provides it centrally as a cloud service for all other municipalities.

Technically, this is a massive scaling and integration problem. It requires a shift from local “island servers” to a modern, multi-tenant cloud-native platform.

The Technological Foundation: Cloud-Native & Multi-Tenancy

For a service like “vehicle registration” to work simultaneously for thousands of municipalities, the infrastructure must be based on three technical pillars:

1. Tenant Isolation at the Namespace Level

In an EfA architecture, many municipalities share the same physical infrastructure, but their data must remain strictly separated.

• Technology: In a Kubernetes cluster, services are isolated via Namespaces. Network Policies ensure at the Layer-3/4 level that, for example, the instance of the city of Cologne cannot access the database of the city of Hamburg.
• Storage: Each tenant receives its own encrypted storage areas via Persistent Volume Claims (PVC), which are logically and physically separated.

2. Standardized Interfaces (FIT-Connect)

The core problem of administration is interoperability. An online application must be securely transferred to the respective specialized procedure of the municipality.

• Technology: This is where the FIT-Connect standard comes into play. It uses an asynchronous, event-driven architecture. The infrastructure must provide robust API Gateways and Message Brokers (like NATS or Kafka) to securely transport end-to-end encrypted metadata and attachments.
• Certificate Management: Since communication between authorities must be highly secure, the platform automates certificate handling (e.g., via cert-manager) to ensure that every connection to the municipalities is TLS-encrypted and authenticated.

3. Scaling Through “One-for-Millions”

When a nationwide relevant service (e.g., an energy price allowance) is launched, the infrastructure must be able to scale from zero to millions of users within seconds.

• Technology: By using Horizontal Pod Autoscalers (HPA) and the cloud-native paradigm, computing resources can be dynamically allocated. The platform detects load peaks at the ingress controllers and scales up the necessary number of application instances before timeouts occur.

DevOps in Administration: GitOps as a Compliance Anchor

In the public sector, every change must be documented. Here, the GitOps approach (e.g., with ArgoCD or Flux) offers an invaluable advantage: the entire configuration of the administrative infrastructure is versioned in a Git repository.

• Audit Security: Every change to the system is traceable (Who changed which firewall rule and when?).
• Disaster Recovery: If an environment fails, it can be rebuilt exactly as documented within minutes – “Infrastructure as Code” makes the state resilient.

FAQ: The Technology Behind OZG & EfA

What is the difference between a “normal” cloud and an OZG cloud? An OZG cloud must meet the requirements of the BSI basic protection and the confidentiality protection order in addition to the technical standards. Moreover, the connection to the “administrative network” (NdB - Networks of the Federal Government) is a specific technical requirement to securely reach internal specialized procedures.

Why are Containers (Docker/Kubernetes) used for EfA services? Containers ensure that software runs exactly the same in the development environment as it does later in the service provider’s data center. This prevents the “It worked on my machine” problem when handing over software between different authorities or IT service providers.

How is data protection technically guaranteed for EfA services? Through a combination of technical isolation (Namespaces, Micro-Segmentation) and organizational separation. Additionally, technologies like “Confidential Computing” are often used, where data remains encrypted even during processing in memory.

How do municipalities connect their local specialized procedures to the EfA platform? Usually via secure VPN tunnels or dedicated lines to the administrative network. Communication takes place over standardized APIs (like XÖV standards), ensuring that the data formats between the central online service and the local database are compatible.

Can EfA services also be hosted with US cloud providers? This is legally controversial (keyword: Schrems II). The technical strategy therefore strongly leans towards sovereign platforms under German jurisdiction or private clouds of public IT service providers (like Dataport, Komm.ONE, or IT.NRW) to maintain full sovereignty over citizen data.