Entra External ID – Is there a supported, least-privileged API for customer self-service Passkey management?

Armin Selimovic 0 Reputation points
2026-10-12T14:26:59+00:00

Hi everyone,

I'm currently implementing a centralized Passkey Self-Service experience for Microsoft Entra External ID customer accounts.

Microsoft's official Passkey sample worked in our PoC using the Graph FIDO2 APIs with highly privileged application permissions (UserAuthenticationMethod.ReadWrite.All / UserAuthMethod-Passkey.ReadWrite.All). However, this is not suitable for our intended production architecture.

I've also tested the previously documented Credential Management API using delegated permissions:

Me.UserAuthenticationMethod.Passkey.Read

Me.UserAuthenticationMethod.Passkey.ReadWrite

Resource: Me-CredentialProfileManagement

Despite successful authentication in some configurations, I encountered AADSTS500026, AADSTS10040143, empty method lists, error_passkey_mismatch_policy_failure, and most recently 405 Method Not Allowed.

I also noticed that Microsoft's Credential Management API documentation was removed on October 6, 2026, and the current Passkey documentation now states that low-privilege APIs are not available.

Has anyone successfully implemented Passkey registration, listing, and deletion for External ID local customer accounts in a production-ready architecture, without tenant-wide application permissions?

I'm particularly interested in an officially supported API or a working implementation that can be reproduced.

Thanks in advance!

Microsoft Security | Microsoft Graph
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-12T14:27:13.92+00:00

    No. There is currently no officially supported low-privilege API for customer self-service passkey management in Microsoft Entra External ID.

    Supported facts from current documentation:

    1. Low-privilege APIs are not available for building a credential management experience.
    2. For External ID customer passkey management, the documented approach is to build the experience by using the FIDO2 provisioning APIs.
    3. The available Microsoft sample demonstrates administrator-controlled provisioning with high-privilege application permissions and is intended for testing only, not as a model for customer self-service.
    4. The External ID passkey sample guidance also warns that the sample uses high-privilege application permissions and that its deletion flow uses a client secret in browser code, so it should be run only in a test tenant, not in production.
    5. Passkey registration requires the customer’s physical presence and a local biometric or PIN gesture. Admins can delete passkeys and prompt re-registration.

    For a production-ready architecture, the supported position in the current documentation is:

    • Registration/listing/deletion self-service UX must be built in the application.
    • No supported least-privileged customer self-service API is documented today.
    • The documented API path is the FIDO2 provisioning APIs, but the provided sample is explicitly not the production model for customer self-service.

    So the direct answer to the question is:

    • No supported, reproducible, least-privileged API for External ID customer self-service passkey registration, listing, and deletion is documented today.
    • No production-ready Microsoft sample is documented for that scenario without high-privilege application permissions.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.