Grundschutz++ ist in der Phase nach der Veröffentlichung von BSI-Standard 300-1 (bis 12/2026). Das BSI hat die Methodik am 26.10.2026 als BSI-Standard 300-1 veröffentlicht.Zum Zeitplan
Änderungsprotokoll des Grundschutz++-Katalogs
Das BSI veröffentlicht den Katalog in Ständen. Die Commit-Meldungen dazu lauten
fast durchgehend „chore: publish rolling artifacts“ und nennen keine Inhalte.
Diese Seite ist das Änderungsprotokoll (englisch: Changelog) dazu: Sie vergleicht
jeweils zwei veröffentlichte Stände und zeigt, was sich an den Anforderungen
geändert hat: Titel, Anforderungstext, Erläuterung, Pflichtgrad,
Stufe, Aufwand, Ergebnis, Dokument, Zielobjekte, Gefährdungen und Tags.
Die Seite entsteht automatisch aus der Git-Historie des
BSI-Repositories. Sie
nennt, was vorher da stand und was jetzt dasteht, und bewertet nichts. Wie
bedeutsam eine Änderung ist, muss man selbst beurteilen. Maßgeblich ist immer das
Original des BSI.
So liest du die Einträge: Die Darstellung entspricht einem Diff. − ist der
Wortlaut des vorherigen Stands, + der des neuen. Wörter, die sich geändert haben, sind hervorgehoben. Bei Listen
(Gefährdungen, Tags, Zielobjekte) steht nur, was wegfiel und was dazukam.
Erfasst sind die Stände seit dem 27. Juli 2026, als das BSI das Repository auf
eine neue Struktur umgestellt hat. Frühere Stände liegen dort an einem anderen
Pfad und sind hier nicht enthalten.
Seit dem 27. Juli 2026: 82 Änderungen an 80 Anforderungen in 8 Ständen, 10 veröffentlichte Stände verglichen.
BES.7.4.12Software Bill of Materials (SBOM) - Cloud
Erläuterung
−vorher: Ein anerkannter Standard für SBOM ist die BSI TR-03183-2.
+nachher: Im Kontext von Software-as-a-Service (SaaS), also Software, die durch einen externen Anbieter betrieben und über ein Netzwerk als Dienst bereitgestellt wird, beschreibt die SBOM die vom Anbieter eingesetzten Softwarekomponenten, beispielsweise proprietäre Softwaremodule, quelloffene Bibliotheken (Open-Source Components) und eingebundene Drittkomponenten (Third-Party Components). Dabei können sowohl direkte Abhängigkeiten (Direct Dependencies) als auch mittelbare beziehungsweise transitive Abhängigkeiten (Transitive Dependencies) berücksichtigt werden. Da die technische Infrastruktur und die Softwarezusammensetzung bei SaaS üblicherweise durch den Anbieter kontrolliert werden, kann sich die SBOM auf die für den bereitgestellten Dienst relevanten und vom Anbieter offengelegten Bestandteile beziehen. Ein anerkannter Standard für SBOM ist die BSI TR-03183-2. Eine Zuordnung der SBOM zum jeweiligen SaaS-Dienst sowie zu einem eindeutig identifizierbaren Softwarestand oder Bereitstellungszeitpunkt ermöglicht die Nachvollziehbarkeit der dokumentierten Komponenten bei softwarebezogenen Lieferkettenrisiken (Software Supply Chain Risks).
−vorher: Beispielsweise Meldewege für Notfälle, Sicherheitsvorfälle, Eskalationsstufen.
+nachher: Unter organisatorischen Schnittstellen des Dienstleisters sind die festgelegten Berührungspunkte zwischen dem Dienstleister und der Institution zu verstehen, über die eine Zusammenarbeit, Abstimmung, Informationsweitergabe oder Entscheidungsfindung erfolgt. Hierzu zählen insbesondere (1) Ansprechpartner und zuständige Rollen auf beiden Seiten, (2) Verantwortlichkeiten und Zuständigkeitsabgrenzungen für die Erbringung und Steuerung der Dienstleistung sowie (3) Kommunikations-, Abstimmungs- und Eskalationswege für operative, administrative und sicherheitsrelevante Angelegenheiten, einschließlich für Notfälle oder Sicherheitsvorfälle. Organisatorische Schnittstellen können sowohl regelmäßige Abstimmungen im laufenden Dienstleistungsverhältnis als auch anlassbezogene Kontakte, etwa bei Sicherheitsvorfällen, Leistungsstörungen oder Änderungen der Dienstleistung, umfassen.
−vorher: Berechtigung SOLLTE eine Vorgehensweise zur initialen Ausgabe von Authentifizierungsmitteln verankern.
+nachher: Berechtigung SOLLTE eine Vorgehensweise zur initialen Ausgabe oder Registrierung von Authentifizierungsmitteln und ihrer Zuordnung zu den vorgesehenen Zugangskonten oder Berechtigungsumfängen verankern.
Ergebnis
−vorher: eine Vorgehensweise zur initialen Ausgabe von Authentifizierungsmitteln
+nachher: eine Vorgehensweise zur initialen Ausgabe oder Registrierung von Authentifizierungsmitteln und ihrer Zuordnung zu den vorgesehenen Zugangskonten oder Berechtigungsumfängen
−vorher: Berechtigung SOLLTE vor der Verteilung von Authentifizierungsmitteln die Identität authentifizieren.
+nachher: Berechtigung SOLLTE vor der Verteilung von Authentifizierungsmitteln die Identität der vorgesehenen Personen oder technischen Instanzen authentifizieren.
Erläuterung
−vorher: Identität meint hier die natürliche Person, Gruppe, Rolle, Anwendung oder das IT-System, welches das Authentifizierungsmittel erhält. Verteilung meint hier die initiale Ausgabe, Weiterleitung oder Speicherung des Authentifizierungsfaktors, z.B. die Ausgabe eines initialen Passwort … oder Speicherung des Authentifizierungsfaktors, z.B. die Ausgabe eines initialen Passwort …
+nachher: Identität meint hier die natürliche Person, Gruppe, Rolle, Anwendung oder das IT-System, welches das Authentifizierungsmittel erhält. Verteilung meint hier die initiale Ausgabe, Weiterleitung, Registrierung oder Speicherung des Authentifizierungsfaktors, z.B. die Ausgabe eines initialen Passwort … oder Speicherung des Authentifizierungsfaktors, z.B. die Ausgabe eines initialen Passwort …
Ergebnis
−vorher: vor der Verteilung von Authentifizierungsmitteln die Identität
+nachher: vor der Verteilung von Authentifizierungsmitteln die Identität der vorgesehenen Personen oder technischen Instanzen
+nachher: Identität vor Zurücksetzung und Ersetzung
Anforderung
−vorher: Berechtigung SOLLTE vor dem Zurücksetzen von Berechtigungsmitteln eine Identitätsüberprüfung verankern.
+nachher: Berechtigung SOLLTE vor der Zurücksetzung oder Ersetzung von Authentifizierungsmitteln eine Überprüfung der Identität der anfragenden Person oder technischen Instanz verankern.
Ergebnis
−vorher: vor dem Zurücksetzen von Berechtigungsmitteln eine Identitätsüberprüfung
+nachher: vor der Zurücksetzung oder Ersetzung von Authentifizierungsmitteln eine Überprüfung der Identität der anfragenden Person oder technischen Instanz
BER.5.2Zurücksetzung und Ersetzung von Authentifizierungsmitteln
Titel
−vorher: Vorgehensweise zur Zurücksetzung
+nachher: Zurücksetzung und Ersetzung von Authentifizierungsmitteln
Anforderung
−vorher: Berechtigung SOLLTE eine Vorgehensweise zur Zurücksetzung von Authentifizierungsmitteln verankern.
+nachher: Berechtigung SOLLTE eine Vorgehensweise zur Zurücksetzung oder Ersetzung von Authentifizierungsmitteln verankern.
Ergebnis
−vorher: eine Vorgehensweise zur Zurücksetzung von Authentifizierungsmitteln
+nachher: eine Vorgehensweise zur Zurücksetzung oder Ersetzung von Authentifizierungsmitteln
Technische Änderungen ohne Auswirkung auf den Text
Feld class bei 897 Anforderungen, zum Beispiel ARCH.1.1:"BSI-Stand-der-Technik-Kernel-G0" → "BSI-Stand-der-Technik-Kernel"
−vorher: Gebäudemanagement für Datenträgerarchiv KANN für die Datenträger schonende Temperatur und Luftfeuchtigkeit anhand von [Schwellwerten] überwachen.
+nachher: Gebäudemanagement für Archiv KANN für die Datenträger schonende Temperatur und Luftfeuchtigkeit anhand von [Schwellwerten] überwachen.
−vorher: Sensibilisierung für Nutzende von Faxen SOLLTE gegen die Risiken der unauthentisierten und unverschlüsselten Faxnutzung sensibilisieren.
+nachher: Sensibilisierung für Nutzende von Faxanwendungen SOLLTE gegen die Risiken der unauthentisierten und unverschlüsselten Faxnutzung sensibilisieren.
−vorher: Governance und Compliance MUSS eine einheitliche Methodik für das Informationssicherheitsrisikomanagement unter Berücksichtigungen von Kontext, Geschäftsprozessanalyse und interessierten Parteien verankern.
+nachher: Governance und Compliance MUSS [eine einheitliche Methodik] für das Informationssicherheitsrisikomanagement unter Berücksichtigungen von Kontext, Geschäftsprozessanalyse und interessierten Parteien verankern.
Ergebnis
−vorher: eine einheitliche Methodik für das Informationssicherheitsrisikomanagement
+nachher: {{eine einheitliche Methodik}} für das Informationssicherheitsrisikomanagement
Dokumentiert in
−vorher: Risikobewertung
+nachher: Risikobetrachtung
PERF.2.1Überprüfung der Einhaltung von Verpflichtungen
Titel
−vorher: Überwachung der Einhaltung von Verpflichtungen
+nachher: Überprüfung der Einhaltung von Verpflichtungen
BER.3.24Alternative Authentifizierung am IT-System
Erläuterung
−vorher: Wenn Nutzende ihren Primärzugang (z.B. Passwort, Smartphone mit Authentifizierungs-App) verlieren, wird eine alternative Möglichkeit zur Wiederherstellung des Zugangs benötigt. Damit dieser Alternativzugang den Schutz der Primärmethode nicht aushebelt, ist eine vergleichbare Zuverlässigkeit der Authentifizierung erforderlich. Lösungsmöglichkeiten je nach Schutzbedarf sind z.B. (1) die persönliche Vorstellung mit Ausweis, oder (2) die Verifikation über bestehende Sitzungen.oder PUK.
+nachher: Wenn Nutzende ein für die reguläre Authentisierung erforderliches Authentisierungsmittel verlieren oder nicht mehr verwenden können, kann eine alternative Möglichkeit zur Wiederherstellung des Zugangs relevant sein. Hierfür kommen sowohl bereits eingerichtete alternative Authentisierungsmittel als auch besondere Wiederherstellungsverfahren in Betracht. Ein vergleichbares Vertrauensniveau der alternativen Authentisierung oder Wiederherstellung trägt dazu bei, dass der Schutz der regulären Authentisierung nicht unangemessen herabgesetzt wird. Als alternative Authentisierungsmittel kommen beispielsweise ein zusätzlich registrierter kryptografischer Authenticator, eine Smartcard oder andere geeignete Authentisierungsverfahren in Betracht. Möglichkeiten zur Wiederherstellung sind beispielsweise sicher hinterlegte Recovery-Codes bzw. PUKs, die Verifikation über ein noch verfügbares Authentisierungsmittel oder eine bestehende vertrauenswürdige Sitzung sowie eine erneute Identitätsprüfung, etwa durch persönliche Vorstellung und Prüfung eines amtlichen Ausweisdokuments.
−vorher: „Weiterleitung mehrfach verwendbarer Anmeldeinformationen“ (auch als Credential Forwarding oder Credential Delegation bekannt) meint technische Mechanismen, bei denen die Anmeldeinformationen eines Zugangskontos (z.B. Kennworthashes oder Kerberos-Tickets) an ein zweites System weitergereicht werden, um sich dort ebenfalls zu authentifizieren, ohne die Daten erneut eingeben zu müssen. Ziel der Deaktivierung ist hier die Unterbrechung von Angriffsketten, die auf dem Diebstahl von Zugangsdaten basieren. Ein Angreifer könnte sonst nach der Kompromittierung eines weniger kritischen Systems, wie einem Webserver, die dorthin weitergeleiteten Anmeldeinformationen eines Administrators aus dem Arbeitsspeicher auslesen und sich mit diesen Rechten unbemerkt im gesamten Netzwerk weiter ausbreiten (Laterale Bewegung). Das gezielte Deaktivieren des Credential Forwarding kann die Angriffsfläche erheblich reduzieren und solche „Pass-the-Hash“- oder „Pass-the-Ticket“-Angriffe effektiv eindämmen, da Anmeldeinformationen mit hohen Privilegien gar nicht erst auf unsichere Systeme gelangen. Stattdessen kann die Authentifizierung ausschließlich temporäre, eingeschränkte Tickets oder Tokens verwenden. Hierzu gehören z.B. Windows Remote Credential Guard oder RestrictedAdmin, sowie unter Linux SSH-Agent Forwarding oder GSSAPI. Eine Token-basierte Authentifizierung ist eine Strategie zur Verbesserung der Informationssicherheit. Nachdem Benutzende ihre Anmeldedaten eingegeben haben, werden diese überprüft und ein einmaliges verschlüsseltes Token generiert, mit dem sie anschließend auf Online-Ressourcen zugreifen können, ohne bei jeder Anfrage ihren Benutzernamen und ihr Passwort eingeben zu müssen. Bei SSH-Verbindungen kann die unsichere „Agent Forwarding“-Funktion serverseitig in der Konfigurationsdatei deaktiviert werden.
+nachher: „Weiterleitung mehrfach verwendbarer Anmeldeinformationen“ (auch als Credential Forwarding oder Credential Delegation bezeichnet) meint Mechanismen, bei denen Anmeldeinformationen oder daraus abgeleitete Authentisierungsinformationen an ein weiteres System übertragen oder diesem zur weiteren Authentisierung zur Verfügung gestellt werden. Dadurch können auf dem Zielsystem Informationen oder Authentisierungsfähigkeiten verfügbar werden, die bei einer Kompromittierung für weitere Zugriffe missbraucht werden könnten. Die Einschränkung der Weiterleitung kann das Risiko reduzieren, dass Angreifende nach der Kompromittierung eines Systems Anmeldeinformationen oder daraus abgeleitete Authentisierungsinformationen für laterale Bewegungen verwenden. Insbesondere bei privilegierten Zugangskonten kann dadurch vermieden werden, dass wiederverwendbare Anmeldeinformationen auf weniger vertrauenswürdigen Systemen verfügbar werden. Für Remotezugriffe können Verfahren eingesetzt werden, bei denen die Anmeldeinformationen nicht an das Zielsystem übertragen werden. Beispiele unter Windows sind Remote Credential Guard oder Restricted Admin für Remotedesktopverbindungen. Bei SSH-Verbindungen kann auf die Weiterleitung des lokalen SSH-Authentisierungsagenten verzichtet werden. Wird Agent Forwarding nicht benötigt, kann dessen Verwendung client- und serverseitig eingeschränkt werden.
−vorher: Die Isolation von Anwendungen (auch Kapselung oder Application Sandboxing genannt) dient dazu, die Angriffsfläche eines Systems zu reduzieren und die Vertraulichkeit, Integrität sowie Verfügbarkeit kritischer Komponenten besser zu schützen. Durch eine klare Trennung der Anwendungs- und Systemprozesse und von deren Ressourcenzugriffen (Netzwerk, Datei‑ oder Geräte‑I/O) kann eine kompromittierte Applikation nicht unbegrenzt auf weitere Systemressourcen zugreifen, sondern ist auf genau definierte Schnittstellen beschränkt. Bestimmte Anwendungen meint hier, dass konkret festgelegt wird, welche Anwendungen konkret isoliert ausgeführt werden. Dies ermöglicht es, Fehlfunktionen oder Angriffe einzudämmen, Schadsoftware leichter zu erkennen und Verantwortlichkeiten einzelner Module transparent zu halten. Dies kann z.B. durch Containerisierung oder eine Microservice-Architektur, in der jede Komponente nur über REST- oder Message-Queue-Schnittstellen kommuniziert umgesetzt werden. Auch klassische Virtualisierung (Gastsysteme mit Hypervisor) oder Betriebssystemfunktionen wie SELinux/AppArmor‑Profile und chroot‑Jails zählen dazu, weil sie Applikationen auf genau festgelegte Ressourcen beschränken. Im Kontext der Containerisierung empfiehlt es sich ebenfalls eine feste Zuordnung von Containern zu Container-Hosts vorzunehmen.
+nachher: Die Isolation von Anwendungen (auch Application Sandboxing oder Application Confinement genannt) kann die Auswirkungen von Fehlfunktionen oder einer Kompromittierung auf andere Anwendungen und Systemressourcen begrenzen. Hierzu werden Zugriffe einer Anwendung auf beispielsweise Prozesse, Dateisystembereiche, Netzwerkressourcen oder Geräte auf die für ihren Betrieb vorgesehenen Ressourcen und Schnittstellen beschränkt. „Bestimmte Anwendungen“ bezeichnet die Anwendungen, für die aufgrund ihres Einsatzzwecks oder der damit verbundenen Risiken eine isolierte Ausführung vorgesehen ist. Die Isolation kann mit unterschiedlichen technischen Mechanismen umgesetzt werden. Hierzu zählen beispielsweise Betriebssystemfunktionen zur Zugriffsbeschränkung wie SELinux- oder AppArmor-Profile, containerbasierte Isolation oder die Ausführung in virtuellen Maschinen. Die verschiedenen Verfahren bieten unterschiedliche Isolationsstärken. Container teilen sich typischerweise den Kernel des Hostsystems, während virtuelle Maschinen zusätzlich über ein eigenes Gastbetriebssystem und einen eigenen Kernel gegenüber dem Hostsystem abgegrenzt sind.
−vorher: Konfiguration für IT-Systeme SOLLTE Code-Signierung im Betriebssystemkern aktivieren.
+nachher: Konfiguration für IT-Systeme SOLLTE die Signaturprüfung für nachladbaren Code im Kernelmodus aktivieren.
Erläuterung
−vorher: Laufende Kernprozesse des Systems können geschützt werden, indem nur signierter Code hierauf zugreifen darf. Beispiele sind unter Windows der der PPL-Schutz (Protected Process Light) des Local Credential Store (LSA-Schutz) oder unter Linux mit SELinux oder dem Secure Computing Mode.
+nachher: Nachladbarer Code im Kernelmodus verfügt typischerweise über weitreichende Berechtigungen und kann bei einer Kompromittierung erhebliche Auswirkungen auf das gesamte IT-System haben. Eine Signaturprüfung kann dazu beitragen, das Laden von nicht oder nicht vertrauenswürdig signiertem Code im Kernelmodus zu verhindern. Beispiele sind die erzwungene Signaturprüfung von Kernelmodulen unter Linux oder die Signaturprüfung von Kernelmodus-Treibern unter Windows. Die Schutzwirkung der Signaturprüfung hängt von den verwendeten Vertrauensankern ab. Hierbei kann insbesondere berücksichtigt werden, welche Signaturschlüssel beziehungsweise Herausgeber als vertrauenswürdig eingestuft werden. Eine gültige Signatur allein erlaubt keine Aussage über die Sicherheit oder Qualität des signierten Codes.
Ergebnis
−vorher: Code-Signierung im Betriebssystemkern
+nachher: die Signaturprüfung für nachladbaren Code im Kernelmodus
−vorher: … n können sich je nach Institution z. B. aus Grundrechten, Cyber Resilience Act, Data Act, Data Markets Act, NIS, DSGVO, BDSG, TKG, TDDDG oder GeschGehG ergeben. Hierbei werden Verpflic … Markets Act, NIS, DSGVO, BDSG, TKG, TDDDG oder GeschGehG ergeben. Hierbei werden Verpflic …
+nachher: … n können sich je nach Institution z. B. aus Grundrechten, Cyber Resilience Act, Data Act, Digital Markets Act, NIS, DSGVO, BDSG, TKG, TDDDG oder GeschGehG ergeben. Hierbei werden Verpflic … Markets Act, NIS, DSGVO, BDSG, TKG, TDDDG oder GeschGehG ergeben. Hierbei werden Verpflic …
−vorher: Umsetzung MUSS eine Priorisierung der festgelegten Maßnahmen auf Basis der der Risikobewertung, Abhängigkeiten und Ressourcenverfügbarkeit festlegen.
+nachher: Umsetzung MUSS eine Priorisierung der festgelegten Maßnahmen auf Basis der Risikobewertung, Abhängigkeiten und Ressourcenverfügbarkeit festlegen.
Ergebnis, Zusatz
−vorher: auf Basis der der Risikobewertung, Abhängigkeiten und Ressourcenverfügbarkeit
+nachher: auf Basis der Risikobewertung, Abhängigkeiten und Ressourcenverfügbarkeit