Diese Seite wird entsprechend des aktuellen Kenntnisstandes stetig erweitert. Wir empfehlen Ihnen diese Seite zu "beobachten", um bei Aktualisierungen informiert zu werden.

Sollten Ihnen weitere hier nicht aufgeführte Probleme bekannt sein, so bitten wir Sie, diese über das ServiceDesk Portal zu melden.

Dieses Konzept richtet sich an Gesellschafter, Anbieter und Dienstleister in der TI.

Das Vorgehen beschreibt, wie der Übergang von RSA zu ECC in der TI während der Migration erreicht wird. Der Fokus liegt dabei auf dezentralen Komponenten.

Ein Reporting und eine rollierende Zeitplanung ist ausdrücklich nicht Bestandteil dieses Dokuments. Die Zeitplanung zum Migrationsvorgehen und den FAQ befindet sich im Bereich Planung- und Umsetzungshorizont.

Version	Stand	Kap./Seite	Grund der Änderung, besondere Hinweise	Bearbeitung
1.0.0	17 Oct 2025		initiale Erstellung	gematik
2.0.0	19 Nov 2025		Kapitel: Kontrollierte Außerbetriebnahme von RSA im Rahmen der ECC-Migration	gematik

Inhalt:

Genutzte Mechanismen

Um die Nutzung von RSA2048 durch die Nutzung von ECC-256 in der TI zu ersetzen, kommen folgende Mechanismen zum Einsatz:

Tausch von Hardware (HBA, SMC-B, gSMC-KT, Konnektoren)
Update von Software bzw. Firmware (eHealth-KT, Konnektoren, Primärsystem, KIM-Clientmodule)
Anpassungen im Vertrauensraum der TSL / BNetzA-VL
Widerruf / Sperrung von Zertifikaten

Diese dienen dazu:

Voraussetzungen: die notwendigen Voraussetzungen zu schaffen,
Durchsetzung: die Nutzung von RSA2048 auf ECC-256 umzustellen und
Abschaltung: die Nutzung von RSA2048 final zu unterbinden.

Diese Phasen werden im weiteren für jede relevante Komponente der TI definiert.

Komponenten

Wie Voraussetzungen, Durchsetzung und Abschaltung für die einzelnen Komponente der TI umgesetzt werden, wird nachfolgend erläutert. Neben den Maßnahmen wird dabei auch auf die Aspekte Monitoring und indirekt auf zeitliche Terminierung eingegangen:

Vorgesehenes Monitoring: Messungen und Auswertungen, die beschreiben wie die gematik überwachen kann, in welchem Maße Voraussetzungen erreicht und Maßnahmen umgesetzt wurden. Dazu stehen der gematik folgende Möglichkeiten zur Verfügung:
1. Konnektordaten: Jeder Konnektor liefert täglich verschiedene Betriebsdaten aus seiner lokalen Betriebsumgebung an die BDE-Senke der TI.
2. Betriebsdaten: Jeder Dienst der TI liefert für diesen definierte Betriebsdaten in spezifizierten Zeitabständen an die BDE-Senke der TI.
3. Manuelles Tracking
Abhängigkeiten: Als Voraussetzung für eine Terminierung, zu wann, ob/in welchen Schritten vorgegangen werden soll

In diesem Dokument wird lediglich beschrieben, welche Größen von der gematik überwacht werden und welche zeitlichen Abhängigkeiten bestehen. Die Ergebniss dieses Monitorings sind für gematik-interne Verwendung vorgesehen und hier nur zur Übersicht aufgelistet. Ob dazu konkrete Reports und eine rollierende Planung veröffentlicht werden, ist hier nicht festgelegt - jedenfalls ist es nicht Teil dieses Dokuments.

Konnektor

Voraussetzungen

Hardware

Voraussetzung für die Nutzung von ECC an den Schnittstellen zum Zugangsdienst und den Kartenterminals sind dualpersonalisierte Konnektoren. Diese Konnektoren beinhalten sowohl RSA- als auch ECC-Zertifikate. Einboxkonnektoren (EBK) haben diese Zertifikate auf der im Gerät intern fest verbauten gSMC-K Gerätekarte bzw. bei laufzeitverlängerten Konnektoren innerhalb des nichtflüchtigen Gerätespeichers zur Verfügung. Highspeedkonnektoren (HSK) haben diese Zertifikate innerhalb der gSM-K Struktur auf einem HSM in einem Rechenzentrum hinterlegt, auf welche nur der HSK exklusiv Zugriff hat. Seit 5 Jahren werden ausschließlich dualpersonalisierte Konnektoren verkauft.

Alle Konnektoren mit RSA-only personalisierten gSMC-K laufen am 31.12.2025 ab und können danach nicht mehr verwendet werden. Solche Konnektoren sind ausschließlich vom Produkttyp EBK und die Ablösung dieser Konnektoren wird von der gematik überwacht. Somit ist ab dem 01.01.2026 die hardwareseitige Voraussetzung für die Ablösung von RSA durch ECC gegeben.

Vorgesehenes Monitoring: Konnektordaten → Konnektorbestand RSA-Only-Konnektoren

Firmware PTV5

Im Feld ist Stand Sept. 2025 flächendeckend PTV5 im Einsatz. Die Firmware der PTV5 verwendet im Default RSA2048, ist aber in der Lage, ECC-Artefakte zu verarbeiten und bei entsprechendem Aufruf ECC-Artefakte zu erzeugen.

Vorgesehenes Monitoring: Konnektordaten → Verbreitungsgrad PTV5

Durchsetzung

Firmware PTV6

