Jenseits von SMS-Codes: Ein technischer Leitfaden zur Entra ID Passkey Integration für eigene Applikationen

Die Sicherheitskrise veralteter Multi-Faktor-Authentifizierung

Ein einziger SIM-Swapping- oder SMS-Abfang-Angriff kann eine veraltete Multi-Faktor-Authentifizierung (MFA) in weniger als 10 Minuten umgehen und kritische Unternehmensdatenbanken für unbefugte Zugriffe offenlegen. Dennoch zeigen Sicherheitsaudits, dass über 65 % der europäischen Unternehmen nach wie vor auf SMS-Codes oder Sprachanrufe als zweiten Authentifizierungsfaktor setzen. Diese Abhängigkeit schafft eine enorme, hochgradig anfällige Angriffsfläche.

Microsoft erzwingt nun einen entscheidenden Wandel, indem Passkeys zur Standard-Authentifizierungsmethode in Microsoft Entra ID werden. Dieses Update leitet das schrittweise Ende der SMS- und sprachbasierten Verifizierung ein. Für technologische Führungskräfte und Softwarearchitekten ist dies eine technische Vorgabe, eigene Web-, Desktop- und mobile Applikationen zu aktualisieren, um die passwortlosen FIDO2- und WebAuthn-Protokolle zu unterstützen.

Die Umsetzung dieses Übergangs erfordert ein tiefes Verständnis kryptografischer Authentifizierung und moderner Webstandards. Wenn Ihre Anwendungen mit eigenen Frontends entwickelt wurden, die an Microsoft Entra ID angebunden sind, müssen Sie Ihre Authentifizierungsschichten anpassen, um native Biometrie und Hardwareschlüssel zu unterstützen. Dieser Leitfaden erläutert im Detail, warum dieser Wandel stattfindet, wie WebAuthn unter der Haube funktioniert und wie Sie eine Entra ID Passkey Integration in Ihrem eigenen Software-Stack implementieren.

Jahrelang galt SMS-basierte MFA als vertretbarer Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. Moderne Angriffsvektoren haben sie jedoch obsolet gemacht. Angreifer umgehen SMS und zeitbasierte Einmalpasswörter (TOTP) heute mithilfe von Echtzeit-Reverse-Proxy-Phishing-Kits wie Evilginx. Diese Kits agieren als Man-in-the-Middle und leiten Anmeldeanfragen transparent zwischen dem Benutzer und dem tatsächlichen Identity Provider weiter.

Der Angreifer fängt dabei nicht nur das Passwort und den MFA-Code ab, sondern auch das resultierende Session-Cookie. Dies ermöglicht es ihm, die authentifizierte Sitzung vollständig zu übernehmen. Eine weitere kritische Schwachstelle ist SIM-Swapping. Hierbei bringt ein Angreifer einen Mobilfunkanbieter mittels Social Engineering dazu, die Rufnummer des Opfers auf eine neue SIM-Karte zu übertragen. Sobald dies geschehen ist, empfängt der Angreifer alle für das Opfer bestimmten SMS-Codes.

Darüber hinaus basieren SMS und Sprachanrufe auf dem Telekommunikationsprotokoll Signaling System No. 7 (SS7). Dieses Protokoll weist gut dokumentierte Schwachstellen auf, die es staatlichen Akteuren und hochentwickelten Hackern ermöglichen, Textnachrichten und Anrufe aus der Luft abzufangen. Im Gegensatz dazu basieren Passkeys auf dem FIDO2-Standard, der die W3C Web Authentication (WebAuthn) API und das Client-to-Authenticator Protocol (CTAP) kombiniert.

Passkeys nutzen asymmetrische Public-Key-Kryptografie. Bei der Registrierung generiert das Gerät des Benutzers ein eindeutiges kryptografisches Schlüsselpaar. Der Private Key wird sicher in der Hardware-Enklave des Geräts gespeichert, beispielsweise in einem TPM-Chip oder der Secure Enclave von Apple. Der Public Key wird anschließend an den Identity Provider gesendet.

