6.2 MFA, SSPR & Password Protection

MFA at tenant scale: three models you must separate

SC-300 scenarios constantly mix three multifactor authentication approaches. If you cannot tell them apart, you will pick a technically “possible” answer that is wrong for a modern enterprise design.

Licensing reminder (exam-level): Security defaults are available without Entra ID P1. Conditional Access generally requires Microsoft Entra ID P1 (or suites that include it). Identity Protection risk-based policies typically need P2. SC-300 often assumes the license needed for the described feature; when a stem emphasizes “no P1 licenses,” Security defaults may be the intended MFA baseline.

Security defaults versus Conditional Access MFA

Security defaults turn on a Microsoft-managed baseline:

• Require all users to register for MFA.
• Require MFA for administrative roles and for users as Microsoft defines in the defaults experience.
• Block legacy authentication protocols that cannot support modern auth.
• Protect privileged actions such as Azure portal access in the defaults model.

They are intentionally not granular. You cannot easily say “require MFA for Exchange Online but not for a specific LOB app,” or “exclude the break-glass group with a named exception policy,” the way you can with Conditional Access.

Conditional Access is the enterprise control plane:

1. Assignments — users/groups included and excluded; target cloud apps or actions; directory roles in modern CA.
2. Conditions — sign-in risk, device platforms, locations, client apps, etc. (deeper in the CA chapter).
3. Grant controls — require MFA, require authentication strength, require compliant device, require password change, and combinations.
4. Session controls — sign-in frequency, persistent browser, app-enforced restrictions, and more.

Hard exam rule: You generally cannot run Security defaults and Conditional Access at the same time as your active strategy. Enabling Conditional Access policies for the tenant means you disable Security defaults and take responsibility for equivalent (or better) protections: MFA for admins and users, legacy auth blocking, and break-glass exclusions designed deliberately.

Also separate MFA registration from MFA enforcement. Methods policy + combined registration + campaigns get methods onto accounts; Security defaults or Conditional Access challenge users when policy requires a second factor.

Tenant-wide multifactor authentication settings (practical admin view)

Beyond the big three models, identity admins touch related MFA configuration surfaces:

• Authentication methods policy — which factors exist (section 6.1).
• Conditional Access — when factors are required.
• MFA registration campaign / Identity Protection — nudges and risk-based requirements (deeper in Identity Protection sections).
• Service settings leftovers — trusted IPs and app passwords appear in older MFA service settings; modern designs minimize app passwords and prefer blocking legacy auth instead of carving permanent holes.

Trusted IPs that skip MFA are a classic exam trap: convenient for egress NAT ranges, dangerous if too broad, and often replaced by named locations + Conditional Access with clearer include/exclude logic.

For admin accounts, never rely on “MFA only from the office.” Prefer phishing-resistant methods, PIM just-in-time activation, and tightly scoped CA. For break-glass accounts, follow your emergency design (often long complex passwords or FIDO2, excluded from CA carefully, monitored continuously)—not SMS to a shared phone.

Self-service password reset (SSPR)

SSPR lets users reset or unlock passwords without a helpdesk ticket. On SC-300 you must deploy it correctly for cloud-only and hybrid users.

Enablement and who can reset

In Microsoft Entra admin center: Protection > Password reset (paths evolve; look for Self-service password reset).

Typical configuration choices:

Selected is common for pilots (IT group first), then All for production workforce. Guests have different password/reset realities depending on whether they authenticate locally in your tenant or via their home IdP—do not assume member SSPR settings fix every B2B guest password issue.

SSPR methods and policy alignment

Choose methods that match your security bar:

• Prefer Authenticator notifications/codes over SMS when possible.
• Security questions are weaker and often discouraged for high-security tenants.
• Requiring two methods to reset raises assurance but increases registration friction.
• Align SSPR methods with the authentication methods policy and combined registration so users are not trapped by enabled-reset methods they were never allowed to register.

Password writeback for hybrid identity

