10.3 MFA, SSPR, and Conditional Access
Key Takeaways
- Multifactor authentication (MFA) requires two or more of something you know, something you have, and something you are so a stolen password is not enough
- Self-service password reset (SSPR) lets users change or reset a forgotten password, or unlock an account, without a help-desk ticket
- Combined registration lets a user register security information once and use it for both MFA and SSPR
- Conditional Access is Microsoft’s if-then policy engine: signals such as user, location, device, application, and risk decide whether to block, allow, require MFA, or require a compliant or hybrid-joined device
- Security defaults are a simple on-or-off baseline for tenants that do not use customized Conditional Access; do not treat unpublished or tenant-specific policies as if they were always on for every Microsoft 365 customer
Quick Answer: Multifactor authentication (MFA) asks for two or more of something you know, something you have, and something you are. Self-service password reset (SSPR) lets users reset or unlock without the help desk. Combined registration records security info once for both. Conditional Access is an if-then engine: if this user, location, device, app, or risk, then block, allow, require MFA, or require a compliant / hybrid-joined device.
The April 30, 2025 MS-900 outline asks you to describe how Microsoft uses methods such as multi-factor authentication (MFA), self-service password reset (SSPR), and conditional access to keep identities, access, and data secure. This is still a fundamentals skill. You will not author a grant-control JSON. You will match the tool to the pain: stolen passwords, forgotten passwords, and “only open Exchange from a healthy laptop.”
Multifactor authentication
Multifactor authentication prompts the user for an additional form of identification during sign-in — a code on a phone, a fingerprint, a security key. Official Learn: a password alone is an insecure vector. If it is weak or reused, an attacker can use it. A second factor is something that is not easy to obtain or duplicate.
Microsoft Entra MFA requires two or more of:
- Something you know — typically a password or PIN.
- Something you have — a trusted device that is not easily copied: a phone, hardware key, or the Microsoft Authenticator app.
- Something you are — biometrics such as a fingerprint or face scan.
Two passwords are not MFA. A password plus the same password typed again is not MFA. A password plus Authenticator, a password plus a FIDO2 key, or Windows Hello (device plus biometric or PIN that unlocks a key on that device) can satisfy the definition.
Verification methods you should recognize by name include Microsoft Authenticator (push / number match / passwordless), Windows Hello for Business, passkeys (FIDO2), OATH hardware or software tokens, SMS, and voice call. SMS and voice still count as “something you have,” but they are easier to attack than Authenticator number match or a hardware key. MS-900 will not ask you to rank every method’s phishing resistance. It will ask whether “password plus a second proof” is the control that stops a leaked password by itself.
You do not rewrite Outlook or Teams to use MFA. The challenge is part of the Microsoft Entra sign-in. When policy says MFA is required, Entra prompts and processes it.
How MFA gets turned on is a separate sentence. Security defaults can require Authenticator-based MFA as a simple tenant-wide baseline. Conditional Access can require MFA only for admins, only outside the office, only for Azure management, or only when risk is high. Legacy per-user MFA toggles still exist in older tenants; they are not the modern targeting model. If the stem wants granular “if remote, then MFA,” the product is Conditional Access, not a blanket slogan.
Self-service password reset
Self-service password reset (SSPR) lets users change or reset their password with no administrator or help-desk involvement. If the account is locked or the password is forgotten, the user follows prompts, proves registered methods, and gets back to work. Official outcome: fewer help-desk calls and less lost productivity. End users go to https://aka.ms/sspr (passwordreset.microsoftonline.com) or Can’t access your account on the sign-in page.
SSPR is not MFA, even though it reuses similar methods. MFA proves you at sign-in. SSPR proves you so you can replace a secret you no longer have. A user who never registered methods cannot complete SSPR and is told to contact an administrator. Admins configure whether one or two methods are required to reset, which methods count (Authenticator, phone, email OTP, security questions, and others), whether users must register when they sign in, and whether they must reconfirm methods after a number of days.
In a hybrid tenant, SSPR only updates the on-premises password if password writeback is enabled. If writeback is off and the password is mastered in AD DS, the portal tells the user to call the help desk. SSPR can also unlock an on-premises account, optionally without forcing a password change. Administrator accounts follow a stronger reset policy than standard users; do not assume a Global Administrator can SMS-reset the same way a salesperson can.
Guest / B2B users typically reset against their home tenant’s SSPR policy, or against the email they used to join. Personal Microsoft accounts (outlook.com / hotmail.com) invited as guests do not use Entra SSPR.
Combined registration
Before combined registration, people registered MFA methods and SSPR methods separately and were confused that the same phone had to be entered twice. Official Learn: with combined registration, users register once and get the benefits of both MFA and SSPR. Combined registration has been rolled out to customers; the old “switch to combined registration” tenant toggle is removed after a tenant migrates.
Users manage methods at Security info (https://aka.ms/mysecurityinfo) under My Account. Two modes matter conceptually:
- Interrupt mode — a wizard at sign-in when an admin enforces registration (MFA policy, SSPR registration required, ID Protection MFA registration, or a Conditional Access “register security info” action).
- Manage mode — the user opens Security info later to add, delete, or change the default method.
If both MFA and SSPR are in play, the wizard collects enough methods to satisfy both policies, usually starting with a stronger MFA-capable method. Combined registration is not a third security product. It is the one registration experience that feeds the other two.
Conditional Access: if this, then that
Microsoft Entra Conditional Access is Microsoft’s Zero Trust policy engine. It brings signals together, makes a decision, and enforces organizational policy. Official one-liner: policies are if-then statements. If a user wants to access a resource, then they must complete an action. Example: if a user wants Microsoft 365, then they must perform MFA.
Two admin goals sit on every page of the docs: let people work from anywhere and protect the organization’s assets. Conditional Access is how you apply the right control when it is needed instead of treating every sign-in the same.
Important boundary: Conditional Access is evaluated after first-factor authentication succeeds. It is not a denial-of-service shield in front of the password box. The user has already proved a password, certificate, or passwordless credential. Conditional Access then decides whether that session may continue.
Signals you should be able to name:
- User, group, or directory role — target Finance, guests, or Global Administrators.
- IP location — named trusted networks, or countries/regions you block or allow.
- Device — platform, compliant (Intune) state, or Microsoft Entra hybrid joined.
- Application — Exchange Online versus a loosely governed SaaS app versus Azure management.
- Real-time and calculated risk — user risk and sign-in risk from ID Protection.
- Microsoft Defender for Cloud Apps — session controls for cloud-app activity.
Decisions you should be able to name:
- Block access — the most restrictive outcome.
- Grant access, optionally with one or more controls: require MFA, require authentication strength, require the device to be marked compliant, require a Microsoft Entra hybrid joined device, require an approved client app, require an app protection policy, require a password change, require terms of use.
Common patterns organizations implement (these are documented examples, not a promise that every tenant has them switched on):
- Require MFA for administrative roles.
- Require MFA for Azure management (portal, CLI, PowerShell).
- Block legacy authentication (IMAP, POP, old Office clients) because those protocols cannot do MFA.
- Require a trusted location before someone registers security info.
- Block or allow specific countries.
- Require a compliant or hybrid-joined device for SharePoint or Exchange.
Licensing, conceptually: using Conditional Access requires Microsoft Entra ID P1 (included in Microsoft 365 E3-class and Microsoft 365 Business Premium). Risk-based policies need ID Protection / P2 (E5-class). You do not memorize a price list. If licenses lapse, existing policies are not silently deleted; they become non-editable so the posture does not vanish overnight.
Security defaults versus Conditional Access
Security defaults are preconfigured baseline protections Microsoft makes available at no extra Entra cost: require MFA registration, require MFA for administrators and when Microsoft deems it necessary, block legacy authentication, block device-code flow, and protect privileged portals such as the Azure and Entra admin centers. They are aimed at organizations that need a starting posture, including many free-tier tenants. Microsoft documents that new tenants can have security defaults enabled at creation, with a short grace period before enforcement, and that Microsoft may notify older tenants that lack Conditional Access and premium licenses before turning defaults on.
That is not the same sentence as “every Microsoft 365 tenant on earth always has these Conditional Access policies enabled.” Do not invent unpublished always-on CA policies. Security defaults are on or off and not customizable. Organizations that need exceptions (“skip MFA on the corporate network, require a compliant device for Exchange, exclude the break-glass account”) disable security defaults and write Conditional Access instead. You cannot run customized Conditional Access and security defaults together as two competing engines.
Side-by-side
| Control | Job | Typical exam signal |
|---|---|---|
| MFA | Second factor so a stolen password is not enough | “Password plus phone / biometric / key” |
| SSPR | User resets or unlocks without help desk | “Forgot password; reduce tickets” |
| Combined registration | One Security info enrollment for MFA and SSPR | “Register once, use for both” |
| Conditional Access | If-then access using signals | “If outside the office / high risk / this app, then MFA or block or compliant device” |
| Security defaults | Simple all-tenant baseline, not custom | “We have no CA policies and need a basic MFA bar” |
Realistic exam-style scenarios
Leaked password, second proof. Attackers have employee passwords from another site. Require MFA. A second password field is not MFA.
Monday-morning lockouts. Help desk spends the first hour on “I forgot my password.” Enable SSPR and make people complete combined registration so the same Authenticator they use for MFA can also reset the password. If accounts are hybrid, turn on writeback or SSPR cannot change AD DS.
Finance only from healthy PCs. If the user is in Finance and the cloud app is SharePoint, then require an Intune-compliant or hybrid-joined device. That is Conditional Access, not SSPR.
Admins from hotels. If the user holds an admin role or the location is not the corporate IP range, then require MFA. Same engine, different signals.
Legacy mail clients. POP and IMAP cannot prompt for Authenticator. Block legacy authentication with Conditional Access (or accept that security defaults already do this when they are on).
Small tenant, no policy authors. A ten-person charity on Entra ID Free wants a basic MFA bar and no IMAP holes. Security defaults, not a story that they already have unpublished custom CA.
Exam traps
- MFA is not two passwords. Factors are know / have / are.
- SSPR is not MFA. One proves sign-in. The other replaces a forgotten password.
- Combined registration is not a fourth product. It is one enrollment for MFA and SSPR.
- Conditional Access is not first-factor authentication. It runs after the password or passwordless proof.
- Conditional Access is not security defaults. Defaults are a fixed baseline. CA is the customizable if-then engine (P1).
- Do not invent always-on unpublished default policies. Quote only documented security-defaults behavior or policies an admin created.
- Compliant device is an Intune signal. Hybrid joined is an AD-plus-Entra device signal. Neither is SSPR.
- Writeback is required before SSPR changes a hybrid, on-premises-mastered password.
Official sources
- Microsoft Entra multifactor authentication overview — know / have / are; MFA prompts at Entra sign-in
- Self-service password reset deep dive — reset without help desk; methods; writeback for hybrid
- Combined registration for SSPR and MFA — register once for both features
- Microsoft Entra Conditional Access overview — if-then engine, signals, grant/block controls, P1/P2 split
- Security defaults — preconfigured baseline; not a customizable CA replacement
- Study guide for Exam MS-900 — MFA, SSPR, and Conditional Access
Which description matches Microsoft Entra multifactor authentication?
Employees frequently lock themselves out after a long weekend and flood the help desk. Which Microsoft Entra capability is designed so those users can prove registered methods and reset or unlock without an administrator?
Why does Microsoft recommend combined registration for multifactor authentication and self-service password reset?
A company wants this rule: if a Finance user opens SharePoint from outside the corporate network, then require multifactor authentication and an Intune-compliant device; if the same user is on the office network with a compliant PC, allow access. Which Entra capability is the if-then policy engine for that rule?