Mehrfaktor-Authentifizierung einführen, ohne den Betrieb lahmzulegen
MFA in Microsoft 365 einführen, ohne Ausfälle: Vorgehen in Wellen, Dienstkonten und Scanner, Notfallzugänge und die typischen Stolperfallen.
· 14 Min. Lesezeit · Fachlich geprüft:
Die Frage kommt fast immer in derselben Form: „Uns ist klar, dass wir das brauchen. Aber was passiert am Montagmorgen, wenn sich 40 Leute nicht mehr anmelden können?“ Die Sorge ist berechtigt. Mehrfaktor-Authentifizierung bedeutet: Anmeldung mit einem zweiten Nachweis zusätzlich zum Passwort. Genau diese Sorge ist der Hauptgrund, warum sie in vielen Unternehmen seit Jahren auf der Liste steht, ohne umgesetzt zu werden. Die Risiken einer Einführung sind bekannt und beherrschbar. Sie liegen fast nie dort, wo man sie vermutet.
Kurzantwort
Eine MFA-Einführung legt den Betrieb nicht lahm, wenn sie in Wellen läuft statt an einem Stichtag: erst Bestandsaufnahme aller Konten und Altgeräte, dann Notfallzugänge einrichten, dann Registrierung ohne Zwang, dann Erzwingung gruppenweise. Jede Regel läuft zuerst im Beobachtungsmodus. Für 10 bis 75 Mitarbeitende sind fünf bis sieben Wochen realistisch. Der Beobachtungsmodus setzt eine Entra-ID-P1-Lizenz voraus; in Microsoft 365 Business Premium ist sie enthalten. Die tatsächlichen Ausfälle verursachen erfahrungsgemäß nicht die Mitarbeitenden, sondern Dienstkonten, alte Geräte wie Scanner, die E-Mails versenden, und fehlende Notfallzugänge, wenn eine Regel weiter greift als geplant.
Wer MFA inzwischen verlangt
Drei Entwicklungen der vergangenen zwei Jahre haben die Anforderungen an MFA konkreter gemacht.
Erstens erzwingt Microsoft MFA inzwischen selbst. Seit Oktober 2024 verlangt der Zugriff auf das Azure-Portal, das Entra-Verwaltungsportal und das Intune-Verwaltungsportal eine Mehrfaktor-Anmeldung, seit Februar 2025 auch das Microsoft-365-Admin-Center. Seit dem 1. Oktober 2025 gilt dasselbe für ändernde Zugriffe auf Azure-Ressourcen über Kommandozeile, Skripte und Schnittstellen; reine Lesezugriffe sind ausgenommen. Ein Aufschub war möglich, endete aber am 1. Juli 2026. Ein Opt-out gibt es nicht. Wichtig für die Einordnung: Diese Pflicht betrifft die Verwaltungszugänge, nicht die tägliche Anmeldung an Outlook oder Teams. Ob Ihre Mitarbeitenden MFA nutzen, entscheiden weiterhin Sie.
Zweitens nennt das deutsche BSI-Gesetz Mehrfaktor-Authentifizierung ausdrücklich als Mindestmaßnahme. § 30 Abs. 2 Nr. 10 BSIG verlangt die „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung“. Die Pflicht gilt seit dem 6. Dezember 2025 ohne Übergangsfrist, aber nur für Einrichtungen im Anwendungsbereich. Dieser ist enger als oft dargestellt. Er setzt die Zugehörigkeit zu einem der regulierten Sektoren voraus und in der Regel mindestens 50 Beschäftigte oder mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme. Viele Unternehmen Ihrer Größe fallen nicht direkt darunter; spürbar wird die Regelung dort meist indirekt, weil regulierte Kunden ihre Lieferkette prüfen und die Frage weiterreichen.
Drittens fragen Cyberversicherer danach. Nicht pauschal, sondern für definierte Bereiche: Fernzugriffe, privilegierte Konten, Cloud- und E-Mail-Zugänge. Der oft gehörte Satz „ohne 100 Prozent MFA zahlt die Police nicht“ ist in dieser Form falsch. Nach § 28 Abs. 2 VVG ist ein Versicherer nur bei Vorsatz vollständig leistungsfrei; bei grober Fahrlässigkeit wird anteilig gekürzt, bei einfacher Fahrlässigkeit bleibt die volle Leistungspflicht bestehen. Nach § 28 Abs. 3 VVG bleibt sie außerdem bestehen, wenn die Obliegenheitsverletzung für den Schaden gar nicht ursächlich war. Einen Marktstandard „100 Prozent MFA“ gibt es nicht. Das ist trotzdem kein Argument, es zu lassen: Eine Microsoft-Untersuchung aus dem Jahr 2023 kommt zu dem Ergebnis, dass MFA das Kompromittierungsrisiko über die untersuchte Nutzerbasis um 99,22 Prozent senkt und selbst bei bereits geleakten Zugangsdaten noch um 98,56 Prozent.
Die Reihenfolge: fünf Wellen statt eines Stichtags
| Welle | Was passiert | Dauer |
|---|---|---|
| 0 Bestandsaufnahme | Alle Konten auflisten: Mitarbeitende, Administratoren, Gäste, Dienstkonten, freigegebene Postfächer. Anmeldeprotokolle daraufhin prüfen, welche Anmeldungen heute einfaktorig laufen. | 3–5 Tage |
| 1 Notfallzugänge | Zwei Notfallkonten einrichten und testen, bevor irgendeine Regel scharf geschaltet wird. | 1 Tag |
| 2 Registrierung ohne Zwang | Mitarbeitende hinterlegen ihr zweites Merkmal, ohne dass schon etwas blockiert wird. | 2–3 Wochen |
| 3 Erzwingung gruppenweise | Erst Administratoren, dann eine Pilotgruppe, dann der Rest. Jede Regel mindestens eine Woche im Beobachtungsmodus. | 2–3 Wochen |
| 4 Altlasten schließen | Alte Anmeldeverfahren sperren, Dienstkonten umstellen. | laufend |
Der entscheidende Hebel steckt in Welle 3. Microsoft-Regeln für bedingten Zugriff lassen sich in einem Beobachtungsmodus betreiben: Die Regel wird ausgewertet und protokolliert, blockiert aber nichts. Microsoft empfiehlt ausdrücklich, jede Regel mindestens eine Woche so laufen zu lassen, bevor sie erzwungen wird. So sehen Sie schon vor der Umstellung, wer betroffen wäre. Dabei fällt auch das Kassensystem auf, an das niemand mehr gedacht hat.
In Welle 2 registrieren Mitarbeitende ihr Verfahren selbst über die Seite für Sicherheitsinformationen im eigenen Konto; eine Einladung per E-Mail mit Link und kurzer Anleitung genügt in den meisten Häusern. Wer heute schon per SMS oder Anruf bestätigt, lässt sich zusätzlich über die sogenannte Registrierungskampagne auf die Authenticator-App oder einen Passkey umlenken: Microsoft blendet die Aufforderung nach einer erfolgreichen Anmeldung mit zweitem Faktor ein, und Sie legen fest, wie viele Tage sie sich wegklicken lässt und ob nach drei Verschiebungen Schluss ist. Wichtig ist die Reihenfolge: Die Kampagne erreicht nur, wer sich bereits mit zweitem Faktor anmeldet. Den ersten Schritt ersetzt sie nicht.
Ein Hinweis zur Lizenz: Regeln für bedingten Zugriff setzen Entra ID P1 oder P2 voraus. In Microsoft 365 Business Premium ist P1 enthalten. Viele Häuser haben die Lizenz also bereits, ohne es zu wissen. Ohne sie bleiben nur die „Sicherheitsstandards“, die sich lediglich an- oder ausschalten lassen, ohne Abstufung und ohne Beobachtungsmodus. Die Alternative ist die ältere MFA-Einstellung je Benutzer, mit der sich weder Gruppen noch ein Beobachtungsmodus sauber abbilden lassen. Für ein gestaffeltes Vorgehen ist P1 praktisch Voraussetzung.
Dienstkonten und Altgeräte: hier entstehen die echten Ausfälle
Für Konten, die keine Person bedient, gibt es keine sinnvolle Zweitfaktor-Abfrage. Der Umgang damit ist trotzdem geregelt:
Echte technische Identitäten wie verwaltete Identitäten und Dienstprinzipale sind von der Microsoft-Erzwingung nicht betroffen. Auch das Synchronisierungskonto für den Verzeichnisabgleich ist ausdrücklich nicht betroffen. Wo Automatisierung heute über ein Benutzerkonto mit Passwort läuft, ist die Umstellung auf eine technische Identität die saubere Lösung, nicht eine dauerhafte Ausnahme.
Freigegebene Postfächer brauchen kein Anmeldekonto. Die Anmeldung sollte dort blockiert sein; der Zugriff läuft über die Berechtigungen der persönlichen Konten.
Scanner, Multifunktionsgeräte, Warenwirtschaft und Faxserver, die E-Mails versenden, sind der praktisch wichtigste Fall. Für mobile Postfachsynchronisierung, POP, IMAP, Webdienste und Outlook hat Microsoft die alten Anmeldeverfahren in Exchange Online bereits 2022/2023 abgeschaltet. Einzig der authentifizierte Mailversand (SMTP AUTH) läuft noch mit klassischem Passwort. Damit ist Ende Dezember 2026 Schluss: Microsoft deaktiviert das Verfahren dann standardmäßig in bestehenden Mandanten. Administratoren können es danach zwar noch einmal einschalten, neue Mandanten bekommen es gar nicht mehr. Das endgültige Abschaltdatum will Microsoft in der zweiten Jahreshälfte 2027 nennen.
Konkret heißt das: Wenn Ihr Scanner heute mit einem hinterlegten Postfachpasswort verschickt, haben Sie noch etwa fünf Monate. Prüfen Sie jetzt, ob das Gerät moderne Anmeldung beherrscht, ob ein Firmware-Update das nachrüstet, oder ob der Versand auf einen anderen Weg umgestellt werden muss.
Notfallzugang: zwei Konten, die niemandem gehören
Der häufigste Weg, sich selbst auszusperren, ist eine Regel, die weiter greift als gedacht. Dagegen hilft genau eine Vorkehrung: mindestens zwei Notfallkonten, eingerichtet bevor die erste Regel scharf geschaltet wird. Microsofts Vorgaben dafür sind eindeutig:
- Reine Cloud-Konten auf der
.onmicrosoft.com-Domäne, nicht aus dem lokalen Verzeichnis synchronisiert - Keinem einzelnen Mitarbeitenden zugeordnet, nicht mit privaten Geräten oder Telefonnummern verknüpft
- Anmeldung mit einem phishing-resistenten Verfahren wie Passkey oder Zertifikat, bewusst mit einem anderen Verfahren als die regulären Administratorkonten
- Von allen blockierenden Regeln ausgenommen (Regeln im Beobachtungsmodus brauchen keine Ausnahme)
- Zugangsdaten getrennt und physisch gesichert aufbewahrt
- Jede Anmeldung löst eine Warnung aus, jede Nutzung wird nachbereitet
- Mindestens alle 90 Tage testen, ob die Konten sich tatsächlich anmelden können
Ein Punkt wird regelmäßig falsch gemacht: Notfallkonten sind von Microsofts eigener MFA-Erzwingung nicht ausgenommen. Ein Notfallkonto mit reinem Passwort funktioniert im Ernstfall nicht mehr. Deshalb Passkey oder Zertifikat. Beides erfüllt die Anforderung und ist unabhängig von Mobilfunknetz und Smartphone.
Für den Alltagsfall „Handy vergessen, verloren oder getauscht“ gibt es ein eigenes Werkzeug: einen zeitlich begrenzten Einmalcode, den die Administration ausstellt. Voreingestellt ist eine Stunde Gültigkeit, konfigurierbar bis zu 30 Tage. Damit meldet sich die betroffene Person an und richtet ihr Verfahren neu ein. Das ersetzt den Anruf „Können Sie mir die MFA mal kurz abschalten?“. Genau dieser Anruf schafft die Lücke, die Angreifer im Support-Betrug ausnutzen.
Was Sie Ihren Mitarbeitenden sagen sollten
Drei Botschaften, zwei Wochen vor Welle 3, in einer kurzen E-Mail und einer Viertelstunde im Teammeeting:
- Was sich ändert: Bei der Anmeldung kommt ein zweiter Schritt hinzu. Nicht jedes Mal, auf bekannten Geräten deutlich seltener, als die meisten befürchten.
- Warum: Nicht „wegen der IT“, sondern weil ein gestohlenes Passwort sonst genügt, um in Ihrem Namen Rechnungen umzuleiten. Nennen Sie einen konkreten Vorgang aus Ihrem Haus.
- Was zu tun ist, wenn etwas klemmt: Eine benannte Person, eine Nummer, eine erreichbare Zeit. Und die klare Regel: Wer eine Anfrage nicht selbst ausgelöst hat, bestätigt sie nicht. Auch dann nicht, wenn sie zum fünften Mal kommt.
Der letzte Punkt ist wichtiger, als er klingt. Angreifer mit gestohlenem Passwort lösen bewusst wiederholt Bestätigungsanfragen aus, bis jemand entnervt zustimmt. Die Authenticator-App verlangt dagegen bei Push-Bestätigungen standardmäßig den Zahlenabgleich: Wer bestätigen will, muss eine am Bildschirm angezeigte Zahl in der App eintippen; abschalten lässt sich das nicht. Zusätzlich lässt sich einstellen, dass die Anfrage Anmeldeort und Anwendungsnamen mit anzeigt. Das gibt Ihren Leuten den Kontext, um eine fremde Anfrage als solche zu erkennen.
Typische Stolperfallen
| Stolperfalle | Folge | Vermeidung |
|---|---|---|
| Notfallkonten erst nach der ersten Regel angelegt | Aussperrung ohne Rückweg | Welle 1 vor Welle 3, ausnahmslos |
| Notfallkonto nur mit Passwort | Funktioniert im Ernstfall nicht | Passkey oder Zertifikat hinterlegen |
| Ausnahmen nicht getestet | Ausgenommene Person wird trotzdem geblockt | Ausschlüsse aktiv gegentesten |
| Scanner und Warenwirtschaft übersehen | Versand bricht ab | Anmeldeprotokolle auf Altverfahren auswerten |
| Dienstkonten dauerhaft ausgenommen | Ausnahme wird zur Dauerlösung | Auf technische Identitäten umstellen |
| Erzwingung ohne Beobachtungsmodus | Ausfall am Stichtag | Mindestens eine Woche beobachten |
| Alle gleichzeitig umstellen | Support bricht zusammen | Gruppenweise, Administratoren zuerst |
| Alte Anmeldeverfahren nicht gesperrt | MFA lässt sich umgehen | Sperrregel als eine der ersten setzen |
Der vorletzte Punkt verdient Nachdruck: Solange veraltete Anmeldeverfahren erlaubt sind, lässt sich die Mehrfaktor-Abfrage umgehen. Microsoft ordnet die Sperrregel für Altverfahren deshalb schon der ersten Phase der empfohlenen Einführung zu. Sie steht damit noch vor der eigentlichen MFA-Pflicht.
Ein organisatorischer Punkt zum Abschluss: Seit dem 30. September 2025 lassen sich Anmeldeverfahren nicht mehr in den alten Verwaltungsbereichen für MFA und Passwortzurücksetzung pflegen. Wer dort noch Einstellungen hat, sollte sie in die zentrale Verwaltung der Authentifizierungsmethoden überführt haben.
Wie Sie sich selbst einordnen
Fünf Fragen, die Sie Ihrem IT-Dienstleister stellen können. Sie zielen nicht auf Tempo, sondern darauf, ob es zu jedem Punkt eine dokumentierte Antwort gibt:
- Wie viele Notfallkonten existieren, und wann wurden sie zuletzt erfolgreich getestet?
- Welche Konten melden sich derzeit noch einfaktorig an? Und welche davon sind Administratoren?
- Sind veraltete Anmeldeverfahren gesperrt?
- Welche Geräte und Anwendungen versenden noch mit hinterlegtem Postfachpasswort, und wie sieht der Plan für Ende Dezember 2026 aus?
- Läuft eine Warnung auf, wenn sich ein Notfallkonto anmeldet?
Die Antworten liegen selten auf Anhieb vor. Sie stehen in den Anmeldeprotokollen, in den Richtlinien und in der Gerätekonfiguration; dort müssen sie nachgesehen werden. Für die Planung bleibt es bei fünf bis sieben Wochen, und ein großer Teil davon ist Wartezeit: Die Registrierung läuft nebenher, und jede Regel steht mindestens eine Woche im Beobachtungsmodus, bevor sie greift. Der Aufwand steckt in der Liste der Geräte und Dienstkonten, die niemand als Benutzer wahrnimmt. Wer diese Liste hat, hat den schwierigen Teil hinter sich.
Quellen
- Microsoft erzwingt MFA für Azure-Portal, Entra-Verwaltungsportal und Intune-Verwaltungsportal seit Oktober 2024, für das Microsoft-365-Admin-Center ab Februar 2025 und seit dem 1. Oktober 2025 für Azure CLI, PowerShell, mobile App, IaC-Werkzeuge, SDKs und REST-API-Endpunkte (Phase 2). Phase 2 gilt für Erstellen-, Ändern- und Löschen-Vorgänge an Azure-Ressourcen; reine Lesevorgänge erfordern keine MFA. Ein Aufschub der Phase 2 war maximal bis zum 1. Juli 2026 möglich; ein Opt-out gibt es nicht (learn.microsoft.com)
- Notfall- bzw. Break-Glass-Konten sind von der Microsoft-seitigen MFA-Erzwingung ausdrücklich NICHT ausgenommen. Microsoft empfiehlt, diese Konten auf Passkey (FIDO2) oder zertifikatsbasierte Authentifizierung umzustellen; beide Verfahren erfüllen die MFA-Anforderung (learn.microsoft.com)
- Workload-Identitäten wie verwaltete Identitäten und Dienstprinzipale sind von beiden Phasen der MFA-Erzwingung nicht betroffen. Benutzerkonten, die als Dienstkonten für Automatisierung genutzt werden, sind betroffen und sollten auf Workload-Identitäten migriert werden. Das Synchronisierungskonto von Microsoft Entra Connect bzw. Cloud Sync ist nicht betroffen (learn.microsoft.com)
- Anforderungen an Notfallzugangskonten: mindestens zwei Konten, reine Cloud-Konten auf der .onmicrosoft.com-Domäne ohne Föderation oder Synchronisierung, phishing-resistente Verfahren (FIDO2 oder Zertifikat) und bewusst andere Verfahren als bei regulären Administratorkonten, keine Zuordnung zu einzelnen Personen oder deren Geräten, Ausschluss von blockierenden Richtlinien für bedingten Zugriff (Richtlinien im Nur-Bericht-Modus brauchen keinen Ausschluss), Aufbewahrung der Zugangsdaten in getrennten gesicherten Orten, Überwachung und Alarmierung bei jeder Anmeldung, Validierung mindestens alle 90 Tage (learn.microsoft.com)
- Microsoft empfiehlt, jede Richtlinie für bedingten Zugriff mindestens eine Woche im Nur-Bericht-Modus (report-only) laufen zu lassen, bevor sie erzwungen wird; Ausschlusskriterien sind aktiv gegenzutesten; Rollback erfolgt durch Deaktivieren der Richtlinie. Die empfohlene Einführung führt die Sperre veralteter Authentifizierung und die Absicherung der Registrierungsseite in Phase 1. Die MFA-Pflicht für alle Nutzer folgt in Phase 2 (learn.microsoft.com)
- Richtlinien für bedingten Zugriff setzen eine Microsoft-Entra-ID-P1- oder -P2-Lizenz voraus. Ohne diese Lizenz stehen nur die Sicherheitsstandards (security defaults) zur Verfügung. Conditional Access und Sicherheitsstandards lassen sich nicht kombinieren (learn.microsoft.com)
- Microsoft Entra ID P1 ist unter anderem in Microsoft 365 Business Premium, E3 und E5 enthalten (learn.microsoft.com)
- Die Registrierungskampagne fordert Nutzer im Anschluss an eine erfolgreiche Mehrfaktor-Anmeldung zur Einrichtung von Authenticator oder Passkey auf; sie greift nur bei Nutzern, die MFA mit Microsoft Entra MFA durchführen, und ersetzt die Erstregistrierung nicht. Die Verschiebedauer (snoozeDurationInDays) ist von 0 bis 14 Tagen konfigurierbar (Voreinstellung ein Tag); mit aktivierter Begrenzung ist die Einrichtung nach drei Verschiebungen verpflichtend. Eine besondere Lizenz ist nicht erforderlich (learn.microsoft.com)
- Ein Temporary Access Pass ist ein zeitlich begrenzter Zugangscode für Onboarding und für die Wiederherstellung, wenn ein Nutzer sein Authentifizierungsmerkmal verloren hat. Standardgültigkeit ist eine Stunde, der zulässige Bereich reicht von 10 Minuten bis 43.200 Minuten (30 Tage); Einmal- oder Mehrfachnutzung ist konfigurierbar. Er ersetzt nicht das Passwort des Nutzers (learn.microsoft.com)
- Basic Authentication ist in Exchange Online für Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover, Outlook für Windows und Outlook für Mac abgeschaltet und kann weder von Kunden noch vom Microsoft-Support wieder aktiviert werden. SMTP AUTH ist davon zunächst ausgenommen (learn.microsoft.com)
- SMTP AUTH mit Basic Authentication bleibt bis Dezember 2026 unverändert; Ende Dezember 2026 wird das Verfahren in bestehenden Mandanten standardmäßig deaktiviert (Administratoren können es bei Bedarf wieder aktivieren). Nach Dezember 2026 erstellte Mandanten haben es nicht mehr verfügbar. Das endgültige Abschaltdatum will Microsoft in der zweiten Jahreshälfte 2027 bekanntgeben. Alternativen sind OAuth, High Volume Email für Microsoft 365 und Azure Communication Services for Email (techcommunity.microsoft.com)
- Seit dem 30. September 2025 können Authentifizierungsmethoden nicht mehr in den alten MFA- und SSPR-Richtlinien verwaltet werden; die Verwaltung erfolgt über die Authentication-methods-Richtlinie (learn.microsoft.com)
- Der Zahlenabgleich (number matching) ist für alle Push-Benachrichtigungen von Microsoft Authenticator aktiviert; Nutzer können ihn nicht abwählen (learn.microsoft.com)
- In den Einstellungen für passwortlose Anmeldung mit Microsoft Authenticator lassen sich Anmeldeort und Name der Anwendung einblenden; diese Optionen geben Nutzern Kontext und helfen, versehentliche MFA-Bestätigungen zu verhindern (learn.microsoft.com)
- Anmeldungen mit der Authentifizierungsanforderung „Single-factor authentication“ im Anmeldeprotokoll zeigen, dass keine MFA-Richtlinie gegriffen hat; darüber lassen sich Abdeckungslücken identifizieren, besonders bei Administratoren (learn.microsoft.com)
- § 30 Abs. 2 Nr. 10 BSIG verlangt die „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme“ als eine der zehn Mindestmaßnahmen (gesetze-im-internet.de)
- § 28 BSIG regelt den Anwendungsbereich: Erfasst sind Einrichtungen der aufgeführten Sektoren, die die Größenschwellen erreichen. Für wichtige Einrichtungen sind das in der Regel mindestens 50 Beschäftigte oder mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme, für besonders wichtige Einrichtungen mindestens 250 Beschäftigte oder mehr als 50 Millionen Euro Jahresumsatz und mehr als 43 Millionen Euro Jahresbilanzsumme (gesetze-im-internet.de)
- Die Risikomanagementmaßnahmen nach § 30 BSIG gelten seit dem 6. Dezember 2025 ohne Übergangsfrist (bsi.bund.de)
- Eine Microsoft-Untersuchung aus dem Jahr 2023 auf Basis von Azure-Active-Directory-Nutzerdaten kommt zu dem Ergebnis, dass MFA das Kompromittierungsrisiko über die untersuchte Population um 99,22 Prozent und bei bereits geleakten Zugangsdaten um 98,56 Prozent senkt (arxiv.org)
- Das BSI empfiehlt überall dort, wo möglich, die Einrichtung und Verwendung einer Zwei-Faktor-Authentisierung; FIDO2-Token gelten bei korrekt implementiertem Token-Binding als resistent gegen übliche Phishing-Angriffe (bsi.bund.de)
Rechts- und Produktstand Juli 2026. Keine Rechtsberatung. Regulatorische Angaben und Herstellerbezeichnungen ändern sich. Wir prüfen diesen Beitrag quartalsweise nach und weisen das Prüfdatum oben aus.