MICROSOFT AZ-104 IDENTITY TOPIC

Security defaults vs Conditional Access vs MFA and SSPR: separate the controls.

Security defaults supply a baseline. Conditional Access decides when access controls apply. MFA strengthens sign-in proof. SSPR lets users recover their passwords after verifying identity.

Updated 25 August 2026 · Original ITCertPath learning resource

Start with the decision each feature makes

FeatureQuestion it answersTypical outcome
Security defaultsDoes this tenant need a simple baseline?Preconfigured protections applied broadly
Conditional AccessUnder these signals, what should access require?Allow, block or require grant controls
MFAHas the user supplied stronger identity evidence?Additional authentication requirement satisfied
SSPRCan this user safely reset a forgotten password?Identity verification followed by password reset

Fast decision rule

Simple tenant-wide baseline? Security defaults. Targeted if-then policy? Conditional Access. Stronger sign-in proof? MFA. Password recovery? SSPR.

Security defaults: a broad, preconfigured baseline

Microsoft Entra security defaults help protect tenants that need a straightforward starting point. Current Microsoft guidance describes protections that include registration for MFA, MFA for administrators and privileged activities, prompts when necessary, and blocking legacy authentication and device-code flow.

The strength is simplicity: the feature is available without premium licensing and does not require an administrator to design policy conditions. The tradeoff is limited customization. You cannot build different security-default policies for separate users, applications, locations or device states.

Important operational distinction

Security defaults are not a collection of editable Conditional Access policies. Treat the feature as a managed baseline that is enabled or disabled for the tenant.

Conditional Access: evaluate signals and enforce policy

Conditional Access is Microsoft Entra's policy engine. A simple policy reads like an if-then statement: if a selected user accesses a selected resource under specified conditions, then block access or require chosen controls.

Signals

Describe the request

User or workload identity, target resource, device state, location, client application and risk can contribute to evaluation.

Decision

Apply access controls

Grant access, block it, or require controls such as MFA, compliant device, approved app or a defined authentication strength.

Conditional Access is enforced after first-factor authentication. Multiple applicable policies are cumulative: if one requires MFA and another requires a compliant device, the user must meet both requirements unless another policy blocks access.

Safe rollout pattern

Define emergency-access exclusions, start with a pilot group, use report-only mode, review impact and dependencies, then enable the policy gradually. Do not disable the existing baseline before replacement controls are ready.

MFA: an authentication control, not the policy engine

Microsoft Entra MFA requires additional verification during sign-in. It can be invoked through security defaults, Conditional Access or older per-user MFA settings. Microsoft recommends Conditional Access for granular enforcement when licensing allows it; security defaults provide protection for tenants without Conditional Access.

Method quality matters. Passkeys, Windows Hello for Business and certificate-based authentication can provide stronger phishing resistance than reusable passwords or interceptable codes. A successful MFA event proves only that the authentication requirement was satisfied; it does not override device, location, risk or application-authorization controls.

SSPR: recover a password after identity verification

Self-service password reset allows eligible users to reset or unlock an account without a help-desk-initiated password change. The user must prove identity using allowed authentication methods before the password operation is completed.

SSPR and MFA can share combined security-information registration, but they remain different features. MFA verifies a sign-in or protected action. SSPR verifies the user for account recovery and then changes the password. For hybrid environments, verify whether password writeback and the required on-premises components are configured.

AZ-104 clue

When the requirement says users should reset their own passwords, evaluate SSPR scope, authentication methods and—where relevant—password writeback. Requiring MFA at sign-in does not itself enable password reset.

Worked rollout: replace security defaults with Conditional Access

Situation: A growing organization needs different controls for administrators, employees and a legacy service account. The tenant currently uses security defaults.

  1. Inventory access: identify users, applications, legacy authentication, device state and emergency-access accounts.
  2. Confirm licensing: verify that the users covered by Conditional Access have the required Microsoft Entra licensing.
  3. Design replacement policies: cover administrators, all users, Azure management, legacy authentication and other organizational requirements.
  4. Protect recovery: exclude only controlled emergency-access accounts and monitor their use.
  5. Test safely: use report-only mode and pilot groups; evaluate results with sign-in logs and the What If tool.
  6. Switch without a gap: disable security defaults only when the replacement policies are ready to be enabled.
  7. Review outcomes: confirm users can register methods, SSPR works as designed and blocked clients are understood.
What you learn today

The migration is not “turn off defaults, then start designing.” Preserve equivalent protections, test policy interaction and avoid locking out administrators.

MFA succeeded but the application is blocked

Follow the entire decision path instead of repeatedly resetting the user's MFA methods:

  1. Open the Microsoft Entra sign-in event and confirm the correct user, application and timestamp.
  2. Review the Conditional Access tab to see every policy that applied, did not apply or reported failure.
  3. Check whether MFA satisfied one policy while another required a compliant device or blocked the request.
  4. Confirm device registration, compliance, client type, location and authentication strength.
  5. Use the Conditional Access What If tool to model the request, then compare it with the real sign-in evidence.
  6. After authentication succeeds, check the application's own authorization if access is still denied.

Practice checks with explanations

Question 1

A free tenant needs a quick baseline without custom conditions. Which feature?

Security defaults. The clue is broad, preconfigured protection without policy customization.

Question 2

Require MFA only for Azure management from unmanaged devices. Which feature?

Conditional Access. The requirement combines a target resource, a device signal and a grant control.

Question 3: users must reset forgotten passwords without calling support

SSPR. Configure eligible users, authentication methods and any required hybrid writeback; MFA alone does not supply the reset workflow.

Common exam and administration mistakes

  • Calling Conditional Access another authentication factor.
  • Assuming MFA success guarantees application access.
  • Trying to customize security defaults by user or application.
  • Disabling security defaults before replacement policies are active.
  • Testing a broad block policy without emergency-access protection.
  • Confusing combined registration with identical MFA and SSPR behavior.
  • Ignoring licensing, legacy clients and service dependencies during rollout.

Frequently asked questions

Can security defaults and Conditional Access be used together?

Security defaults are an on-or-off baseline and don't provide the customization of Conditional Access. Microsoft guidance says organizations replacing security defaults with Conditional Access should disable security defaults and immediately enable policies that preserve the required protections.

Is MFA the same as Conditional Access?

No. MFA is an authentication requirement. Conditional Access is a policy engine that evaluates signals and can require MFA, a compliant device, an approved client, an authentication strength or another grant control.

Is SSPR a security defaults feature?

SSPR is a separate password-reset capability. Authentication-method registration can be combined for MFA and SSPR, but the features have different purposes and configuration requirements.

When should an organization use security defaults?

Security defaults provide a simple identity-security baseline, especially for organizations on Microsoft Entra ID Free or those without the resources and licensing to design Conditional Access policies.

Why can MFA succeed while access is still denied?

MFA can satisfy only one policy requirement. Another applicable Conditional Access policy may require a compliant device, block a location or client type, or deny access. Application authorization can also reject the user after authentication.

Official Microsoft references

Review Microsoft's current documentation for security defaults, the Conditional Access overview, Microsoft Entra MFA and the current AZ-104 study guide. Use the official exam guide as the final scope authority.