← Zurück zum Fachleitfaden
Format: DIN A4 Druckvorlage
🔒 Exklusives Arbeitsmittel

Mandanten-Login erforderlich

Dieses druckfertige Arbeitsmittel steht Kunden und Mandanten der DKSchV zur Verfügung. Melden Sie sich an, um das Arbeitsblatt zu nutzen, zu drucken oder als PDF zu speichern.

DKSchV Schweiz · Dokumentiertes Arbeitsmittel

Passkey-Rollout-Checkliste für Microsoft 365 und Entra ID

Stand 1. November 2026 · Zielgruppe: Schweizer KMU Geschäftsleitungen & IT

DKSchV Schweiz

Arbeitsmittel zum Artikel: Microsoft 365 MFA und Passkeys für Schweizer KMU: Rollout zu den Microsoft-Terminen 2027

Version: 1. November 2026

Status: Arbeitsvorlage – nicht freigegeben; vor produktiver Durchsetzung ⚖️ Fachprüfung erforderlich


Zweck

Diese Checkliste unterstützt Schweizer KMU dabei, die Ablösung von Microsoft-bereitgestellter SMS- und Sprachanruf-MFA in Microsoft Entra ID planbar vorzubereiten. Sie verbindet Inventar, Pilot, Conditional Access, Wiederherstellung und Benutzerkommunikation. Sie hilft, Auslassungen sichtbar zu machen, ersetzt aber weder die Prüfung des konkreten Entra-Tenants noch Herstellerdokumentation, Lizenzprüfung oder eine allfällig erforderliche rechtliche Fachprüfung.

Die Microsoft-Termine gelten nach Herstellerangaben für Entra ID in der Public Cloud: Seit 1. September 2026 werden Benutzer, die für SMS oder Voice aktiviert sind, für Passkeys automatisch aktiviert und können durch eine Registrierungskampagne angesprochen werden. Ab 1. Februar 2027 stellt Microsoft die bereitgestellte SMS-/Sprachübermittlung für alle Benutzer ausser globalen Administratoren und externen Benutzern ein; interne Gastbenutzer bleiben in dieser Februar-Gruppe. Für globale Administratoren und externe Benutzer gilt der 1. Juli 2027. Für einen belegten betrieblichen, regulatorischen oder technischen Bedarf an SMS oder Sprache dokumentiert Microsoft CYOT seit 30. Oktober 2026 als allgemein verfügbar für Workforce-Tenants in global Azure. Soprano, Telesign und Infobip nennt Microsoft als Anbieter. Das bestätigt weder die Berechtigung eines bestimmten Tenants noch regionale Zustellung in der Schweiz, ein verfügbares Angebot, Lizenzvoraussetzungen oder eine funktionierende Integration. ⚖️ Fachprüfung erforderlich Prüfen Sie Geltungsbereich, Termine, Lizenzen, Anbieterabdeckung, Azure-Voraussetzungen und Tenant-Konfiguration vor jeder produktiven Änderung erneut gegen die aktuelle Microsoft-Dokumentation. [1] [2] [8] [9] [10]

Anwendung

Füllen Sie die Vorlage vor dem Pilot aus. Verwenden Sie je eine Ausgabe pro Tenant oder klar abgegrenztem Rollout. Kennzeichnen Sie einen Kontrollpunkt erst als abgeschlossen, wenn ein Nachweis vorhanden ist, zum Beispiel ein Protokollauszug, ein dokumentierter Test oder eine freigegebene Kommunikationsvorlage. Behandeln Sie jede Ausnahme als befristete Risikoentscheidung mit verantwortlicher Person.

Organisation / TenantVerantwortliche PersonDatum der letzten Aktualisierung
Geplantes DurchsetzungsdatumFachliche Prüfung durchNächster Testtermin

1. Ausgangslage und Entscheidungsrahmen

KontrollpunktStatus (☐ / ☑ / n. a.)Nachweis / BemerkungEigentümerTermin
Die Public-Cloud-Anwendbarkeit und die für unsere Benutzer geltende Microsoft-Frist sind geprüft.☐
Benutzer mit SMS oder Sprachanruf sind mit dem Microsoft-Auswertungsweg identifiziert.☐
Die betroffenen Benutzer sind nach Rollen, Gerätetypen und kritischen Anwendungen gruppiert.☐
Privilegierte Rollen, IT-Provider, Finanz- und Personalrollen sowie interne und externe Gäste sind separat markiert.☐
Legacy- oder Altanwendungen ohne moderne Anmeldung/MFA-Unterstützung sind erfasst.☐
Für jede Ausnahme bestehen Begründung, Risiko, Eigentümer, Ablaufdatum und Entscheid.☐
Für eine SMS-/Voice-Ausnahme ist dokumentiert, weshalb keine phishing-resistente Methode genügt.☐
Bei geplanter CYOT-Nutzung sind Workforce-Tenant in global Azure, Anbieterangebot, regionale Abdeckung einschliesslich Schweiz, Vertrag, Kosten, Datenschutz und Azure-Subscription fachlich geprüft.☐
Die Geschäftsleitung kennt die offenen Risiken und den Rolloutentscheid.☐

