IT-Sicherheit · 19. Oktober 2026

IT-Planungsrat veröffentlicht Sicherheitsvorgaben für Verwaltungs-APIs: Was Behörden jetzt prüfen sollten

Der IT-Planungsrat hat am 16. Oktober 2026 die Sicherheitsvorgaben und die Zielarchitektur der Föderalen API-Autorisierungsinfrastruktur veröffentlicht. Damit liegt erstmals ein gemeinsamer Anforderungskatalog vor, wie Bund, Länder und Kommunen Programmierschnittstellen (APIs) mit OAuth 2.0 und OpenID Connect absichern sollen. Die Vorgaben richten sich ausdrücklich an alle Organisationseinheiten, IT-Dienstleister und Entwicklungsteams, die APIs im Kontext der öffentlichen Verwaltung konzipieren, entwickeln, betreiben oder nachnutzen. Noch sind sie nicht verbindlich. Eine Projektgruppe unter Beteiligung von BMDS und BSI bereitet die Verbindlichkeit aber bereits vor. Wer heute Fachverfahren, Onlinedienste oder Schnittstellen beschafft oder modernisiert, sollte die Vorgaben deshalb schon jetzt als Maßstab nehmen.

Grundlage ist der Beschluss B-2026/16-IT aus der 50. Sitzung des IT-Planungsrats vom 17. Juni 2026, mit dem der IT-Planungsrat die föderalen Sicherheitsvorgaben zur Kenntnis genommen hat. Das Vorhaben gehört zu den ersten 27 Projekten, die der IT-Planungsrat im Juni 2025 zur Umsetzung der föderalen Digitalstrategie beschlossen hat. Federführend waren das Land Sachsen-Anhalt und die FITKO (Föderale IT-Kooperation).

Was sich ändert

Im Kern stehen zwei Ergebnisse mit unterschiedlichem Zweck. Die Sicherheitsvorgaben gelten für alle APIs der öffentlichen Verwaltung, bei denen OAuth 2.0, OAuth 2.1 oder OpenID Connect eingesetzt werden können. Die Zielarchitektur beschreibt, wie Fachverfahren und Onlinedienste künftig standardisiert an föderale Basisdienste wie Postfächer oder Bezahldienste angebunden werden. Statt vieler Einzelanbindungen soll ein gemeinsames Sicherheitsniveau entstehen.

Die Vorgaben sind nach den Schutzbedarfskategorien des BSI-Standards 200-2 gegliedert. Vor der Implementierung einer API muss eine Schutzbedarfsfeststellung nach diesem Standard erfolgen. Daraus ergibt sich, welches der beiden Profile gilt.

Schutzbedarf normal

Das Profil für den normalen Schutzbedarf baut auf dem „Best Current Practice for OAuth 2.0 Security“ (RFC 9700) auf und übernimmt einzelne Empfehlungen aus OAuth 2.1, das noch im Entwurfsstadium ist. Wesentliche Punkte:

• Verbotene Abläufe: Implicit Grant und Resource Owner Password Credentials Grant dürfen nicht verwendet werden.
• PKCE für alle Clients: Öffentliche und vertrauliche Clients müssen PKCE einsetzen, empfohlen ist die Methode S256. Authorization Server müssen PKCE-Downgrade-Angriffe abwehren.
• Redirect-Schutz: Redirect-URIs werden mit exakter Zeichenfolge verglichen, offene Weiterleitungen sind unzulässig, CSRF muss verhindert werden.
• Token-Schutz: Sendergebundene Access Token über Mutual TLS oder DPoP sollen eingesetzt werden. Die Rechte eines Access Token sollen auf das notwendige Minimum beschränkt sein.
• Transportverschlüsselung: TLS nach BSI TR-02102-2 ist Pflicht, Redirect-URIs mit http-Schema sind bis auf eng definierte Ausnahmen für native Apps ausgeschlossen.

Für REST-APIs gelten diese Vorgaben immer. Für gRPC und GraphQL gelten sie, sobald die Nutzer der Schnittstelle autorisiert werden müssen. SOAP-Schnittstellen sind ausgenommen, solange kein OAuth eingesetzt wird. Bilden sie nutzerseitige Autorisierungen auf anderem Weg ab, ist eine gleichwertige Sicherheit nachzuweisen.

Schutzbedarf hoch und sehr hoch

Für hohen und sehr hohen Schutzbedarf gilt ein Hochsicherheitsprofil, das aus dem FAPI 2.0 Security Profile der OpenID Foundation abgeleitet und für die deutsche Verwaltung erweitert wurde. Die Anforderungen sind deutlich strenger:

• Authorization Server dürfen nur vertrauliche Clients unterstützen und nur sendergebundene Access Token ausstellen, über Mutual TLS oder DPoP.
• Clients müssen sich über Mutual TLS oder private_key_jwt authentisieren.
• Pushed Authorization Requests (PAR) sind verpflichtend. Autorisierungsanfragen ohne PAR werden abgelehnt.
• Autorisierungscodes gelten höchstens 60 Sekunden, PAR-Referenzen weniger als 600 Sekunden.
• Für signierte Token sind PS256, ES256 oder EdDSA (Ed25519) vorgeschrieben. RSA-Schlüssel müssen die Mindestlänge der jeweils aktuellen BSI TR-02102-2 erfüllen, das Dokument nennt für die Version 2026-01 beispielhaft 3000 Bit.
• Der Übergang zu Post-Quanten-Kryptografie nach BSI TR-02102-2 muss bis Ende 2030 vollzogen sein.

