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: Official Technical Refutation: Case 105534 / VULN-169872
To: Microsoft Identity Engineering & Executive Leadership
Regarding your latest update (March 9th) promoting Email/SMS OTP as a security standard, I am issuing a formal objection based on Case 105534.
Your system is currently suffering from "Strategic Digital Blindness." You are promoting a feature that acts as a critical vulnerability in the most dangerous scenario: A Stolen or Lost Device.
The Logical Failure:
When a device is snatched while active, your current algorithms treat the thief as the legitimate owner. By sending OTPs and recovery links to the same stolen device, you are not securing the...
Subject: Urgent Strategic Security Proposal: Global Session Kill-Switch (Case VULN-169872 / 105534)
To the Microsoft Engineering & Security Team,
I am reaching out through this developer platform because standard support channels have failed to address a critical architectural blind spot in global data sovereignty.
Current session management protocols suffer from "Digital Blindness"—they cannot distinguish between a legitimate owner and a physical thief who snatches an active, unlocked device.
The Solution: The Global Session Kill-Switch ("The Light System")
I am proposing a strategic update to the Microsoft ecosystem that includes:
1. Immediate Session Termination: A dedicated "Device Stolen/Lost" trigger in the recovery model that kills...
إلى السيد ساشا مارس.مدير منتج أول
بروتوكول “نظام النور”: إنهاء السيادة الزائفة للسارق (القضية 105534)
1. تشخيص الفشل (العمى الرقمي):
إن خوارزميات مايكروسوفت وجوجل الحالية مصممة للتعامل مع “نسيان كلمة السر”، لكنها عاجزة تماماً أمام “سرقة الجهاز النشط”.
الفجوة: عندما يطلب السارق استرداد الحساب أو تغيير الإعدادات، يرسل النظام رمز (OTP) أو رابط استرداد إلى نفس الجهاز المسروق.
النتيجة: النظام يقوم حرفياً بمساعدة السارق على اختراق خصوصية المالك، وكأن الحارس يسلم مفاتيح الخزنة للشخص الخطأ لمجرد أنه يقف أمام الباب.
2. الحل الجذري: خانة “هل جهازك مسروق أو مفقود؟”
يجب دمج خيار سيادي في صفحة الاسترداد وتسجيل الدخول يسمى “الجهاز مسروق” بجانب خيار “نسيت كلمة المرور”. تفعيل هذا الخيار يقوم بالآتي فوراً:
إبطال فوري وشامل (Global Kill-Switch): إنهاء جميع الجلسات المفتوحة على كافة الأجهزة والمتصفحات في ثانية واحدة، مما يجرد السارق من الوصول الحالي.
حظر قنوات الاختراق: منع إرسال أي رسائل SMS أو رسائل بريد إلكتروني إلى الأرقام والحسابات المفتوحة على الجهاز المفقود.
التحقق المادي الصارم: تحويل عملية إثبات الهوية إلى “خارج الجهاز المسروق” عن طريق:
بصمة الإصبع أو الوجه عبر جهاز موثوق آخر.
المسح الضوئي لبطاقة الهوية الوطنية (OCR).
النقش المسبق أو البصمة المسجلة في خوادم الشركة الأم.
3. الهدف الاستراتيجي:
الهدف من القضية 105534 و VULN-169872 هو حماية “السيادة الرقمية”. لا يمكن اعتبار أي نظام “آمناً” إذا كان لا يستطيع التمييز بين المالك والسارق. إن تطبيق هذا النظام سيجعل مايكروسوفت الحارس الأول للبيانات الحكومية والحساسة (مثل بيانات البيت الأبيض) والمواطنين حول العالم.