JUMP TO SECTIONChoose a lesson section
A secure method is a process—not a checkbox.
Our existing Understanding MFA and Conditional Access lessons explain factors and policy evaluation. This guide moves into operational decisions: how a method gets registered, how recovery is authorized, and how identity risk becomes a defensible response.
Choose a method by its assurance and lifecycle.
Microsoft Entra's Authentication methods policy controls method eligibility. A user's actual sign-in also depends on authentication-strength requirements, method registration, device/browser support and other policies. “MFA enabled” does not mean “phishing resistant.”
Passkeys (FIDO2)
A public-key authenticator bound to the legitimate relying party. Synced and device-bound credentials have different deployment and assurance properties.
Admin decision: Configure allowed passkey profiles, user/group targeting and security-info registration. Test the required authentication strength against actual app sign-in.
Watch out: An allowed passkey is not automatically registered or guaranteed to satisfy every Conditional Access policy.Microsoft Authenticator
The same app can support push MFA, TOTP and passwordless phone sign-in; they do not all have the same security properties.
Admin decision: Define authentication mode and targeting, consider number matching and the user registration experience.
Watch out: Ordinary push approval isn't equivalent to phishing-resistant FIDO2 authentication.Temporary Access Pass
A time-bound admin-issued passcode that lets approved users register or recover authentication methods, configured for one or multiple uses.
Admin decision: Verify the caller, enable TAP only where needed, issue securely with an appropriate lifetime, and replace it with a durable strong method.
Watch out: TAP expiration prevents new TAP use but does not necessarily terminate every already-established session.Certificate-based authentication
Microsoft Entra verifies an approved user's certificate against configured certificate and issuer trust and mapping rules.
Admin decision: Plan the PKI, certificate issuance, identity binding, revocation and operational rotation before enforcement.
Watch out: A certificate method is only as trustworthy as the issuance, revocation and mapping lifecycle.Windows Hello for Business
A local biometric or PIN unlocks a device-specific asymmetric credential used to authenticate the identity.
Admin decision: Plan device provisioning, trusted enrollment and the correct cloud, hybrid key, or cloud Kerberos trust strategy.
Watch out: A Windows Hello PIN is not a portable password; hybrid devices still depend on proper trust and registration.Phishing-resistant FIDO2 authenticators use public-key operations tied to the legitimate sign-in origin. Microsoft Authenticator push with number matching is useful MFA, but it doesn't automatically meet a phishing-resistant authentication strength. Check the actual method and required strength.
Enable the method. Then get people safely enrolled.
A passkey registration campaign can nudge eligible users during sign-in. Current Entra campaigns target either passkeys (FIDO2) or Microsoft Authenticator push, one method per campaign. The user needs appropriate method eligibility, a qualifying MFA sign-in, and authorization to register security information. A blocked registration page or unsupported device can suppress the prompt.
Inventory methods and user populations
Identify current registration, sign-in and device support. Separate regular users, privileged roles, guests and recovery populations.
Enable the correct methods
Use Entra ID → Authentication methods → Policies to target allowed passkeys, Authenticator, TAP or certificates to a limited pilot. Confirm the specific profile and method settings.
Choose an onboarding path
Existing MFA users may self-register. Approved new hires or people who lost factors can use an identity-verified TAP as a bridge; don't send it through an untrusted help-desk request.
Configure a registration campaign
Target passkey (FIDO2) or Microsoft Authenticator push registration for eligible groups, one target method at a time. Pilot include/exclude settings, snoozes and security-info Conditional Access behavior.
Validate access and recovery
Test supported device/browser experiences, policy authentication strength, legitimate recovery, removal of stale methods, failed unauthorized registration and help-desk readiness.
Verify the person's identity before issuing a Temporary Access Pass, configure an appropriately short lifetime and secure delivery, and remove obsolete methods after successful registration. TAP expiry is not synonymous with clearing all sessions; an incident may need separate session containment.
Recovery must work when the normal method doesn't.
Self-service password reset (SSPR), password protection and session revocation solve different problems. Design them together, but don't confuse their effects—especially in hybrid Entra/Active Directory environments.
Self-service password reset
Scope rollout to pilot users, set verification methods and registration requirements, test end-user recovery, and review licensing. For synchronized identities, configure supported password writeback so on-premises AD DS also receives the new password.
A completed cloud password reset doesn't guarantee the on-premises password was updated if writeback is missing or unhealthy.Entra Password Protection
Microsoft's global banned-password list automatically protects cloud password changes. A licensed custom list can include organization-specific terms. For on-premises AD DS password changes, install and validate the supported password-protection proxy and DC agents.
Entra Password Protection is not the same as Conditional Access or a password length check. Verify the allowed behavior in both cloud and hybrid systems.Disable account and revoke sessions
A confirmed compromise may require disabling sign-in, revoking session/refresh tokens, resetting credentials, verifying MFA methods and reviewing related app access. Follow security approvals, impact assessment and evidence preservation.
Revoking refresh sessions or blocking sign-in may not immediately invalidate all existing access tokens and app sessions; continuous access evaluation and service behavior vary.SSPR pilot checklist
Before: Verify the right license, target group, registered methods, password policies, administrators' recovery and support path.
During: Enable SSPR for a pilot group, test real recovery with an authorized test user and confirm verification requirements.
Hybrid: If AD DS remains authoritative, validate Connect Sync/Cloud Sync password writeback as supported and actual on-premises sign-in behavior.
After: Confirm users can recover securely, account notifications work and help desk staff understand lockout exceptions.
Sign-in risk. User risk. Workload risk. Different evidence.
Microsoft Entra ID Protection evaluates detections that may be generated during sign-in or later through offline analysis. Risk levels can change as new signals are processed. Before remediation, find out what was actually detected, which identity type is involved, and what controls are configured.
Sign-in risk
Could this authentication attempt be suspicious?Evidence: Per-event detections, sign-in result, IP/device/app, policy evaluation and time.
Response: Risk-based Conditional Access can challenge or block appropriately. Review real-time and offline detections before concluding the user is compromised.User risk
Is the account or its credentials likely compromised?Evidence: Identity Protection user risk, risk detections, sign-in history, account changes and corroboration.
Response: Use approved containment, secure password change or reset and recovery methods; verify risk remediation before restoring access.Workload identity risk
Could an application/service principal credential be abused?Evidence: Risky service-principal detections, credential inventory, app-only sign-ins, grants and downstream resource access.
Response: Contain per incident policy, rotate exposed credentials and connected secrets, review permissions and validate the job. A service principal cannot perform interactive MFA.Workloads are not users and cannot approve prompts. A risky application may require credential and connected-secret rotation, app-grant review, risk-based blocking where licensed, and validation that legitimate jobs still work.
Identity Protection's detailed risk reports and advanced risk-based controls have licensing requirements; full workload-risk details and risk-based Conditional Access also require the applicable Workload Identities Premium entitlements. This lesson uses simulations, not a substitute for those licensed features.
Correlate sign-ins and Defender evidence, contain a confirmed compromise and validate both blocked attacker sessions and approved user recovery.
Open Identity Risk Containment & Recovery →Identity Protection incident decisions
Work through three decisions. Review the available evidence, choose an action, and explain why it is safer than the alternatives. Fictional environment; no live tenant access.
A high-risk sign-in appears in the middle of the night.
- The employee normally signs in from a managed Northstar laptop.
- A new device and unfamiliar network appear in the risky sign-in.
- The employee has not confirmed that the sign-in was legitimate.
Which first response respects both security and evidence?
Make the call. Then defend it.
Choose one of four fictional Northstar scenarios: recover a lost authenticator, roll out passkey registration, investigate a risky employee, or contain a risky service principal. Select controls, validate your decisions and learn why unsafe shortcuts fail.
Secure the method. Validate the response.
The authenticator is gone. How do you recover safely?
A new hire loses their phone before registering a FIDO2 passkey. The help desk is asked to 'just turn off MFA.' Northstar has a verified identity-proofing process and has enabled TAP for the onboarding group.
A green status isn't the entire resolution.
Confirm identity, affected scope, licensing, method enrollment, policy and business impact. Retain the initial sign-in, risk and administrative evidence.
Record authorized changes to methods, recovery or containment. Use narrow controls with expiration and documented ownership.
Test intended sign-ins and blocked attempts, session behavior, old credential invalidation and affected application access. Preserve logs and approvals.
Start with pilot groups, do not lock out emergency accounts, and check the impact on guest users, legacy authentication and shared application workflows. A passwordless design needs a documented recovery path before it's enforced.
Verify product configuration with Microsoft.
The exact enrollment experience, accepted passkey profiles, licensing and available risk policies can evolve. These Microsoft references provide the current implementation details.
Can you restore access without weakening the tenant?
Practice 015 tests method selection, risk distinctions and safe recovery with original Northstar decisions.