PTV6 Konnektoren verhalten sich nach dem ECC-Preferred Prinzip. Dabei wird per Default ECC verwendet. Nur wenn eine angesprochene Karte bzw. Identitätsträger kein ECC-Schlüsselmaterial enthält, fällt die Software automatisch auf RSA2048 zurück. Eine Steuerung durch Aufrufparameter über die Schnittstellen ist dabei nicht möglich. Die Verarbeitung von bestehenden RSA-Artefakten ist mit der Firmware weiterhin gegeben.

PTV6 stellt die VPN-Verbindung und die KT-Verbindung eigenständig auf ECC um, wenn die Voraussetzungen dafür gegeben sind:

Für die VPN-Verbindung muss der Konnektor dualpersonalisiert sein.
Für die KT-Verbindung muss der Konnektor dualpersonalisiert, die KT-Firmware aktuell sein und eine G2.1-gSMC-KT stecken.

Vorgesehenes Monitoring: Konnektordaten → Verbreitungsgrad PTV6, Verbreitungsgrad PTV2

Maßnahme PTV6 Rollout

Beschleunigter Rollout von PTV6 bzw. dem funktional identischen HSK PTV2 sobald diese Firmwareversionen zugelassen sind. Die gematik misst den Verbreitungsgrad von PTV6 im Feld.

Abhängigkeiten: PTV6-Konnektor-Rollout darf erst nach umfassenden Ausrollen von KIM 1.5.2-9 im Feld erfolgen.

Vorgesehenes Monitoring: Konnektordaten → Verbreitungsgrad PTV6, Verbreitungsgrad PTV2

Abschaltung

Sobald G2.0 gSMC-KT im Feld gegen G2.1-Karten getauscht wurden und kein RSA2048 mehr in den Verbindungen zu Kartenterminals verwendet wird, werden RSA-Zertifikate aus den Laufzeitverlängerungspaketen entfernt und die RSA2048-Zertifikate der gSMC-K aus dem Vertrauensraum der TI entfernt, indem die RSA KOMP-CAs für C.SAK.AUT und C.SMKT.AUT aus der TI-TSL entfernt werden.

Weiterhin müssen auch RSA-Zertifikate der gSM(C)-K bis zur Abschaltung mit der Laufzeitverlängerung verlängert werden und prüfbar sein, um die KT-Verbindung mit RSA weiter zu unterstützen. Somit werden erst mit der Abschaltung die RSA-Zertifikate aus den Laufzeitverlängerungspaketen entfernt.

Abhängigkeiten:

Komplettierung der Durchsetzung der Kartenterminals
ECC-Only-LZV-Pakete erst ab Zeitpunkt der Abschaltung
Komplettierung der Maßnahmen Rollout der Primärsysteme

SMC-B

Voraussetzungen

Aktuell werden noch G2.0 SMC-B verwendet, welche keine ECC-Zertifikate enthalten. Diese werden durch die Herausgeber bis zum 01.01.2026 gegen G2.1 SMC-B getauscht werden. Der Austausch wird von der gematik gemessen.

Vorgesehenes Monitoring:

Manuelles Tracking → Bestand G2.0 SMC-B
Betriebsdaten → TSP X.509 → G2.0 SMC-B OCSP-Anfragen

Durchsetzung

Auch über den 01.01.2026 hinaus bleiben SMC-B Zertifikate im TI-Vertrauensraum unverändert gültig und prüfbar. Die Nutzung von ECC-Signaturen und -Verschlüsselungen wird durch flächendeckende Verbreitung von G2.1 SMC-B und PTV6-Konnektoren durchgesetzt.

Mit der flächendeckenden Verbreitung von PTV6-Konnektoren ist auch die Voraussetzung für die Herausgabe von ECC-only SMC-B (ohne RSA-Zertifikate) gegeben.

Vorgesehenes Monitoring: Betriebsdaten → TSP X.509 → SMC-B OCSP-Anfragen (ECC vs. RSA)

Abhängigkeiten: PTV6-Konnektor-Rollout

Abschaltung

Sobald die flächendeckende Verbreitung von G2.1 SMC-B und PTV6 festgestellt wurde und die Abhängigkeiten von KIM erfüllt sind (siehe KIM-Durchsetzung), werden die Ausstellerzertifikate für die RSA2048-Zertifikate der SMC-B auf "revoked" gesetzt. Weiterhin werden die EE-Zertifkate der SMC-B gesperrt. Anwendungsfälle für SMC-B-Signaturen sind z.B. KIM, Authentisierung ggü. ePA/eRezept/VPN-ZugD und Konnektor-Backups.

Bei Restbeständen von G2.0 Karten oder PTV5 Konnektoren ist dann in dem Fehlertrace mit dem Fehler 1027 „CA_CERT_MISSING“ zu rechnen. Der Fehler kann bei allen Anwendungsfällen auftreten, die eine Gültigkeitsprüfung von SMC-B- Zertifikaten durchführen, wie Signieren, Signaturprüfen, VSDM.

HBA

Voraussetzungen

Aktuell werden noch G2.0 HBA verwendet, welche keine ECC-Zertifikate enthalten. Diese werden durch die Herausgeber bis zum 01.01.2026 gegen G2.1 HBA getauscht. Der Austausch wird von der gematik gemessen.

Vorgesehenes Monitoring:

Manuelles Tracking → Bestand G2.0 HBA
Betriebsdaten → TSP X.509 → G2.0 HBA OCSP-Anfragen

Durchsetzung

