MFA not triggering for users created via Graph API in Entra External ID but works for portal-created users

Question

MFA not triggering for users created via Graph API in Entra External ID but works for portal-created users

Nikhil Putta 0

Issue: When a user is created directly in the Entra admin portal and logs in through our application, MFA is triggered. When a user is created via Graph API and logs in through the same application, MFA is not triggered.

We compared both users via Graph API, and they are identical:
Things we have already checked:

No user flows exist in the tenant; a third-party identity provider acts as the authentication layer and enforces MFA during login
Compared both users via Graph API: all attributes are identical
No Conditional Access policies targeting external users
MFA is not configured via Entra user flow: it is enforced by the third-party identity provider during sign-in

Question: Is there any attribute automatically set by the Entra admin portal during user creation that is not set via Graph API that could affect MFA behavior in Entra External ID? Is there a hidden attribute, tenant-level default, or internal property that the portal sets which the Graph API does not expose?

Any suggestions or guidance are highly appreciated. We want to understand what the portal sets differently at a deeper level than what the Graph API exposes, so we can replicate it in our API provisioning payload and ensure consistent MFA behavior for all users, regardless of how they are created.

Carolyne-3676 1,136 Reputation points

2026-07-03T10:49:58.6366667+00:00

Hello Nikhil!
Try the following:
Check createdByPolicy and authentication methods registration: Portal-created users in External ID may automatically have a strongAuthenticationRequirement or per-user MFA state set that Graph API doesn't replicate by default. Compare both users via GET /users/{id}/authentication/methods and GET /users/{id}/authentication/requirements — also check if the portal sets passwordPolicies or userType differently (e.g., "Member" vs "Guest"), as your third-party IdP may only enforce MFA based on a specific user type or attribute it receives in the token.

Inspect the SAML/OIDC claims sent to your third-party IdP: The likely root cause is that the IdP decides whether to trigger MFA based on a claim (like acrs, amr, or a custom attribute) that differs between portal-created and API-created users. Use Entra sign-in logs to compare the token claims for both users at the point of federation — once you identify the differing claim, include that attribute in your Graph API user creation payload.

Your answer

Carolyne-3676 1,136 Reputation points

2026-07-03T10:49:58.6366667+00:00

Hello Nikhil!
Try the following:
Check createdByPolicy and authentication methods registration: Portal-created users in External ID may automatically have a strongAuthenticationRequirement or per-user MFA state set that Graph API doesn't replicate by default. Compare both users via GET /users/{id}/authentication/methods and GET /users/{id}/authentication/requirements — also check if the portal sets passwordPolicies or userType differently (e.g., "Member" vs "Guest"), as your third-party IdP may only enforce MFA based on a specific user type or attribute it receives in the token.

Inspect the SAML/OIDC claims sent to your third-party IdP: The likely root cause is that the IdP decides whether to trigger MFA based on a claim (like acrs, amr, or a custom attribute) that differs between portal-created and API-created users. Use Entra sign-in logs to compare the token claims for both users at the point of federation — once you identify the differing claim, include that attribute in your Graph API user creation payload.