Offene Risiken / Entscheide:

Risiko oder AusnahmeGeschäftsauswirkungEntscheidung / MassnahmeEigentümerAblauf / Review

2. Passkey-Design und Pilot

Ein Passkey ist ein FIDO2-basierter Anmeldenachweis, bei dem der private Schlüssel beim Authenticator bleibt. Synchronisierte Passkeys können über einen Plattform-Schlüsselbund auf den berechtigten Geräten einer Person verfügbar sein; gerätegebundene Passkeys bleiben auf einem bestimmten Gerät, etwa einem FIDO2-Sicherheitsschlüssel. Die Auswahl muss zu Rolle, Gerät, Wiederherstellung und Risiko passen. [3]

KontrollpunktStatus (☐ / ☑ / n. a.)Nachweis / BemerkungEigentümerTermin
Für jede Benutzergruppe ist die vorgesehene Passkey-Variante festgelegt.☐
Für privilegierte Rollen ist eine besondere Passkey- und Aufbewahrungsregel dokumentiert.☐
Der Pilot umfasst repräsentative Benutzerprofile und tatsächlich eingesetzte Windows-, macOS-, iOS- und/oder Android-Geräte.☐
Eine eigene Entra-Gruppe begrenzt Methoden- und Richtlinienumfang im Pilot.☐
Pilotpersonen können Passkeys registrieren und sich an Microsoft 365 sowie an kritischen Anwendungen erneut anmelden.☐
Der Einsatz von Passkeys auf gemeinsam genutzten Geräten ist ausdrücklich getestet oder ausgeschlossen.☐
Pilotfeedback, Registrierungsquote, Fehlerfälle und daraus abgeleitete Anpassungen sind festgehalten.☐
Die Pilotabnahme ist durch IT und verantwortliche Fachseite freigegeben.☐

Pilotgruppe / Abnahmekriterien:

Gruppe / GeräteprofilAnzahl geplantKritische Anwendungen getestetErgebnisFreigabe durch
☐ Ja ☐ Nein
☐ Ja ☐ Nein
☐ Ja ☐ Nein

3. Conditional Access kontrolliert einführen

Conditional Access steuert den Zugriff nach Bedingungen wie Benutzergruppe und Anwendung. Die Microsoft-Authentisierungsstärke «phishing-resistant MFA» lässt nur definierte phishing-resistente Methoden zu. Regeln müssen zuerst in einer begrenzten Gruppe und im Berichtsmodus geprüft werden; eine aktiv geschaltete Fehlkonfiguration kann Zugänge blockieren. [4] [5]

KontrollpunktStatus (☐ / ☑ / n. a.)Nachweis / BemerkungEigentümerTermin
Jede Regel hat einen eindeutigen Namen, Zweck, Zielressourcen, einbezogene Gruppe und Ausnahmebegründung.☐
Der Berichtsmodus ist aktiviert und Auswirkungen sind in Anmeldeprotokollen geprüft.☐
Pilotbenutzer verfügen vor der Durchsetzung über die geforderte, registrierte Methode.☐
Notfallzugangskonten sind von blockierenden oder einschränkenden Regeln ausgeschlossen.☐
Kritische Geschäftsanwendungen und Administrationspfade sind mit der geplanten Regel getestet.☐
Die aktive Durchsetzung erfolgt nur nach dokumentierter Pilotabnahme und Benutzerinformation.☐
Nach der Aktivierung sind Anmeldeprotokolle und Supportfälle während der festgelegten Beobachtungszeit kontrolliert.☐

Richtlinienübersicht:

RegelnameZielgruppe / RessourceBerichtsmodus geprüft amAktive Durchsetzung abAusnahmegruppeEigentümer

4. Wiederherstellung und Notfallzugang

Ein verlorenes oder defektes Gerät darf nicht zu improvisierter Identitätsprüfung führen. Microsoft beschreibt den Temporary Access Pass (TAP) als zeitlich begrenzten Code, mit dem Benutzer einen Passkey einrichten und nach Verlust einer starken Methode wieder in einen geordneten Zustand zurückkehren können. Der TAP-Wert ist nach dem Anzeigen nicht erneut abrufbar. [6]

KontrollpunktStatus (☐ / ☑ / n. a.)Nachweis / BemerkungEigentümerTermin
Der Identitätsprüfprozess vor einer Wiederherstellung ist schriftlich festgelegt und geübt.☐
Die TAP-Richtlinie, berechtigte Gruppen, Lebensdauer und Ausgabeberechtigungen sind festgelegt.☐
Sichere Übergabe und Dokumentation eines TAP sind definiert.☐
Der Ablauf «Gerät verloren», «Sicherheitsschlüssel verloren» und «Gerätewechsel» ist im Pilot getestet.☐
Alte oder verlorene Authentisierungsmethoden werden nach erfolgreicher Wiederherstellung bereinigt.☐
Mindestens zwei cloud-only Notfallzugangskonten bestehen und verwenden eine vom normalen Adminweg unabhängige phishing-resistente Methode.☐
Notfallzugänge sind sicher, getrennt und für mehrere berechtigte Personen verfügbar verwahrt.☐
Jede Nutzung von Notfallzugängen löst eine Überwachung aus; die Konten sind regelmässig getestet.☐
Bei geplanter CYOT-Nutzung ist der Ausfall der SMS-/Voice-Zustellung im Wiederherstellungs- und Notfallablauf behandelt.☐