Die Nutzung von ECC für die QES wird mit der flächendeckenden Verbreitung von G2.1 HBA und PTV6-Konnektoren sowie durch die Umstellung der Primärsysteme entsprechend der Umstellungsleitfäden in Verbindung mit PTV5-Konnektoren durchgesetzt.
Die nonQES-Authentisierungsfunktion des HBA wird mit der flächendeckenden Verbreitung von G2.1 HBA und PTV6-Konnektoren durch die Umstellung der Primärsysteme entsprechend der Umstellungsleitfäden auf ECC umgestellt.
Laut BNetzA werden ab 2026 die RSA CA-Zertifikate für die QES in der BNetzA-Vertrauensliste auf „withdrawn“ gesetzt. Das hat zur Folge, dass keine neuen RSA QES-Zertifikate mehr ausgestellt werden können, so dass ab dem 1.1.2026 ECC-only HBAs (ohne RSA-Zertifikate) herausgegeben werden müssen.
Es ist davon auszugehen, dass die Nutzung zur Erzeugung einer QES der vor dem 1.1.2026 erstellten QES-RSA-Zertifikate einen Aufsichtsfall der BNetzA nach sich zieht, sollte sich herausstellen, dass diese über 31.12.2025 weiter zur QES genutzt werden. In solch einem Fall ist mit der Veranlassung der Sperrung der QES EE-Zertifikate zu rechnen.
Bei HBAs von bestimmten TSPs laufen QES-RSA-Zertifikate am 31.12.2025 ab. Wird versucht, danach mit einem solchen Zertifikat eine Signatur zu erstellen, findet sich im Fehlertrace der Fehler 1021 "CERTIFICATE_NOT_VALID_TIME" im Konnektor.
Damit ein nach dem 01.01.2026 herausgegebener HBA oder ein HBA mit abgelaufenem oder widerrufenem/gesperrtem RSA-Zertifikat ohne Fehler zum Signieren verwendet werden kann:
- muss ein PTV6-Konnektor verwendet werden oder
- kann ein PTV5-Konnektor verwendet werden, wenn das Primärsystem in dem Signaturaufruf den Parameter CRYPT=RSA_ECC setzt.

Known Issue: NFD können bei PTV5-Konnektoren nicht mit Angabe des CRYPT Parameters signiert werden.

Vorgesehenes Monitoring: Betriebsdaten → TSP X.509 → HBA OCSP-Anfragen (ECC vs. RSA)

Abhängigkeiten:

PTV6-Konnektor-Rollout
oder Rollout aller ECC-Ready Primärsysteme

Abschaltung

Da die Verwendung von RSA2048 für QES nach dem 31.12.2025 nach europäischen Recht für die Dokumentensignatur unzulässig ist, ist ab 01.01.2026 jederzeit mit einer Sperrung dieser Zertifikate zu rechnen. Wenn ein Konnektor versucht, mit einem widerrufenen Zertifikat eine Signatur zu erstellen, findet sich im Fehlertrace der Fehler 1047 „CERT_REVOKED“.

Die nonQES Authentisierungsfunktion mit RSA2048-Zertifikaten wird nach flächendeckenden Verbreitung von G2.1 HBA und PTV6-Konnektoren durch das Entfernen der relevanten RSA-CAs aus dem Vertrauensraum der TI (TI-TSL) unterbunden.

eGK

Voraussetzungen

G2.1 mit ECC-Zertifikaten werden flächendeckend eingesetzt. Dies ist zum heutigen Stand bereits erfüllt und es befinden sich keine RSA-Only-eGK mehr im Feld.

Vorgesehenes Monitoring: Manuelles Tracking → Reporting der TSPs, Zertifikatsablauf der G2.0 Karten

Durchsetzung

Damit der Usecase VSDM das ECC-Zertifikat verwendet, muss die Karte mit einem PTV6 Konnektor verwendet werden. Durch die Verwendung des VSDM-Prüfungsnachweises für eRezept und ePA wirkt das auch auf diese Anwendungen.

Abhängigkeiten: PTV6-Konnektor-Rollout

Vorgesehenes Monitoring: Betriebsdaten → TSP X.509 → Anzahl der OCSP-Anfragen zu RSA-Zertifikaten der eGK

Abschaltung

Entfernen der eGK-CAs für RSA-Zertifikate aus der TI-TSL. Als Konsequenz werden ab diesem Zeitpunkt nur noch ECC-only eGK herausgegeben. Die IOP-Fähigkeit mit ECC-only eGK ist erst mit PTV6 Konnektoren qualifiziert nachgewiesen, sodass der flächendeckende Rollout hier eine Abhängigkeit darstellt.

Vorgesehenes Monitoring: Manuelles Tracking → Stichprobenhaftes Prüfen von Karten, welche nach Abschaltung personalisiert wurden

Abhängigkeiten: PTV6-Konnektor-Rollout vor Abschaltung

eHealth-Kartenterminal & gSMC-KT

Voraussetzungen

Maßnahmen eHealth-Kartenterminal

Entgegen der meisten anderen TI-Kompoenten beziehen KTs ihre TSL nicht über download, sondern über FW updates bzw. Dateiimport. Ein Update der Kartenterminal-Firmware auf einen minimalen Stand ist erforderlich, um sicherzustellen, dass die KTs eine ECC-fähige TSL bekommen.

Voraussetzung für den Umstieg auf ECC ist eine G2.1 SMC-KT und eine Firmwareversion >= der folgenden:

KT-Produkt	ProductVendorId	FW-Version
Ingenico Orga	INGHC	3.9.1
GT900	GERTE	2.1.1
Cherry ST	DECHY	4.0.47

Vorgesehenes Monitoring: Konnektordaten → Verbreitung der ECC-fähigen KT-Versionen an den verbundenen Konnektoren.

Maßnahmen gSMC-KT