Im Gegensatz zu Passwörtern oder OTPs sind Passkeys kryptografisch an die spezifische Domain der Website oder Anwendung gebunden. Beim Login überprüft der Browser die Domain Origin, bevor er den Benutzer zur biometrischen Bestätigung auffordert. Wird ein Mitarbeiter dazu verleitet, eine gefälschte Login-Seite aufzurufen, erkennt der Browser die Diskrepanz und verweigert die Freigabe der Anmeldedaten. Dieser Mechanismus senkt die Rate des Phishing-basierten Identitätsdiebstahls (Credential Theft) von rund 82 % auf praktisch 0 %.

Die folgende Tabelle stellt die Sicherheits- und Betriebsmerkmale traditioneller MFA-Methoden denen von Passkeys gegenüber:

Technische Anatomie des WebAuthn-Lebenszyklus

Für eine erfolgreiche Passkey-Integration müssen Entwickler das Zusammenspiel zwischen Relying Party, Client und Authenticator verstehen. Die Relying Party ist Ihr Anwendungs-Backend, während der Client der Browser oder die native App ist. Der Authenticator bezeichnet den Biometrie-Chip oder den Hardwareschlüssel. Dieser Lebenszyklus besteht aus zwei primären Phasen: Registrierung (Registration) und Verifizierung (Assertion).

Während der Registrierung fordert Ihre Anwendung die Erstellung neuer Anmeldedaten (Credentials) an. Das Backend muss eine kryptografisch sichere, zufällige Challenge generieren, um Replay-Angriffe zu verhindern. Die clientseitige Anwendung ruft anschließend die WebAuthn-API via JavaScript auf.

// TypeScript: Client-side Passkey Registration using WebAuthn API
interface PasskeyRegistrationOptions {
  challenge: string;      // Base64URL encoded random bytes from the backend
  rpName: string;         // Relying Party name (your company name)
  rpId: string;           // Relying Party domain (must match current domain origin)
  userId: string;         // Unique user identifier generated by the backend
  userName: string;       // User's login name (e.g., email address)
  userDisplayName: string;// User's readable display name
}

export async function registerPasskey(options: PasskeyRegistrationOptions): Promise<PublicKeyCredential | null> {
  try {
    // Convert base64url challenge and user ID string to ArrayBuffer objects
    const challengeBuffer = Uint8Array.from(atob(options.challenge), c => c.charCodeAt(0));
    const userIdBuffer = new TextEncoder().encode(options.userId);

    const publicKeyCredentialCreationOptions: PublicKeyCredentialCreationOptions = {
      challenge: challengeBuffer,
      rp: {
        name: options.rpName,
        id: options.rpId, // e.g., "portal.projectmakers.de"
      },
      user: {
        id: userIdBuffer,
        name: options.userName,
        displayName: options.userDisplayName,
      },
      pubKeyCredParams: [
        {
          type: "public-key",
          alg: -7, // ES256: ECDSA using P-256 curve and SHA-256 (standard for mobile/biometrics)
        },
        {
          type: "public-key",
          alg: -257, // RS256: RSASSA-PKCS1-v1_5 using SHA-256 (fallback for legacy systems)
        }
      ],
      authenticatorSelection: {
        authenticatorAttachment: "platform", // "platform" forces FaceID/TouchID/Windows Hello
        userVerification: "required",        // Demands PIN or biometric confirmation
        residentKey: "required",             // Required for passwordless (discoverable credentials)
      },
      timeout: 60000, // 60-second execution window
      attestation: "none" // Omit hardware attestation data for privacy and compliance
    };

    const credential = await navigator.credentials.create({
      publicKey: publicKeyCredentialCreationOptions
    }) as PublicKeyCredential;

    return credential;
  } catch (error) {
    console.error("Passkey registration failed in the browser:", error);
    throw error;
  }
}