Bemerkenswert für den Betrieb: Betreibt ein Dienstleister mehrere Clients auf derselben Software, etwa ein Landes-IT-Dienstleister für mehrere Behörden, sollten diese Clients auf getrennten Servern laufen, im Container-Betrieb nach den Grundschutz-Bausteinen APP.4.4 und SYS.1.6. Eine Bündelung von Client-Zugangsdaten darf die Schutzziele nicht unterlaufen.

Folgen

Noch handelt es sich um Vorgaben ohne bindende Wirkung. Das Rahmendokument beschreibt aber bereits, was nach Herstellung der Verbindlichkeit gelten soll: Die zutreffenden Sicherheitsvorgaben sind verpflichtend einzuhalten, Abweichungen von SOLL-Anforderungen sind zu dokumentieren und zu begründen, Abweichungen von MUSS-Anforderungen sind nicht zulässig.

Der Beschluss B-2026/16-IT legt den Weg dorthin fest. Das Föderale IT-Architekturboard bildet unter Einbeziehung von BMDS und BSI eine Projektgruppe. Sie erarbeitet einen Vorschlag zur Verbindlichkeit, einschließlich der Beachtung der Vorgaben im Deutschland-Stack, eines Zeitplans, möglicher Ausnahmen und Übergangsfristen sowie Unterstützungsleistungen wie Leitfäden und Schulungen. Der Vorschlag soll dem IT-Planungsrat zu seiner 52. Sitzung vorgelegt werden. Parallel pilotiert die FITKO zentrale Elemente der Zielarchitektur mit ausgewählten Basisdiensten und FIT-Connect und legt Zeitplanung, Kostenschätzung, Betreibermodell und Wirtschaftlichkeitsbetrachtung vor. Ein Abgleich mit dem BSI-Grundschutz++ ist ausdrücklich vorgesehen.

Für Behörden heißt das: Schnittstellen, die heute neu gebaut oder vergeben werden, laufen voraussichtlich noch in ihrer Betriebszeit in eine Pflicht hinein. Wer jetzt Implicit Grant, Passwort-Grant oder unkontrollierte Redirects einführt, plant die Nachbesserung gleich mit ein. Für Verfahren mit hohem Schutzbedarf kann der Abstand zwischen bestehenden OAuth-Installationen und dem FAPI-2.0-Profil beträchtlich sein, insbesondere bei PAR, sendergebundenen Token und asymmetrischer Client-Authentisierung.

Was jetzt zu tun ist

1. API-Bestand erfassen: Welche Schnittstellen nutzen OAuth oder OpenID Connect, welche sind REST, gRPC, GraphQL oder SOAP, und wer betreibt sie? Ohne Inventar lässt sich der Geltungsbereich nicht bestimmen.
2. Schutzbedarf feststellen: Für jede API die Schutzbedarfsfeststellung nach BSI-Standard 200-2 dokumentieren. Sie entscheidet über das anzuwendende Profil.
3. Lückenanalyse gegen MUSS-Anforderungen: Verbotene Grant Types, PKCE, Redirect-Prüfung und TLS-Konfiguration zuerst prüfen, bei hohem Schutzbedarf zusätzlich PAR, Sender-Binding, Client-Authentisierung und Algorithmen.
4. Vergaben anpassen: In Leistungsbeschreibungen für Fachverfahren, Onlinedienste und Plattformen die Sicherheitsvorgaben des IT-Planungsrats als Anforderung aufnehmen, mit dem jeweils geltenden Schutzbedarfsprofil und der Pflicht, Abweichungen von SOLL-Anforderungen zu begründen.
5. Abnahme prüfbar machen: Die Vorgaben eignen sich als Testgrundlage. Negativtests gehören dazu: Wird ein Implicit Grant abgelehnt, scheitert ein Redirect mit abweichender URI, wird ein wiederverwendeter Autorisierungscode zurückgewiesen, greift der Schutz gegen PKCE-Downgrade?
6. Termine verfolgen: Die FITKO stellt die Ergebnisse am 27. Oktober 2026 in ihrer Online-Infoveranstaltung „FITKO stellt vor“ vor. Der Vorschlag zur Verbindlichkeit ist für die 52. Sitzung des IT-Planungsrats angekündigt.

Wer bereits an der Umstellung auf Post-Quanten-Kryptografie arbeitet, sollte die Algorithmenwahl der API-Absicherung in dieselbe Planung aufnehmen.

MUSS, SOLL und begründete Abweichungen

Die Sicherheitsvorgaben arbeiten mit MUSS- und SOLL-Anforderungen und verlangen nach Eintritt der Verbindlichkeit, dass jede Abweichung von einer SOLL-Anforderung dokumentiert und begründet wird. Das ist im Kern eine Aufgabe der Anforderungs- und Testdokumentation.

Wer die Vorgaben je Schutzbedarfsprofil als prüfbare Anforderungen anlegt, mit Testfällen und Abnahmeprotokollen verknüpft und Abweichungen mit Begründung festhält, kann für jede API zeigen, welche Vorgabe sie erfüllt. Weil Schnittstellen laufend weiterentwickelt werden, gehört dazu auch, die Prüfungen nach jeder Änderung zu wiederholen. So ist der Nachweis bereits vorhanden, wenn die Verbindlichkeit kommt.