L2. Modern Authentication and Application Identity: MFA, Passwordless, App Registrations & Managed Identities

The Authentication Methods Policy

Microsoft Entra ID centralizes which sign-in methods are allowed in a single Authentication methods policy, replacing the older separate MFA and self-service password reset (SSPR) method configurations. From here you enable or restrict methods like the Microsoft Authenticator app, FIDO2 security keys, Windows Hello for Business, certificate-based authentication, and SMS/voice (legacy, weakest, and increasingly discouraged).

Passwordless Authentication

Passwordless methods remove the password from the sign-in flow entirely, eliminating phishing and credential-stuffing risk against that factor:

• FIDO2 security keys — a physical hardware key using public-key cryptography; the private key never leaves the device, so there is nothing for a phishing site to capture
• Microsoft Authenticator passwordless phone sign-in — the user enters their username, gets a number-matching prompt on their phone, and approves it
• Windows Hello for Business — biometric or PIN unlock backed by a TPM-protected key pair on the device

Number matching is a critical MFA hardening detail: instead of a simple Approve/Deny push, the user must type the number shown on the sign-in screen into the Authenticator app, defeating MFA fatigue attacks where an attacker spams approval requests hoping for an accidental tap.

App Registrations vs. Enterprise Applications

This distinction shows up constantly on the exam and in real tenants:

One app registration can have a service principal (enterprise application entry) in every tenant that consents to it. Permissions, sign-in restrictions, and conditional access all target the service principal, not the app registration.

Delegated vs. Application Permissions

• Delegated permissions: the app acts *as the signed-in user*, limited to whatever that user is allowed to do
• Application permissions: the app acts *as itself*, with no signed-in user, and requires admin consent because there's no user to limit the blast radius

OAuth Permission Grants and Consent Settings

Consent settings control who can grant an app permissions:

• User consent can be disabled entirely, restricted to low-risk permissions only, or left open, reducing the risk of consent phishing where a malicious app requests broad delegated permissions
• Admin consent workflow lets a non-admin user request an app be reviewed and approved by an administrator instead of blocking them outright
• Existing grants are visible and revocable under each enterprise application's permissions blade, which is how you audit and remediate over-permissioned or risky third-party app consents

Managed Identities for Azure Resources

A managed identity is an identity Azure automatically manages for a resource (VM, Function App, Logic App, etc.), with no secret or certificate for you to store or rotate:

• System-assigned: tied 1:1 to the resource's lifecycle; deleted automatically when the resource is deleted
• User-assigned: an independent Azure resource that can be assigned to multiple compute resources, useful when several resources need the identical identity/permission set

Prefer a managed identity over a service principal with a client secret or certificate whenever the workload runs on Azure compute, since it removes a credential that would otherwise need storage, rotation, and Key Vault protection. Exam tip: Expect questions where the correct answer is "use a managed identity" specifically because it avoids secret management, and questions distinguishing app registration (definition) from service principal/enterprise application (the usable, permission-bearing instance in a tenant).