Aktuell werden noch in großer Zahl G2.0 gSMC-KT genutzt. Damit bei der TLS-Verbindung zum Konnektor ECC-Kryptographie genutzt werden kann, ist eine G2.1 gSMC-KT notwendig. Ein Austausch der im Feld befindlichen G2.0 gSMC-KT ist daher erforderlich.

Da ein vollständiger Kartentausch bis Jahresende nicht möglich ist und unter Berücksichtigung, dass die RSA-Zertifikate der gSMC-KT 2.0 ausschließlich in geschlossenen Netzen (z. B. innerhalb einer Arztpraxis) und nicht zur Verschlüsselung oder Signatur medizinischer Daten verwendet werden, bleibt die Nutzung der gSMC-KT 2.0 über den 01.01.2026 hinaus vorerst zulässig. Unabhängig von der Laufzeit der auf den Karten gespeicherten Zertifikate ist die Nutzung jedoch spätestens zum 31.12.2026 einzustellen.

Die meisten dieser Karten laufen in dieser Zeit ab und werden regulär getauscht. Restbestände, die im Januar und Februar 2027 ablaufen, müssen vorzeitig getauscht werden.

Um den neuen kryptografischen Sicherheitsanforderungen des BSI zu entsprechen, empfiehlt die gematik, die Karte spätestens bis zum 01.01.2026 gegen eine gSMC-KT 2.1 auszutauschen.

Vorgesehenes Monitoring: Konnektordaten → Anteil der ECC-Pairings

Durchsetzung

Wenn die Voraussetzungen erfüllt sind, setzt der PTV6-Konnektor die Verwendung von ECC bei der TLS-Verbindung zu Kartenterminals durch. Dies erfolgt, indem die RSA-basierten Pairings durch ein Wartungspairing automatisch auf ECC-basierte Pairings umgestellt werden.

Vorgesehenes Monitoring: nicht verfügbar

Abschaltung

RSA2048-gSMC-KT-Zertifikate werden aus dem Vertrauensraum der TI entfernt, indem die RSA KOMP-CAs für C.SAK.AUT und C.SMKT.AUT aus der TI-TSL entfernt werden.

Vorgesehenes Monitoring: nicht verfügbar

Abhängigkeit:

Austausch der G2.0 gSMC-KT im Feld
Aktuelle KT-FW im Feld

KIM-Clientmodul

Voraussetzungen

Das Empfangen von ECC verschlüsselten/signierten KIM-Nachrichten erfordert eine KIM-Version größer als 1.0/1.5.2.

Das Versenden von ECC-verschlüsselten KIM-Nachrichten erfordert eine G2.1 SMC-B beim Empfänger sowie eine KIM-Version größer 1.0.

Das Versenden von ECC-signierten KIM-Nachrichten erfordert eine G2.1 SMC-B und einen PTV6-Konnektor bzw. eine G2.1 SMC-B und einen PTV5-Konnektor mit KIM 1.5.2-9 beim Sender.

Subsummiert resultieren daraus folgende Voraussetzungen:

KIM-CM 1.5.2-9 ist flächendeckend ausgerollt
Konnektor PTV6 ist flächendeckend ausgerollt
HBA und SMC-B G2.0 sind vollständig getauscht

Maßnahmen KIM 1.5.2-9 CM Rollout

Die KIM-Clientmodule werden auf KIM 1.5.2-9 aktualisiert. Dies betrifft auch alle Basis Consumer Instanzen im Feld.

Vorgesehenes Monitoring: Manuelles Tracking → Meldungen der KIM-CM-Hersteller → Status Rollout KIM 1.5.2-9

Durchsetzung

Die Verwendung von ECC für die Verschlüsselung von KIM-Nachrichten wird durch das Herausfiltern der RSA2048-Verschlüsselungszertifikate (SM-B, HBA) vom VZD durchgesetzt. Ein Versender einer KIM-Nachricht ist durch den vom VZD angewendeten Filter in der Rückgabe der LDAP-Abfrage nicht mehr in der Lage, mit den RSA-Zertifikaten eines Empfängers zu verschlüsseln, da nur noch die ECC-Zertifikate zurückgegeben werden.

Wenn die Voraussetzungen erfüllt sind, garantieren sie die Verwendung von ECC für das Signieren von KIM-Nachrichten.

Abhängigkeiten: PTV6-Konnektor-Rollout darf erst nach umfassenden Ausrollen von KIM 1.5.2-9 im Feld erfolgen.

Abschaltung

Die CAs der RSA2048-Zertifikate von SMC-B und HBA werden aus dem Vertrauensraum der TI entfernt (siehe SMC-B). Zusätzlich werden die EE-Zertifikate der SMC-B gesperrt. Die Sperrung der EE-Zertifikate der HBA unterliegt der Zuständigkeit der BNetzA. Auch hier ist mit Sperrung dieser zu rechnen.

Primärsystem

Voraussetzungen

Das Primärsystem muss seine Kompatibilität mit den Schnittstellen des PTV6 sicherstellen: und ggf. ECC-preferred-Verhalten bei PTV5-Konnektoren durchsetzen. Die Vorgehensweise ist im Detail in den ULFs beschrieben.

Maßnahmen PS-Implementierung

Primärsysteme müssen die Umsetzung notwendiger Anpassungen anhand der Umstellungsleitfäden (ePA, eRezept, KIM, NFDM und weitere Unterseiten) sicherstellen, um IOP-Probleme im Zuge der Migration insbesondere PTV6 Update zu vermeiden.

Vorgesehenes Monitoring:

Manuelles Tracking → Meldungen der PS-Hersteller aus den Umfragen der gematik (Umfragen zur ECC-Readiness) und Direktansprache der PS-Hersteller
Manuelles Tracking → Meldungen der RU-Teilnehmer über das RUaaS Serviceportal (ANFRUS, Meldung der Readiness, Fehlermeldungen etc.)
Betriebsdaten
- TSP X.509 → RSA basierte OCSP-Aufrufe
- E-Rezept Signaturquote RSA/ ECC

Abhängigkeiten: PTV6-Konnektor-Rollout darf erst nach umfassendem Ausrollen der PVS, die die ULFs umgesetzt haben, erfolgen.

Maßnahmen Tests

Die Primärsysteme müssen gegen PTV6-Konnektoren getestet werden. Da die Ende-zu-Ende Anwendungsfälle vielschichtig sind und von der gematik weder vollumfänglich übersehen noch gesteuert werden können, ist hier eigenverantworliche Testplanung und Testdurchführung durch die PS-Hersteller erforderlich. Die gematik stellt hierfür unterstützend die ECC-Testwochen zur Verfügung, in denen die entsprechende Testumgebung als Voraussetzung geschaffen ist.

Vorgesehenes Monitoring: Manuelles Tracking → Problemmeldungen der RU-Teilnehmer aus den ECC-Testwochen

Abhängigkeiten:

PTV6-Konnektoren bzw. PTV2 HSK Versionen den PS-Herstellern verfügbar
Testmittel den PS-Herstellern verfügbar, um die im Feld gängigen Kombinationen/Konstellationen nachstellen zu können
Qualifizierte Testergebnisse in vielen Aspekten nur innerhalb der Testwochen möglich

Maßnahmen Rollout

Die PTV6-fähigen Primärsystemversionen müssen ausgerollt werden. Wenn nach den ULFs implementiert wurde, kann der PS Rollout dann sofort erfolgen und es muss keine Abhängigkeit beachtet werden.

Vorgesehenes Monitoring: Manuelles Tracking → Meldungen der PS-Hersteller aus den Umfragen der gematik (Umfragen zur ECC-Readiness)

Abhängigkeiten: keine

Durchsetzung

Werden neue Clientsysteme über TLS an den Konnektor angeschlossen, können nur noch RSA3072 oder ECC-NIST Client-Zertifikate eingerichtet werden. Bei der Umstellung von bereits bestehenden RSA-basierten TLS-Konfigurationen auf ECC müssen alle Server- und Clientzertifikate umgestellt werden, da Mischkonfigurationen nicht von allen Konnektoren unterstützt werden.

Vorgesehenes Monitoring:

HSK: Konnektordaten → Kryptografie der zuletzt eingerichteten Clientsystemverbindung (erst ab HSK PTV2)
EBK: nicht verfügbar

Abhängigkeiten: PTV6-Konnektor-Rollout

Abschaltung

Clientsystemverbindung

Sollte erkannt werden, dass die an einem Konnektor eingerichtete Clientsystemauthentisierung RSA2048 basiert ist, sollte diese zwar gegen eine andere ersetzt werden, jedoch gibt es im Rahmen der geplanten RSA-Abschaltungen keine Durchsetzungsmechanismen und daher auch keine Konsequenzen, wenn dies in einer LEI nicht umgesetzt wird. D.h. bestehende RSA2048 Verbindungen werden sowohl mit PTV5 als auch mit PTV6 bis auf Unbestimmte Zeit weiterhin nutzbar sein.

Nichtsdestotrotz weist die gematik darauf hin, dass gem. SOG-IS solche Verbindungen ab 2026 nicht mehr zulässig sind.

Prüfung bei Serverauthentisierung

Wenn der Konnektor das gSMC-K Zertifikat als TLS-Server-Zertifikat nutzt, und das Primärsystem dieses gegen die TSL prüft, wird mit Entfernen der RSA-gSMC-K C.AK.AUT Zertifikate aus dem Vertrauensraum der TI durch Entfernen der RSA KOMP-CAs aus der TI-TSL eine PKI-Kettenprüfung durch ein Clientsystem nicht erfolgreich sein. Es ist keine empfohlene Konfiguration, dass das Primärsystem das TLS-Server-Zertifikat gegen die TSL und PKI-Kette prüft. Es ist intendiert, dass das TLS-Server-Zertifikat vom Client immer als Self-Signed angesehen wird.

Vorgesehenes Monitoring: Betriebsdaten → TSP X.501 → OCSP Anfragen für C.AK.AUT

Kontrollierte Außerbetriebnahme von RSA im Rahmen der ECC-Migration

Die Außerbetriebnahme von RSA2048 über den Vertrauensraum der TI wurde während der Testwochen in der Referenzumgebung konsequent umgesetzt. Dabei zeigte sich, dass mit jeder weiteren Testwoche weniger kritische Themen identifiziert wurden.

Gleichwohl bestehen Risiken bei der Umstellung in der Produktivumgebung:

Unter anderem gibt es keine vollumfängliche Testabdeckung,
Systeme wurden speziell für die Referenzumgebung (RU) angepasst, jedoch vermeintlich bislang nicht in der Produktivumgebung (PU).
Zudem könnte es unter realen Lastbedingungen bei der Umstellung auf ECC zu Performance- oder Stabilitätsproblemen kommen.

Um diesen Risiken mit weiteren Maßnahmen zu begegnen, erfolgt die Abschaltung von RSA nicht an einem Stichtag, sondern kontrolliert und schrittweise – anders als in der RU während der Testwochen. Konkret ist vorgesehen, den Vertrauensraum iterativ zu bereinigen: Es wird jeweils eine Sub-CA aus der TSL entfernt, das Verhalten des Systems anschließend mittels Monitoring engmaschig überwacht. Sollten keine unerwarteten Störungen auftreten, folgt nach einer definiereten Boabachtungsphase die Entfernung der nächsten CA. Bei Problemen kann die CA temporär wieder aktiviert und die Ursachen analysiert und behoben werden.