If users are authoritative in on-premises Active Directory and authenticate with password hash sync or pass-through authentication, a cloud password reset must write back to AD or the on-premises password remains the real secret and cloud/on-prem will diverge.

Password writeback (Microsoft Entra Connect / Cloud Sync capability with proper licensing—typically Entra ID P1) is required for hybrid SSPR scenarios where the password changes in the cloud and must update AD DS.

Exam stem: “Users reset passwords in the cloud but still cannot sign in to on-premises PCs.” Check writeback, Connect health, and whether accounts are in scope for sync and writeback—not only the SSPR methods blade.

SSPR deployment checklist (SC-300 style)

1. Confirm licenses (P1 features as required for writeback / CA coexistence designs).
2. Enable SSPR for a pilot group.
3. Select methods and number required to reset.
4. Enable registration and communicate the mysecurityinfo experience.
5. For hybrid: enable password writeback, validate with a pilot hybrid account, confirm on-premises password updated.
6. Expand to all users; monitor reset success/failure in audit/sign-in reports.
7. Integrate with helpdesk process for users who fail proofing (TAP + re-register).

Microsoft Entra Password Protection

Microsoft Entra Password Protection detects and blocks weak passwords and organization-specific banned terms. It works in the cloud for Entra ID password changes and can extend to on-premises AD DS password change/set operations.

Cloud banned password lists

Microsoft maintains a global banned password list of known weak/common passwords. Organizations add a custom banned password list (terms such as company name, local sports teams, product names, location slang) so variants of Contoso2026! are rejected.

Admins configure Password Protection in the Entra admin center under Protection > Authentication methods / Password protection surfaces (UI labels evolve). Custom lists should stay focused—excessively huge lists are hard to manage; target high-value org terms.

On-premises agent concept

Hybrid organizations still change passwords on domain controllers. To apply the same banned-password evaluation on-premises:

1. Deploy the Microsoft Entra Password Protection proxy service in the forest (forwards DC validation requests to Entra—architecture uses proxy rather than every DC calling the internet directly in the supported design).
2. Deploy the Password Protection DC agent on domain controllers.
3. Register/configure the forest and set the mode: often Audit first, then Enforced.
4. On-premises password changes are evaluated against Microsoft’s algorithms and your custom list policy downloaded via the service.

SC-300 expects the concept, not a deep MSI install walkthrough: custom banned passwords + cloud protection + DC agent/proxy for hybrid, audit-then-enforce.

Password Protection is not MFA, not Conditional Access, and not a substitute for banning legacy auth. It reduces password spraying and guessing success when passwords still exist—especially valuable during passwordless migration when passwords have not been fully eliminated.

How MFA, SSPR, and Password Protection work together

Think of three complementary controls:

1. Password Protection — make the password harder to guess or spray.
2. SSPR + writeback — recover safely without helpdesk, keeping hybrid passwords consistent.
3. MFA via Conditional Access — ensure a stolen or reset password alone is not enough for apps.

A mature design still moves toward passwordless (Authenticator passwordless, FIDO2, Windows Hello for Business) so password reset volume falls. Until then, SSPR quality and banned passwords remain high-yield SC-300 topics.

Common exam traps

• Enabling Security defaults when the org already needs granular CA exceptions for break-glass and application-specific grants.
• Forgetting password writeback in hybrid SSPR scenarios.
• Treating per-user MFA as the modern answer when CA is described.
• Assuming custom banned passwords apply on-premises without DC agents.
• Using security questions as a “strong” reset method for executives.
• Believing MFA enrollment alone enforces MFA on every app without Security defaults or Conditional Access requiring it.

When a scenario mentions “require MFA for all users accessing the Azure portal except two emergency accounts, and block legacy auth,” draft Conditional Access policies—not Security defaults alone. When it mentions “users change passwords in M365 but AD still has the old password,” fix writeback. When it mentions “stop employees from using the company name in passwords on-premises,” deploy Password Protection with custom banned list and on-premises agents, typically audit then enforce.

/practice/azure-sc-300Practice questions with detailed explanations