In diesem Code muss rp.id strikt mit der aktuellen Domain Origin der Anwendung übereinstimmen. Das Array pubKeyCredParams spezifiziert die kryptografischen Algorithmen, wobei ES256 für ECDSA unter Verwendung der P-256-Kurve und SHA-256 steht. Die Option userVerification: 'required' stellt sicher, dass das Gerät den Benutzer zur Eingabe biometrischer Daten oder einer PIN auffordert. Dies garantiert, dass zwei Faktoren in einer einzigen, nahtlosen Geste validiert werden.

Wenn ein Benutzer versucht, sich anzumelden, stellt das Backend eine weitere eindeutige Challenge bereit. Das Frontend ruft navigator.credentials.get() auf und übergibt die Challenge sowie die registrierte Credential-ID. Der Authenticator fordert den Benutzer zu seiner biometrischen Geste auf, signiert die Challenge und gibt die Signatur an das Frontend zurück. Das Backend verifiziert diese Signatur mithilfe des gespeicherten Public Keys, um die Session zu autorisieren.

Integration von Passkeys in Microsoft Entra ID und eigene Applikationen

Wenn Ihr Unternehmen Microsoft Entra ID als primären Identity Provider (IdP) nutzt, erfordert die Aktivierung von Passkeys eine Synchronisierung der Entra-ID-Richtlinien mit dem Authentifizierungs-Flow Ihrer eigenen Anwendung. Das Microsoft-Update bedeutet, dass Entra ID Benutzer beim Login aktiv dazu auffordert, Passkeys zu registrieren und zu verwenden. Wenn Ihre eigenen Anwendungen jedoch veraltete Client-Bibliotheken nutzen, können diese Aufforderungen Fehler verursachen oder den Authentifizierungsprozess zum Absturz bringen.

Um die Standard-Passkey-Authentifizierung zu unterstützen, müssen Sie die Microsoft Authentication Library (MSAL) in der Codebase Ihrer Anwendung aktualisieren. Veraltete Versionen von MSAL.js, die den Implicit Grant Flow nutzen, verarbeiten den modernen Authorization Code Flow mit PKCE nicht korrekt. Stellen Sie sicher, dass Ihre Webanwendungen auf MSAL.js 3.x aktualisiert werden, um moderne, passwortlose Sitzungen zu unterstützen. Zudem müssen Sie sicherstellen, dass Ihre Client-Anwendung Browser-Redirects nicht abfängt oder blockiert.

Eine häufige Fehlerquelle liegt in nativen iOS- und Android-Apps, die Web-Interfaces in einem Wrapper ausführen. Viele veraltete Hybrid-Apps, die mit älteren Versionen von Cordova, Ionic, oder React Native entwickelt wurden, nutzen standardmäßige WebViews. Diese eingebetteten Web-Engines machen die native Biometrie des Geräts für die WebAuthn-API nicht zugänglich. Wenn Entra ID versucht, den Benutzer zur Verwendung eines Passkeys aufzufordern, bricht der Authentifizierungs-Flow mit einem allgemeinen Fehler ab.

Um dieses Problem zu lösen, müssen Mobile-Entwickler ihre Authentifizierungs-Flows auf System-Browser umstellen. Unter iOS müssen Sie ASWebAuthenticationSession oder SFAuthenticationSession implementieren. Unter Android sollten Sie Chrome Custom Tabs in Kombination mit der Android Credential Manager API nutzen. Diese nativen Brücken stellen sicher, dass bei einer Passkey-Assertion-Anforderung durch Entra ID der native biometrische Prompt des Betriebssystems korrekt initialisiert wird.

Architekturplanung: Souveränität, Modellierung und Lock-in-Effekte

Bevor die erste Zeile Authentifizierungscode geschrieben wird, müssen Tech-Leads die Architektur sorgfältig planen. Authentifizierungssysteme lassen sich nach dem Deployment in der Produktion bekanntermaßen nur schwer ändern. Das Design sicherer, intuitiver Authentifizierungs-Workflows ist eine gemeinschaftliche Herausforderung. Um Entwickler, Sicherheitsbeauftragte und Business-Stakeholder aufeinander abzustimmen, ist die Nutzung der Vorteile der kollaborativen Software-Modellierung ein entscheidender erster Schritt.