Dabei wird berücksichtigt, dass bestimmte CAs weiterhin im Vertrauensraum verbleiben müssen – etwa für gSMC-KT 2.0, um deren Funktionalität bis mindestens 2026 sicherzustellen, oder für Karten, auf denen weiterhin RSA-basierte Identitäten aufgebracht werden müssen.

Nachfolgend ist die Außerbetriebnahme von RSA aus PKI-Management-Sicht beschrieben.

Planungsstand

RUaaS > Migrationsvorgehen RSA2ECC > image-2025-11-19_14-29-37.png

Allgemeine Schritte der Außerbetriebnahme von RSA

Nachfolgend sind die Schritte im allgemeinen betrachtet:

Maßnahme	Wo?	Was passiert?	Wirkung
Entfernen/Statuswechsel von Ausstellerzertifikaten	TSL	RSA-CA-Zertifikate werden aus der TSL entfernt oder erhalten einen Statuswechsel.	EE-Zertifikate werden ungültig, Zertfikatspfad kann nicht mehr erfolgreich validiert werden. Für Signaturprüfungen verbleiben diese CAs im Vertrauensraum.
Entfernen von Zertifikatstyp-OIDs	TSL	OIDs für RSA-Zertifikatstypen werden aus TSL-Einträgen entfernt.	Zertifikate können für bestimmte Zwecke technisch nicht mehr verwendet werden.
Filterung und Entfernung von Zertifikaten	VZD	Es wird ein Filter im VZD gesetzt, welche keine RSA-Zertifikate mehr beauskunftet. RSA-Zertifikate (v.a. Verschlüsselungszertifikate) werden aus Verzeichnisdienst entfernt.	Keine neuen RSA-verschlüsselten Nachrichten mehr möglich.
Sperren von Zertifikaten	TSP/OCSP	EE-Zertifikate werden beim TSP auf „revoked“ gesetzt.	Zertifikate können nicht mehr eingesetzt werden, bestehende Signaturen bleiben prüfbar.
Abschaltung des RSA-TSL-Downloadpunkts	TSL	Der Downloadpunkt für reine RSA-TSL wird deaktiviert. Komponenten können keine RSA-TSL mehr herunterladen.	Es kann wird nur noch der ECC-TSL-Downloadpunkt verwendet welcher eine TSL bereitstellt, welche alle CAs beinhaltet. Die TSL ist mit ECC signiert und muss entsprechend vor der Verarbeitung geprüft werden.
Statuswechsel der QES CA's "withdrawn"	BNetzA_VL (QES)	Die QES CA's werden laut Bundesnetzagentur einen Statuswechsel auf "withdrawn" erhalten	Dadurch lassen sich keine QES Zertifikate für HBAs ausstellen.

Schritte der Außerbetriebnahme von RSA im Detail

Entfernen/Statuswechsel von Ausstellerzertifikaten

Aktuell etwas über einhundert relevente CAs von verschiedenen TSPs in der TSL. Diese werden nachfolgenden ge-clustert betrachtet und die entsprechend Planung zur Entfernung oder zum Statuswechsel betrachtet.

Allgemeine CA (Zweck) (Bemerkung)	Zeitplan	Abschaltkriterium (Alle aufgelisteten Kriterien müssen erfüllt sein, sonst kann der Schritt nicht ausgeführt werden)
eGK-ALVI-CA (eGK, Kassen-Apps) (Authentisierung in Kassen-Apps, ePA-Aktensystem)	Obsolet - Es gab nie RSA CA's für ALVI und wurde direkt mit Einführung der ePA mit ECC umgesetzt.	Bereits erfüllt
eGK-CA (elektronische Gesundheitskarte) (Authentisierung, Verschlüsselung, Signatur)	Entfernen alle eGKs mit Ablaufdatum <2028 01 Jul 2026 Hintergrund: Die ältesten CAs haben die wenigsten Karten im Feld (geschätzt 20% der Karten) Kein Anbieter ist benachteiligt Entfernen alle restlichen eGKs 29 Jul 2026	siehe: eGK
HBA-CA (Heilberufsausweis) (Authentisierung, Verschlüsselung)	Schritt 1: VZD umschalten auf ECC-only-Filterung 05 Aug 2026 Siehe: Filterung und Entfernung von Zertifikaten wirkt sofort & umkehrbar wirkt auch auf SMC-B Schritt 2: HBA-CAs aus der TSL entfernen 05 Aug 2026 RSA-EE im VZD werden automatisch entfernt. Siehe: VZD	siehe: HBA Nicht zum Quartalsende
SMCB-CA (Institutionskarte SMC-B) (Authentisierung, Verschlüsselung, Signatur)	Schritt 1: VZD umschalten auf ECC-only-Filterung 05 Aug 2026 Siehe: Filterung und Entfernung von Zertifikaten wirkt sofort & umkehrbar wirkt auch auf HBA Schritt 2: CA auf "revoked" in der TSL setzen 05 Aug 2026 → 1 Monat nach der ECC-Only Kartenherausgabe Schritt 3: EE-Zertifikate sperren (ca. ein Quartal nach "revoked" setzen der CA) Siehe: Sperren von Zertifikate	siehe: SMC-B Nicht zum Quartalsende ECC-Only Kartenherausgabe gestartet
KOMP-CA (Komponenten, gSMC-K, gSMC-KT, etc.) (Authentisierung von Konnektoren/Kartenterminals/Fachdiensten)	Schritt 1: Entfernen der OIDs für die jeweiligen Zertifikatstypen aus der TSL: Siehe: Entfernen von Zertfikatstyp-OIDs Schritt 2: Entfernen der RSA KOMP-CA aus der TSL 31 Dec 2026	Keine G2.0 gSMC-KTs mehr im Feld (toleriert bis Ende 2026). Siehe: eHealth-Kartenterminal & gSMC-KT Es dürfen kein RSA-Signatur-Zertifikate in Nutzung sein (FD.SIG, ZD.SIG, FD.OSIG) RSA-gSMC-K Zertifikate müssen bis Ende 2026 prüfbar bleiben (CA Zertifikate verbleiben in der TSL), ansonsten funktioniert die Laufzeitverlängerung nicht mehr - auch die Verlängerung von ECC-Zertifikaten Einboxkonnektor PTV6 müssen flächendeckend im Feld ausgerollt sein, so dass Laufzeitverlängerung funktionsfähig bleibt Wenn alle OIDs entfernt sind. Siehe: Entfernen von Zertfikatstyp-OIDs
VPNK-CA (VPN-Konzentrator) (Authentisierung VPN-Zugangsdienst)	Entfernen der RSA VPNK-CA aus der TSL 01 Jul 2026	Es werden keine neuen RSA VPNK-Zertifikate mehr für VPN-Zugangsdienste benötigt. Alle Konnektoren unterstützen den VPN-Verbindungsaufbau mit ECC-Zertifikaten

