Multi-Factor Authentication (Azure)
An Entra ID security feature requiring users to verify their identity through a second factor (authenticator app, SMS, or hardware key) in addition to a password before gaining access, typically enforced through Conditional Access.
Multi-Factor Authentication (Azure)
MFA adds a second proof of identity beyond a password — even a stolen or guessed password alone can't complete sign-in without it.
Why It Matters in Production
After a phishing attempt targeted Zerodha employees with fake login pages, MFA enforcement via Conditional Access meant the stolen passwords alone were useless to the attackers — every account remained protected.
az rest --method GET --uri "https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails"Common MistakeEnabling MFA only for admin roles — attackers commonly target regular user accounts first as a foothold before privilege escalation.
Frequently Asked Questions
How does Entra ID MFA differ from just requiring a strong password policy?
Password policies address credential strength, but MFA addresses credential theft — even a leaked or phished password is useless to an attacker without the second factor. Entra ID supports several methods (Microsoft Authenticator push/OTP, SMS, phone call, FIDO2 hardware keys), and Microsoft's own telemetry has repeatedly shown MFA blocks the overwhelming majority of account compromise attempts that rely on a stolen password alone.
What's a common MFA rollout mistake that causes lockouts or gaps in coverage?
Enabling MFA per-user through legacy 'per-user MFA' settings instead of Conditional Access policies is a common mistake — it's harder to manage at scale and doesn't account for context like trusted networks or device compliance. Another frequent gap: forgetting that legacy authentication protocols (POP, IMAP, older Office clients) can bypass MFA entirely unless explicitly blocked, so MFA enforcement should always be paired with a legacy-auth-blocking policy.