Today we’re announcing the general availability of Email and SMS one‑time passcode (OTP) as second‑factor MFA for Native Authentication in Microsoft Entra External ID. This enables developers to add step‑up security to native sign‑in and sign‑up flows while keeping users fully inside their applications.
This release focuses exclusively on MFA as a second factor, evaluated after first‑factor authentication completes, and is enforced through Microsoft Entra Conditional Access.
Clarifying first factor vs. second factor
Native Authentication in Entra External ID supports distinct authentication stages, allowing developers to layer security only when needed.
Second‑factor MFA is commonly required:
| Authentication stage | What’s supported |
|---|---|
| First factor | Email OTP; Email + password (with SSPR) |
| Second factor (GA) | Email OTP; SMS OTP |
Second‑factor MFA is evaluated only after first‑factor authentication succeeds, enabling step‑up security without adding friction to every sign‑in.
Why second‑factor MFA matters for native apps
Consumer and external‑facing applications increasingly require stronger assurance without sacrificing user experience.
- When higher assurance is needed — such as high‑risk sign‑ins, sensitive user actions, or regulated scenarios.
- Without breaking native UX — keeping users fully inside the app while security policies are enforced server‑side.
By supporting Email and SMS OTP as a second factor, Native Authentication enables developers to strengthen account security while maintaining fully branded, native authentication experiences.
What’s now generally available
With this GA release, developers can now:
- Enforce MFA after first‑factor authentication in native sign‑in and sign‑up flows.
- Use Email OTP or SMS OTP as the second authentication factor.
- Rely on Conditional Access to control when MFA is required.
- Receive ID and access tokens only after MFA succeeds, with no client‑side enforcement logic.
Native Authentication continues to issue tokens only after all required authentication factors have been successfully completed.
Ready to get started?
To begin using second‑factor MFA with Native Authentication, configure Conditional Access policies in your Entra External ID tenant and integrate using Native Authentication SDKs or APIs.
Stay connected and informed
To learn more or test out features in the Microsoft Entra suite of products, visit our developer center. Make sure you subscribe to the Identity blog for more insights and to keep up with the latest on all things Identity. And, follow us on YouTube for video overviews, tutorials, and deep dives.
Subject: Mitigation of Identity Recovery Logic Flaws via Biometric-Anchored Emergency Protocols (Global Identity Sovereignty)
Related Vulnerability References: VULN-056593, VULN-056738, VULN-169872, 105534
CRM Reference: 0022118606
Reporter Information:
- Name: Lekbir El Marouani
- Phone: +212699838619
- Email: lekbirlmarouani5@gmail.com
- The Flaw: The system assumes the possessor of the recovery tool is the legitimate owner.
- The Risk: An attacker can exploit the recovery workflow to hijack accounts, effectively using the user's own security protocols against them. This creates a state of "Identity Instability" during physical device loss.
A. The Emergency Trigger (UI/UX Integration)
Implementation of an explicit "Device Compromised/Lost" trigger adjacent to standard recovery options....