Durch die Modellierung der Zustandsübergänge (State Transitions) von User-Enrollment, Geräteregistrierung und administrativen Recovery-Flows vor der Programmierung können Teams Edge Cases frühzeitig identifizieren. Dies verhindert kostspielige Architektur-Nachbesserungen in einer späten Phase des Entwicklungszyklus. Zudem wirft die tiefe Integration in das proprietäre Ökosystem von Entra ID langfristige Compliance- und Hosting-Fragen auf. Microsofts Initiative für Passkeys erhöht die Sicherheit drastisch, vertieft jedoch auch die Abhängigkeit von in den USA gehosteter Cloud-Infrastruktur.

Für europäische Unternehmen, die strengen Anforderungen an die Datensouveränität unterliegen, ist dieser Vendor Lock-in ein wachsendes Problem. In unserer Analyse über den Ausstieg aus der US-Cloud haben wir die Lehren aus dem Übergang des Schweizer Militärs zu lokal gehosteten Open-Source-Plattformen wie OpenDesk erörtert. Wenn Ihre langfristige IT-Strategie den Übergang zu einer souveränen Infrastruktur vorsieht, sollten Sie die Authentifizierungsschicht Ihrer eigenen Anwendung providerunabhängig konzipieren. Die Implementierung standardkonformer WebAuthn-Protokolle stellt sicher, dass Ihr Code für potenzielle zukünftige Migrationen portabel bleibt.

Technische Herausforderungen bei der Implementierung von Passkeys im Unternehmen

Obwohl eine Entra ID Passkey Integration unübertroffene Sicherheit bietet, bringt die unternehmensweite Einführung einige technische Hürden mit sich. Die erste Hürde ist die Reibung bei der geräteübergreifenden Synchronisierung (Cross-Device Synchronization). Registriert ein Benutzer einen Plattform-Passkey auf seinem geschäftlichen Windows-Laptop über Windows Hello, ist der Private Key an den TPM-Chip dieses spezifischen Laptops gebunden. Versucht er sich später von einem geschäftlichen iPhone aus in Ihrer eigenen mobilen Anwendung anzumelden, hat er keinen Zugriff auf diesen Schlüssel.

Um dies abzufedern, müssen Sie das Benutzerportal Ihrer Anwendung so konfigurieren, dass es mehrere registrierte Credentials pro Benutzerkonto unterstützt. Zudem sollten Sie Benutzer anleiten, sowohl einen plattformgebundenen Authenticator als auch einen geräteübergreifenden Roaming-Authenticator zu registrieren. Beispiele hierfür sind ein hardwarebasierter YubiKey oder ein Cloud-synchronisierter Credential-Manager wie iCloud Keychain. Dies gewährleistet einen nahtlosen Zugriff über verschiedene vom Unternehmen verwaltete Geräte hinweg.

Eine weitere Herausforderung ist das sichere Recovery und Enrollment, ohne auf SMS-Fallbacks zurückzugreifen. Wenn ein Benutzer seinen physischen Schlüssel verliert, wie meldet er sich wieder an? Wenn Ihr System es ihm ermöglicht, seinen Passkey einfach über einen SMS-Code zurückzusetzen, wird die Sicherheit Ihres gesamten Authentifizierungssystems auf das Sicherheitsniveau von SMS herabgestuft. Der Recovery-Flow wird zum schwächsten Glied in der Kette, das Angreifer ausnutzen werden.

Um dieses Problem zu lösen, müssen Sie die Funktion Temporary Access Pass (TAP) von Microsoft Entra ID implementieren. Ein TAP ist ein zeitlich begrenztes Einmalkennwort, das Administratoren für einen Benutzer generieren können. Der Benutzer meldet sich mit dem TAP an, um die Passkey-Anforderung gerade so lange zu umgehen, bis er einen neuen biometrischen Passkey auf seinem neuen Gerät registrieren kann. Dieser Prozess hält den Enrollment-Flow sicher, ohne auf schwache Fallback-Methoden angewiesen zu sein.

