1.3.1. Authentication: Proving Who You Are
💡 First Principle: Proof of identity rests on factors — something you know (password, PIN), something you have (phone, security key, certificate), something you are (fingerprint, face). One factor can be stolen or guessed; two independent factors multiply the attacker's work, which is why MFA defeats the overwhelming majority of account-compromise attacks.
In the Microsoft cloud, Entra ID is the identity provider (IdP): the authority that challenges for credentials, evaluates them, and issues proof. Centralizing this matters — one place to enforce MFA, one place to watch for anomalies, one sign-in that unlocks many apps (single sign-on), and one switch to disable when someone leaves.
Not all factors are equal, and the exam expects you to rank them. Passwords alone are the weakest. SMS and voice add a second factor but are phishable and vulnerable to SIM-swapping. Authenticator push notifications resist SIM-swap but can fall to prompt-fatigue attacks — mitigated by number matching. At the top sit the phishing-resistant methods — FIDO2 passkeys, Windows Hello for Business, certificate-based authentication — where the credential is cryptographically bound to the legitimate site, so a fake login page gains nothing. Phase 2 covers deploying each of these; here, lock in the ladder itself.
Authentication strength can also be conditional: a routine sign-in from a compliant device might need less proof than the same user activating an admin role. That idea — matching proof to risk — is the seed of Conditional Access authentication strengths and PIM activation requirements later.
⚠️ Exam Trap: "Enable MFA" is not one setting; which methods satisfy it matters. When a scenario demands protection against phishing specifically, only passkeys/FIDO2, Windows Hello for Business, or certificate-based authentication qualify — Authenticator push, SMS, and voice do not.
Reflection Question: Why does a FIDO2 passkey still protect a user who is actively tricked into visiting a pixel-perfect fake sign-in page, when an Authenticator push approval might not?