Wiederherstellungs-Testprotokoll:

SzenarioGetestet amErgebnisFestgestellte LückeKorrektur bisFreigabe
Verlorenes Mobilgerät
Verlorener Sicherheitsschlüssel
Admin-Aussperrung / Notfallzugang

5. Benutzerkommunikation und Support

Kommunizieren Sie in Wellen: zuerst das «Warum» und den Zeitrahmen, danach die konkrete Handlung pro Gerätetyp und schliesslich zielgruppenspezifische Erinnerungen. Die Nachricht muss einen verlässlichen Supportweg nennen und darf Benutzer nie auffordern, Passwort, Einmalcode oder Entsperrung eines Passkeys weiterzugeben. Microsoft empfiehlt Kommunikation entlang der Phasen Awareness, Action und Reminder. [1]

KontrollpunktStatus (☐ / ☑ / n. a.)Nachweis / BemerkungEigentümerTermin
Zielgruppen und Reihenfolge der Kommunikationswellen sind definiert.☐
Die Erstaussendung erklärt Änderung, Termin, Nutzen, Handlung und verlässlichen Supportweg.☐
Es bestehen geprüfte Kurzanleitungen für die tatsächlich unterstützten Gerätetypen.☐
Die Kommunikation enthält eine Phishing-Warnung und keinen unerwarteten Anmeldelink.☐
Der Support kennt Wiederherstellungsprozess, Eskalationsweg und Grenzen der Identitätsprüfung.☐
Erinnerungen richten sich nur an Benutzer mit fehlender Registrierung oder fehlgeschlagenem Pilot.☐
Supportfälle, wiederkehrende Fragen und Kommunikationsanpassungen sind ausgewertet.☐

Kommunikationsplan:

WelleZielgruppeKernaussage / HandlungVersanddatumSupportkontaktErgebnis / Nachfassaktion
Awareness
Action
Reminder

6. Rollout-Freigabe und Nachsteuerung

FreigabekriteriumErfüllt (☐ / ☑)Nachweis / RestpunktFreigabe durchDatum
Pilot und Wiederherstellungsfälle sind erfolgreich getestet oder bekannte Grenzen als Risiko entschieden.☐
Conditional-Access-Auswirkungen sind im Berichtsmodus geprüft und Ausnahmegruppen sind minimal.☐
Notfallzugänge sind funktionsfähig, überwacht und getestet.☐
Benutzerkommunikation und Supportbereitschaft sind bestätigt.☐
SMS-/Voice-Restbestand und Ausnahmen sind vor der relevanten Microsoft-Frist aktiv entschieden.☐
CYOT-Ausnahmen sind nur nach dokumentiertem Evaluations- und Produktionstest mit stufenweiser Verkehrsverlagerung freigegeben; bestehende SMS-/Voice-Zielgruppen wurden dabei nicht unbeabsichtigt geändert.☐
Nachkontrolle von Registrierung, Anmeldung und Support ist terminiert.☐

Rolloutentscheid:

☐ Freigabe für nächste Gruppe

☐ Zurück in Pilot / Anpassung erforderlich

☐ Ausnahme oder Verschiebung mit dokumentiertem Risikoentscheid

Entscheid, Begründung und Unterschrift / Freigabe:


Grenzen

Diese Checkliste ist eine organisatorische Arbeitsvorlage. Sie garantiert weder eine unterbruchsfreie Anmeldung noch vollständigen Schutz vor Kontoübernahmen oder Phishing. Passkeys reduzieren bestimmte Phishing-Risiken, ersetzen aber nicht sichere Endgeräte, Berechtigungsmanagement, Protokollierung, Benutzeraufmerksamkeit und Incident Response. Herstellerfunktionen, Lizenzvoraussetzungen, unterstützte Geräte sowie Microsoft-Termine können sich ändern; prüfen Sie vor jedem produktiven Schritt die aktuelle Herstellerdokumentation.

Art. 8 DSG verlangt geeignete technische und organisatorische Massnahmen für eine dem Risiko angemessene Datensicherheit. Der Wortlaut wurde am 1. November 2026 anhand der amtlichen Fedlex-XML-Fassung und Chronologie geprüft; die jüngste dort ausgewiesene Fassung hat den Stand 7. Juli 2025. ⚖️ Fachprüfung erforderlich Ob die konkreten Einstellungen, Verfahren und allfälligen Branchenvorgaben Ihres Unternehmens genügen, muss fachlich und bei Bedarf rechtlich geprüft werden. Dieses Arbeitsmittel und die Quellenprüfung erteilen keine individuelle Rechtsfreigabe. [7]

Quellen

DKSchV Dini · Bammattenweg 19, CH-3904 Naters · www.dkschv.ch
Vertrauliche Arbeitsunterlage · Rechts- & Fachprüfung vorbehalten