Schließlich ist die erzwungene, plötzliche Umstellung auf Passkeys über Nacht für Tausende von Mitarbeitern ein Rezept für betriebliches Chaos. Die Durchsetzung von MFA-Updates ohne ein schrittweises Enrollment-Fenster führt in der Regel zu einem Anstieg der internen IT-Supporttickets um über 300 % innerhalb der ersten 48 Stunden. Moderne Anwendungsschnittstellen müssen eine progressive Onboarding-Strategie unterstützen, um Passkeys schrittweise einzuführen und das Support-Personal auf die TAP-Generierung vorzubereiten.

Implementierung der Entra ID Passkey Integration: Schritt für Schritt

Die Aktivierung von Passkeys in Entra ID und die Konfiguration eigener Apps erfordert eine bestimmte Abfolge administrativer und technischer Schritte. Der erste Schritt ist die Aktivierung von FIDO2-Sicherheitsschlüsseln im Microsoft Entra Admin Center. Navigieren Sie zu „Schutz“ (Protection), dann „Authentifizierungsmethoden“ (Authentication methods) und wählen Sie „Richtlinien“ (Policies). Aktivieren Sie die Methode „FIDO2-Sicherheitsschlüssel“ (FIDO2 Security Key) entweder für alle Benutzer oder eine Pilot-Sicherheitsgruppe.

Stellen Sie unter der Registerkarte „Konfiguration“ (Configuration) die Option „Registrierung durch den Benutzer zulassen“ (Allow self-service registration) auf „Ja“ (yes). Für Hochsicherheitsumgebungen können Sie auch Schlüsselbeschränkungen erzwingen. Dies ermöglicht es Ihnen, Registrierungen auf bestimmte Hardwarehersteller zu beschränken, indem Sie deren Authenticator Attestation GUIDs (AAGUIDs) hinterlegen. So können Sie beispielsweise festlegen, dass nur vom Unternehmen ausgegebene YubiKeys zugelassen sind.

Konfigurieren Sie als Nächstes die Richtlinie für den Temporary Access Pass (TAP), um ein sicheres Onboarding zu ermöglichen. Aktivieren Sie die Richtlinie im Menü „Authentifizierungsmethoden“ (Authentication methods) und konfigurieren Sie die Mindest- und Maximallaufzeit. Stellen Sie die Einmalnutzung (one-time use) auf „Ja“ (yes), um sicherzustellen, dass TAPs sofort nach ihrer ersten Verwendung ablaufen. Dies verhindert die Wiederverwendung von Anmeldedaten während des Einrichtungsprozesses.

Modernisieren Sie schließlich Ihren clientseitigen Code und konfigurieren Sie das progressive Onboarding. Aktualisieren Sie Ihre Frontends auf die neueste MSAL.js-Version und ersetzen Sie eingebettete WebViews in mobilen Apps durch Custom Tabs. Erkennen Sie die WebAuthn-Unterstützung programmatisch mittels JavaScript und fordern Sie den Benutzer während seiner aktiven Sitzung über ein Banner auf, seine Biometrie zu registrieren.

Best Practices für den Einsatz von Passkeys im Unternehmen

Um sicherzustellen, dass Ihre Passkey-Implementierung sicher, compliant und benutzerfreundlich ist, sollten Sie diese praxiserprobten Entwicklungsmethoden anwenden. Diese Tipps helfen Entwicklern, typische Integrationsfehler zu vermeiden und gleichzeitig maximale Sicherheitsgarantien zu gewährleisten.