Entfernen von Zertifikatstyp-OIDs

oid	Zert. Typ	Komponente	Plandatum	Usecase	Kommentar
oid_hsk_sig	C.HSK.SIG	HSK	01 Jul 2026	HSM-B	Aktuell in PU nicht in Verwendung Verwendung nach Spec. nur mit ECC
oid_hsk_enc	C.HSK.ENC	HSK	01 Jul 2026	HSM-B	Aktuell in PU nicht in Verwendung Verwendung nach Spec. nur mit ECC
oid_fd_aut	C.FD.AUT	Fachdienste	01 Jul 2026	EPA-VAU/-VST/FDZ eRezept-VAU	RSA2048 aktuell in PU nicht in Verwendung
oid_fd_osig	C.FD.OSIG	Fachdienste	01 Jul 2026	eRezept	RSA2048 aktuell in PU nicht in Verwendung
oid_nk_vpn	C.NK.VPN	Konnektor (gSMC-K)	14 Oct 2026	IPSec Verbindung aufbauen	Sobald alle Konnektoren sich über ECC reregistriert haben, also mit Rollout-Abschluss von PTV6
oid_vpnk_vpn_sis	C.VPNK.VPN-SIS	Konnektor (gSMC-K)	14 Oct 2026	IPSec Verbindung aufbauen	Sobald alle Konnektoren sich über ECC reregistriert haben, also mit Rollout-Abschluss von PTV6
oid_vpnk_vpn	C.VPNK.VPN	VPN-ZugD	14 Oct 2026	IPSec Verbindung aufbauen	Sobald alle Konnektoren sich über ECC reregistriert haben, also mit Rollout-Abschluss von PTV6
oid_cm_tls_c	C.CM.TLS-CS	KIM-Clientmodul	14 Oct 2026	Client-Cert zum KIM-FD, und zum Konnektor	Sobald KIM CM auf V1.5.2-9 umgestiegen ist, werden vom FD ECC-Certs bezogen und die OID kann entfernt werden.
oid_fd_tls_c	C.FD.TLS-C	Alle FD, die als TLS-Clients fungieren	14 Oct 2026	EPA-MGMT als Client eRezept-FD als Client (für EPA) Intermediär als Client KIM-FD als Client TSP-SMB-Schnittstelle
oid_fd_tls_s	C.FD.TLS-S	Alle FD, die als TLS-Server fungieren	14 Oct 2026	CMS EPA-AS/-MGMT/-VST/-FDZ eRezept-FD IDP Intermediär als Server KIM-FD TIGW-Zugangsmodul UFS VSDD
oid_fd_sig	C.FD.SIG	Fachdienste	14 Oct 2026	EPA-AS/-VAU eRezept-FD IDP / sekIDP TIM-FD VPNZ (RegServer) VZD Wanda
oid_fd_enc	C.FD.ENC	Fachdienste	14 Oct 2026	EPA-AS/-VAU/-VST/-FDZ eRezept-VAU Wanda
oid_zd_tls_s	C.ZD.TLS-S	Zentrale Dienste	14 Oct 2026	BDE (C.ZD.TLS-S.STAMP) KSR TSL-Dienst VPNZ VZD
oid_zd_sig	C.ZD.SIG	Konnektor PS	14 Oct 2026	Bestandsnetze.xml PoPP PoPP-Token	PoPP(-Token) sind nicht umgesetzt. Somit auch keine Verwendung mit RSA
oid_smkt_aut	C.SMKT.AUT	eHKT (gSMC-KT)	31 Dec 2026	mTLS-Verbindung KT-Konnektor	Wenn keine gSMC-KT in der Version G2.0 mehr im Feld sind.
oid_sak_aut	C.SAK.AUT	Konnektor (gSMC-K)	31 Dec 2026	mTLS-Verbindung KT-Konnektor	Wenn keine gSMC-KT in der Version G2.0 mehr im Feld sind. 31 Dec 2026
oid_ak_aut	C.AK.AUT	Konnektor (gSMC-K)	31 Dec 2026	Clientsystem TLS-Verbindung (AUT der gSMC-K)	siehe: PS-Abschaltung