Keine unsicheren Fallbacks zulassen: Ermöglichen Sie es Benutzern nicht, ihre Sitzung auf SMS/Sprachanruf herunterzustufen, wenn die Authentifizierung mit einem Passkey fehlschlägt. Andernfalls wird das gesamte Sicherheitskonzept hinfällig, da Hacker gezielt diese Schwachstelle angreifen werden. Erzwingen Sie stattdessen einen strikten Recovery-Flow unter Verwendung von Temporary Access Passes (TAP), die von IT-Administratoren nach erfolgreicher Identitätsprüfung ausgestellt werden.
Hybride Geräteregistrierung implementieren: Ermutigen Sie Benutzer, mindestens zwei Authenticatoren zu registrieren. Dies sollte einen plattformgebundenen Authenticator (Windows Hello oder TouchID) für den täglichen Gebrauch und einen Roaming-Key (wie einen USB-C/NFC-YubiKey) oder einen synchronisierten Passkey umfassen. Dieses Setup bietet einen geräteübergreifenden Fallback-Schutz und verhindert, dass sich Benutzer aussperren.
AAGUID-Filterung für Hochsicherheitsumgebungen nutzen: Wenn Sie in regulierten Branchen wie dem Finanz- oder Gesundheitswesen tätig sind, nutzen Sie die Authenticator Attestation GUID (AAGUID) Filterung in Entra ID. Dies beschränkt die Registrierung von Hardwareschlüsseln auf solche mit bestimmten Sicherheitszertifizierungen (z. B. FIPS 140-2 Level 3). So wird sichergestellt, dass nur vom Unternehmen freigegebene Authenticatoren auf den Tenant zugreifen können.
Electron- und Hybrid-App-Container aktualisieren: Wenn Ihre eigenen Desktop- oder mobilen Apps in Web-Wrappern laufen, stellen Sie sicher, dass Electron auf Version 20+ aktualisiert wird und Cordova/Capacitor-Apps native Plugins nutzen. Dies schlägt die Brücke von der WebAuthn-API zum Credential-Manager des Betriebssystems. Ohne diese Anpassung können native biometrische Prompts nicht gestartet werden.

Wann sich ein Partner lohnt: Eigenbau vs. Outsourcing Ihrer Authentifizierungs-Architektur

Der Aufbau eines eigenen Authentifizierungssystems, das veraltete Unternehmensdatenbanken mit modernen passwortlosen Standards verbindet, ist ein komplexes und risikoreiches Unterfangen. Eine einzige Schwachstelle in der Logik zur Token-Verifizierung kann zu schwerwiegenden Sicherheitsverletzungen führen. Dies in-house umzusetzen bedeutet, Fachkräfte für Kompetenzen einzustellen, die Sie nur einmalig benötigen, und das Ergebnis über Jahre hinweg warten zu müssen. Ein erfahrener Partner wie ProjectMakers liefert diese Integration als sicheres Festpreisprojekt.

Wir übernehmen die gesamte Transition – vom Audit Ihrer bestehenden Codebase über das Upgrade von MSAL-Integrationen bis hin zur Einrichtung sicherer Fallback-Workflows. Dadurch kann sich Ihr internes Team voll und ganz auf Ihr Kernprodukt konzentrieren. Ganz gleich, ob Sie ein komplexes React-Web-Dashboard oder ein plattformübergreifendes Unity Serious Game absichern möchten: ProjectMakers bietet die fundierte technische Expertise, die für die Implementierung von WebAuthn- und Entra-ID-Protokollen erforderlich ist, ohne die Workflows der Benutzer zu beeinträchtigen.

Nächste Schritte: Auf dem Weg zur passwortlosen Compliance

Die Einstellung von SMS- und Sprach-MFA in Microsoft Entra ID ist ein klares Signal dafür, dass veraltete Authentifizierungsmethoden nicht mehr tragbar sind. Beginnen Sie mit einem Audit Ihrer aktuellen Benutzerbasis, um festzustellen, welche Geräte WebAuthn nicht unterstützen, und konfigurieren Sie eine progressive Enrollment-Richtlinie. Planen Sie ein Software- oder KI-Projekt? Kontaktieren Sie ProjectMakers für ein kostenfreies Erstgespräch, um Ihre Migrationsstrategie zu planen.

Quelle: Microsoft macht Passkeys zum Standard in Entra ID