Filterung und Entfernung von Zertifikaten

Maßnahme	Wo?	Was passiert, wann?	Wirkung
Filterung/Entfernung von HBA/SMC-B Zertifikaten aus dem Verzeichnisdienst.	VZD	Schritt Filter setzen (umkehrbar) 05 Aug 2026 CAs werden aus TSL entfernt → Wirkung: HBA EEs werden automatisch beim VZD gelöscht (generell nicht umkehrbar; nur teilweise durch ReBackup) → Siehe HBA und Entfernen/Statuswechsel von Ausstellerzertifikaten EE RSA SMC-B Zertifikate aus VZD löschen (generell nicht umkehrbar: nur teilweise durch ReBackup) 31 Dec 2026 → parallel zur SMC-B Massensperrung	RSA Zertifikate werden nicht mehr verwendet

Sperren von Zertifikaten

Maßnahme

Wo?

Was passiert, wann?

Wirkung

HBA - C.HP.QES.R2048

TSP QES

Durch Vorgaben der BNetzA in Abstimmung mit den TSPs

Es können nur noch ECC QES-Signaturen ausgestellt werden. Vergangene RSA Signaturen bleiben prüfbar.

Siehe auch: HBA

SMC-B:

C.HCI.OSIG.R2048
C.HCI.AUT.R2048
C.HCI.ENC.R2048

TSP nonQES

Die Zertfikate werden als Massenauftrag gesperrt. Die Signaturzertifikate werden bei den TSPs zum Stichtag auf den Status "revoked" gesetzt. In diesem Status behalten vor dem Stichtag getätigte Signaturen ihre Gültigkeit. Ein Quartal nach "revoked" setzen der SMC-B CA 04 Nov 2026

Das Sperren von EE-Zertifikate in der PU ist irreversibel.

Es können nur noch ECC Zertfikate einer G2.1 verwendet werden.

Siehe auch: SMC-B

Abschaltung des RSA-TSL-Downloadpunkts

Maßnahme

Wo?

Was passiert, wann?

Wirkung

Abschaltung des RSA-TSL-Downloadpunkts

TSL

Der Downloadpunkt für reine RSA-TSL wird deaktiviert. Komponenten können keine RSA-TSL mehr laden. 01 Jul 2026

Es wird nur noch der ECC TSL Downloadpunkt verwendet.

In der TU/RU ist die RSA TSL bereits seit mitte 2025 nicht mehr aktiv.

Mit Tausch der restlichen RSA-only Personalisierten Konnektoren (Ende 25') in der PU wird die RSA TSL nicht mehr benötigt.

Statuswechsel der QES CA's auf "withdrawn"

Allgemeine CA (Zweck) (Bemerkung)	Was passiert, wann?	Wirkung
HBA-qCA (HBA, QES) (Qualifizierte elektronische Signatur)	Die BNetzA kann nach Feststellung einer Weiternutzung von QES RSA ab 2026 in Abstimmung mit dem jeweiligen TSP die QES CAs in der BNetzA_VL auf den Status "withdrawn"setzen.	Es lassen sich keine EEs QES RSA Zertfikate für HBAs ausstellen und somit können nur noch ECC only HBAs herausgegeben werden.

Abkürzungsverzeichnis

Kürzel	Erläuterung
AUT	Authentication
BNetzA	Bundesnetzagentur
BNetzA-VL	Vertrauensliste (TSL) der Bundesnetzagentur
BSI	Bundesamt für Sicherheit in der Informationstechnik
CRL	Certificate Revocation List
DVO	Dienstleister vor Ort
eAU	Elektronische Arbeitsunfähigkeitsbescheinigung
ECC	Elliptic Curve Cryptography
ECDSA	Elliptic Curve Digital Signature Algorithm
EE-Zertifikat	End-Entity-Zertifikat
eGK	Elektronische Gesundheitskarte
ePA	Elektronische Patientenakte
gSMC-K	Smartcard zur Identifikation und Authentisierung des Konnektors
gSMC-KT	Smartcard zur Identifikation und Authentisierung des Kartenterminals
HBA	Heilberufsausweis
IDP	Identity Provider
KIM	Kommunikationsdienst im Medizinwesen
KOM-LE	Früherer Name für KIM (Kommunikation im Medizinwesen)
KSR	Konfigurations- und Software-Repository
LE	Leistungserbringer
LEI	Leistungserbringerinstitution
NFD	Notfalldatensatz
OCSP	Online Certificate Status Protocol
PKI	Public Key Infrastructure
PS	Primärsystem
PTV	Produkttypversion
PU	Produktivumgebung
PVS	Praxisverwaltungssystem
QES	Qualifizierte elektronische Signatur
RSA	(Rivest–Shamir–Adleman) ist ein asymmetrisches kryptographisches Verfahren
RU	Referenzumgebung
SigD	Signaturdienst
SMC-B	Sicherheitsmodul Card Typ B
TI	Telematikinfrastruktur
TI-M	TI-Messenger
TLS	Transport Layer Security
TSL	Trust-service Status List
TU	Testumgebung
VPNK	VPN-Konzentrator
VSDD	Versichertenstammdatendienst
VSDM	Versichertenstammdatenmanagement
VZD	Verzeichnisdienst
WANDA	Weitere Anwendungen für den Datenaustausch in der Telematikinfrastruktur

Wir freuen uns jederzeit über Hinweise und Feedback, um dieses Dokument aktuell und so zielführend wie möglich zu halten!

Anfragen zur RSA/ECC-Migration (gern auch über "Meldung" als vereinfachter Workflow ohne Rückantwort)

Allgemeines Anfrageportal - Serviceprojekt