Microsoft Entra ID & Identity

This book section is for MS Entra ID & Identity services documentation. Plus documentation for application authentication across the Tech Infrastructure stack, including SSO integrations, identity providers, authentication protocols, and configuration guidance.

OIDC SSO with Entra ID - Integration Guide

Field

Details

Document Type

How-To Guide - SSO Integration

Applies To

Microsoft Entra ID, Any OIDC-compatible SaaS or Third-Party Application

Audience

2nd Line / Systems Administrator / IT Engineer

Author

AK. Udofeh

Last Updated

March 2026

Overview

This article covers how to configure Single Sign-On (SSO) using the OpenID Connect (OIDC) protocol between Microsoft Entra ID and any third-party or SaaS application that supports OIDC for authentication. It is intended for systems administrators who need to integrate enterprise applications with Entra ID to centralise identity management, enforce MFA, and control user access. The guide covers App Registration in Entra ID, redirect URI configuration, required API permissions, and the standard OIDC configuration values expected by most OIDC-compliant applications.

 

Root Cause

OIDC SSO works by delegating authentication to Entra ID as the Identity Provider (IdP). The application (Service Provider) redirects the user to Microsoft's authorisation endpoint, which authenticates the user and returns an ID token containing identity claims. The application then validates the token using signing keys retrieved from Microsoft's OIDC discovery document.

Common Failure Points

Check

Where

You have Global Administrator or Application Administrator rights in Entra ID

Entra ID → Roles and Administrators

The target application supports OIDC (not only SAML)

Application vendor documentation

You know the exact Redirect URI format expected by the application

Application vendor documentation

Outbound HTTPS (port 443) from the application server to login.microsoftonline.com is permitted

Firewall / network policy

You have admin access to the application's configuration settings

Application admin console or hosting environment

A client secret can be created and stored securely

Azure Key Vault or organisation secrets manager

Step 1: Create an App Registration in Entra ID

Note the following values from the Overview page - you will need these later:

•    Application (client) ID - this is your OIDC Client ID
•    Directory (tenant) ID - this is used to construct your OIDC Issuer URL

Step 2: Create a Client Secret

Copy the secret Value immediately - it will not be displayed again after you navigate away. Store it securely in a secrets manager or vault.

Step 3: Configure the Redirect URI

Step 4: Grant API Permissions

Permission

Purpose

openid

Required - enables OIDC sign-in

profile

Provides basic profile claims (name, etc.)

email

Provides the user's email address claim

All three permissions should show a green tick with "Granted for <tenant>" status.

 

Step 5:  Configure the Application

Add the following configuration values to your application. The exact setting names vary per application — refer to your application's OIDC documentation. The values below represent the standard OIDC parameters used across most platforms:

Configuration Key

Value

Auth Method / SSO Protocol

oidc

Client ID

Application (client) ID from Entra App Registration

Client Secret

Secret value created in Step 2

Issuer URL

https://login.microsoftonline.com/<Directory (tenant) ID>/v2.0

Auto-Discovery

true (recommended — eliminates need to manually specify endpoints)

Redirect / Callback URI

Must match exactly what was registered in Step 3

Scopes

openid profile email

Critical: Issuer URL format: The Issuer URL must contain only the tenant GUID in the path and must end with /v2.0. A common misconfiguration is storing a full URL in a variable and substituting it into the Issuer field, producing a doubled path such as https://login.microsoftonline.com/https://login.../v2.0/v2.0. This will cause discovery to fail. Correct format: https://login.microsoftonline.com/e21b46c3-367f-4ced-b138-2c57e76746f6/v2.0

Step 6:  Restrict Access via Enterprise Application (Recommended)

By default, any user in your Entra tenant can attempt SSO into the application. To restrict access to specific users or groups:

Only assigned users will be permitted to authenticate. All others will receive an Entra-side access denied message before reaching the application.

 

Step 7: Optional: Group-to-Role Synchronisation

If the application supports mapping identity provider groups to application roles, you can automate role assignment via Entra group membership:

Entra sends group Object IDs, not display names, in the token. Always use the group's Object ID when mapping groups to application roles - not the group's display name.

Troubleshooting

OIDC Discovery Error / Discovery endpoint unreachable

Cause: The application cannot fetch the OIDC discovery document from Microsoft, or the Issuer URL is malformed.

Resolution:

bash

curl -s "https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration" | head -c 200

Missing required configuration "keys" value or similar

Cause: Auto-discovery is disabled or not correctly configured. The application is expecting manually specified JWKS signing keys.

Resolution:

redirect_uri_mismatch

Cause: The Redirect URI registered in Entra does not exactly match the callback URL the application is generating or sending.

Resolution:

 invalid_client

Cause: The Client ID or Client Secret is incorrect, or the client secret has expired.

Resolution:

User authenticates successfully in Entra but receives an error or no access in the application

Cause: The user account was provisioned in the application with no role or permissions assigned.

Resolution:

invalid_grant or token validation failure

Cause: Clock skew between the application server and Microsoft's servers, or the authorisation code was already consumed.

Resolution:

Expected Outcome

Factor

Detail

Resolution Time

30–60 minutes for initial configuration; 15 minutes for troubleshooting known issues

User Impact

Zero - SSO login is additive; existing local accounts remain functional during migration

Recurrence Risk

Low - primary recurring issue is client secret expiry; set a calendar reminder before the secret's expiry date

Ongoing Maintenance

Rotate client secrets before expiry; manage user access via Enterprise Application user/group assignments

SAML v2.0 SSO with Entra ID - Integration Guide

Field

Details

Document Type

How-To Guide: SSO Integration

Applies To

Microsoft Entra ID, Any SAML 2.0-compatible SaaS or Third-Party Application

Audience

2nd Line / Systems Administrator / IT Engineer

Author

AK. Udofeh

Last Updated

March 2026

Overview

This article covers how to configure Single Sign-On (SSO) using the SAML 2.0 protocol between Microsoft Entra ID and any third-party or SaaS application that supports SAML for authentication. It is intended for systems administrators who need to integrate enterprise applications with Entra ID to centralise identity management, enforce MFA, and control user access. The guide covers Enterprise Application creation in Entra ID, SAML endpoint configuration, certificate handling, and attribute claim mapping.

 

SAML SSO works by delegating authentication to Entra ID as the Identity Provider (IdP). The application (Service Provider / SP) redirects the user to Entra's SAML endpoint, which authenticates the user and returns a signed SAML assertion containing identity attributes. The application validates the assertion signature using Entra's signing certificate and establishes a user session.

Common Failure Points

Before You Start

Check

Where

You have Global Administrator or Application Administrator rights in Entra ID

Entra ID > Roles and Administrators

The target application supports SAML 2.0 (not only OIDC)

Application vendor documentation

You have the application's ACS URL, Entity ID, and SLO URL

Application vendor documentation or SP metadata XML

Outbound HTTPS (port 443) from the application server to login.microsoftonline.com is permitted

Firewall / network policy

You have admin access to the application's configuration

Application admin console or hosting environment

Step 1:  Create an Enterprise Application in Entra ID

For SAML SSO, configuration is done through Enterprise Applications, not App Registrations. An App Registration is created automatically in the background.

You will be taken to the application overview page.

 

Step 2:  Configure SAML Settings

If the application provides a metadata XML URL (e.g. https://app.yourdomain.com/saml/metadata), Entra can import these values automatically — click Upload metadata file at the top of the Basic SAML Configuration panel.

Click Save.

 

Step 3:  Download the Entra Signing Certificate

Store a copy of this certificate securely. If Entra's signing certificate is rotated (e.g. on expiry), the application will fail to validate assertions until the new certificate is imported.

Step 4: Collect IdP Configuration Values

In the SAML configuration page, note the following values in the "Set up <app name>":

Value

Description

Login URL

Entra's SAML SSO endpoint - set as the IdP SSO URL in the application

Logout URL

Entra's SAML SLO endpoint - set as the IdP SLO URL in the application

Entra ID Identifier

Entra's Entity ID - set as the IdP Entity ID in the application

Certificate (Base64)

Signing certificate from Step 3 - used by the application to validate assertions

Alternatively, download the Federation Metadata XML from the same section - many applications can import this file directly to auto-populate all IdP settings.

Step 5: Configure Attribute Claims in Entra

By default, Entra sends a standard set of SAML attribute claims. Verify these match what the application expects:

            The default claims sent by Entra are:

Claim Name

Value

emailaddress

user.mail

givenname

user.givenname

surname

user.surname

name

user.userprincipalname

By default, Entra sends group Object IDs (GUIDs) in the group claim, not display names. Configure the application's role mapping to use Object IDs, or change the group claim's source attribute to display names if supported.

Step 6: Restrict Access via Enterprise Application (Recommended)

Step 7: Configure the Application

In the Service Provider application, enter the values collected in Step 4 into the application's SAML configuration. The exact setting names vary per application - refer to the application vendor's SAML documentation. The standard SAML parameters are:

Application Setting

Value to Enter

IdP Entity ID

Entra ID Identifier from Step 4

IdP SSO URL

Login URL from Step 4

IdP SLO URL

Logout URL from Step 4

IdP X.509 Certificate

Certificate base64 content from Step 3

SP Entity ID

Must match the Identifier (Entity ID) entered in Entra Step 2

ACS URL

Must match the Reply URL entered in Entra Step 2

Name ID Format

emailAddress or persistent - check application documentation

Binding

HTTP-POST for ACS; HTTP-Redirect for AuthnRequest

=========================Troubleshooting====================

AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters

Cause: The application is not correctly forming the SAML AuthnRequest, or the binding type does not match Entra's expectation.

Resolution:

AADSTS70011: The provided value for the input parameter 'redirect_uri' is not valid

Cause: The ACS URL registered in Entra does not match the URL the application is posting to.

Resolution:

AADSTS750057: Invalid SAML response or no SAML response

Cause: The Entity ID in the application does not match what is registered in Entra, or the SAML response is malformed.

Resolution:

Assertion signature validation fails / Invalid signature

Cause: The X.509 certificate used for validation in the application does not match the current Entra signing certificate, or the certificate has expired.

Resolution:

Entra signing certificates expire every 3 years by default. Set a calendar reminder 60 days before expiry to plan a rotation window.

 

Single Logout (SLO) does not work - user remains signed in to Entra after signing out of the application

Cause: The SLO URL is not configured in either Entra or the application, or the binding types do not match.

Resolution:

User authenticates successfully in Entra but receives an error or no access in the application

Cause: The SAML assertion was accepted, but the user account was provisioned with no role or permissions in the application.

Resolution:

Attribute claims are empty or not recognised by the application

Cause: The attribute claim names sent by Entra do not match the names the application is expecting.

Resolution:

Expected Outcome

Factor

Detail

Resolution Time

45–90 minutes for initial configuration; additional time if attribute mapping requires investigation

User Impact

Zero - SAML SSO is additive; existing local accounts remain functional during migration

Recurrence Risk

Low - primary recurring issue is Entra signing certificate expiry (every 3 years by default)

Ongoing Maintenance

Rotate Entra signing certificate before expiry; manage user access via Enterprise Application assignments

WebApp Authentication with Social IDPs (Google, Facebook & Apple ID)

Field

Details

Document Type

Runbook / How-To Guide

Applies To

Microsoft Entra ID External Identities (CIAM), Social Identity Providers (Google, Facebook, Apple), Third-party Web Applications 

Audience

Systems Administrators / Identity Engineers / 2nd Line Support

Author

AK. Udofeh

Last Updated

March 2026
Overview
This guide documents how to integrate Social Identity Providers (Google, Facebook, and Apple) with a SAML-based web application for authentication using Microsoft Entra ID External Identities and Customer Identity & Access Management (CIAM). The configuration allows users to authenticate using social accounts while Microsoft Entra acts as the identity broker and issues a SAML assertion to the third-party or line-of-business (LOB) web application.
The process involves creating an external tenant, registering social identity providers, creating a user flow, configuring a SAML enterprise application, and updating the application configuration.
The Issue
Organisations often require users to authenticate using Social Identities (e.g. Google or Facebook) while maintaining a centralised identity broker for security and policy enforcement.
Without a configured identity broker:
Basic authentication methods such as:
do not provide centralised identity management or federation capabilities.
Using Microsoft Entra External Identities resolves this by brokering authentication from social providers and issuing a standard SAML assertion to the application.
Authentication via Socials IDP.png
Context
Modern applications often require authentication from multiple identity providers while maintaining centralised access control.
Without a broker, the authentication flow typically looks like this:
User
  ↓
Application
  ↓
Direct OAuth with Google/Facebook
This causes several issues:
Using Microsoft Entra External Identities introduces an identity broker layer:
User
  ↓
Google / Facebook / Apple
  ↓  (OAuth / OIDC)
Microsoft Entra External Tenant (CIAM)
  ↓  (User Flow)
Enterprise Application (SAML)
  ↓
Flask Web Application
In this architecture:
Before You Start
Check
Where
External tenant created
Microsoft Entra admin centre
Azure subscription linked
Tenant creation wizard
Google Developer Console account
console.cloud.google.com
Meta Developer account
developers.facebook.com
Apple Developer account (optional)
developer.apple.com
SAML web application deployed
Flask service
Service Provider metadata configured
settings.json

Implementation Steps (Per Environment)

Phase 1 - Create External Tenant

Step 1: Sign in to the Microsoft Entra admin centre:
https://entra.microsoft.com 
Navigate to:
Microsoft Entra ID> Overview> Manage Tenants

Click:

Create> External
Enter the tenant details:
Click:
Review + Create> Create
Provisioning may take up to 30 minutes.
Switch to the new tenant:
Settings> Directories + Subscriptions> Switch

Phase 2 -  Add Social Identity Providers

Navigate to:
External Identities
> All Identity Providers

Integrate with Google Identity Provider

Step 1: Configure Google OAuth
Visit: https://console.cloud.google.com/ 
In Google Cloud Console:
APIs & Services
> Credentials
> OAuth2 Client ID
Fill in the Name of the Webapp
Add the Authorized redirect URI:
https://<tenant-subdomain>.ciamlogin.com/<tenant-subdomain>.onmicrosoft.com/federation/oauth2

Copy the following values and keep is save

> Client ID
> Client Secret
Step 2: Register Google as Idp in Entra ID
In Entra ID (Ext tenant directory) navigate to:
External Identities
> All Identity Providers
Enter:
Client ID
Client Secret
Click:
Save

Integrate with Facebook Identity Provider

Step 1: Create Meta Developer App
Visit to:
https://developers.facebook.com 
Select:
My Apps > Create App
Choose:
Authenticate and request data from users with Facebook Login
Select platform:
Web
Add redirect URI:
https://<tenant-subdomain>.ciamlogin.com/<tenant-subdomain>.onmicrosoft.com/federation/oauth2
In App Settings > Basic, copy:
App ID
App Secret
Add application domain:
<your domain here> (e.g: example.com)

Without adding the domain, Facebook login will fail with: "Can't load URL — domain isn't included in the app's domains"

Switch the application to:
Live Mode
Step 2: Register Facebook Idp in Entra ID
In Entra ID (Ext tenant directory) navigate to:
External Identities
> All Identity Providers
> + Facebook
Enter:
App ID
App Secret
Click:
Save

Integrate with Apple Identity Provider

Prerequisite: ● An active Apple Developer Account (Paid membership).

Step 1: Configure Apple Developer Portal
Navigate to:
https://developer.apple.com
Create an App ID with:
Sign in with Apple enabled
Create a Services ID
Example:
com.example.samllab
Configure redirect URI:
https://<tenant-subdomain>.ciamlogin.com/<tenant-subdomain>.onmicrosoft.com/federation/oauth2
Create Sign In with Apple Key
Download:
.p8 private key
Record:
Key ID
Team ID
Step 2: Register Apple Idp in Entra ID
In Entra ID (Ext tenant directory) navigate to:
External Identities
> All Identity Providers
> + Apple
Configure:
Client ID: Your Apple services ID
Apple developer team ID: Your Apple Team ID here
Key ID: Your Apple Key ID here
Client Secret: Upload the .p8 key file here

Phase 3: Create a User Flow

In Entra ID (Ext tenant directory) navigate to:
External Identities
> User Flows
> + New User Flow
Configure:
Name: (e.g) PilotApp-Auth-via-Socials
Enable identity providers:
Email with Password
Google
Facebook
Select attributes:
Display Name
Email Address
Given Name
Surname
Click:
Create

Phase 4: Register the SAML Application in Entra ID Ext Tenant directory

Navigate to:
Enterprise Applications
> New Application
> Create Your Own Application
Name:
My PilotApp with Socials Idp
Select:
Integrate any other application you don't find in the gallery
Configure SAML
Navigate to:
Single Sign-On
> SAML
Configure:
Identifier (Entity ID)
https://mypilot-app.example.com

Reply URL (ACS)
https://mypilot-app.example.com/acs
Configure Attributes & Claims
Map attributes:
Claim Value
givenname user.givenname
surname user.surname
emailaddress user.mail

Obtain Federation Metadata
Download:
Federation Metadata XML
Extract:
IdP Entity ID
SSO URL
Signing Certificate
In Entra ID Ext Tenant Directory Link the Application to the User Flow
Navigate to:
External Identities
> User Flows
> saml_lab_signin
> Applications
Click: Add Application
Select: <The Enterprise App you want to integrate>

Phase 5: Update Third-party or LOB App that you want to integrate with Socials IDP

Replace workforce tenant values with the external tenant values.
# External Tenant Configuration

SAML_IDP_ENTITY_ID=https://<external-tenant-id>.ciamlogin.com/<external-tenant-id>/
SAML_IDP_SSO_URL=https://<tenant-name>.ciamlogin.com/<tenant-name>.onmicrosoft.com/saml2
SAML_IDP_X509CERT=<base64-certificate>
Save the configuration.
The application will now authenticate users through the External Tenant user flow.

SAML - social idp UI.png

--------------------------------- Troubleshooting -----------------------------------

Facebook -  Domain Not Included in App Domains
Error: 
Can't load URL The domain of this URL isn't included in the app's domains
Resolution:
Add the application domain in:
Meta Developer Console
>  App Settings
>  Basic
>  App Domains
Facebook - Invalid Scopes Email
Error:
Invalid Scopes: email
Resolution:
Add the permission:
Permissions and Features
> email
Google - Redirect URI Mismatch
Error:
redirect_uri_mismatch
Resolution:
Ensure the redirect URI in Google Console matches:
https://.ciamlogin.com/.onmicrosoft.com/oauth2/authresp
SAML Login Failure
Error:
AADSTS75011 Authentication method mismatch
Resolution:
Disable strict authentication context in the Service Provider configuration.
Metric
Result
Resolution Time
~45–90 minutes
User Impact
Users can authenticate using social providers
Authentication Method
Google, Facebook, Apple, or local account
Recurrence Risk
Low once identity providers are configured

Entra ID Self-Service Password Reset (SSPR) Implementation

Field

Details

Document Type

How-To Guide: Enterprise Implementation Runbook

Applies To

Microsoft Entra ID, Microsoft Entra Connect Sync, Microsoft 365

Audience

Identity Engineers / Entra ID Administrators / Systems Administrators
Author

AK. Udofeh

Last Updated

March 2026
Overview

SSPR image.png

This document provides a complete runbook for implementing Self-Service Password Reset (SSPR) in Microsoft Entra ID within an enterprise environment using Entra Connect Sync with Password Writeback. The guide walks through prerequisites, configuration steps, authentication method setup, hybrid password writeback, monitoring, and troubleshooting.

The configuration enables users and administrators to reset their own passwords securely using Microsoft Authenticator, SMS, and Security Questions, with passwords written back to on-premises Active Directory.

The Issue

In organisations without Self-Service Password Reset enabled:

Common symptoms in such environments include:

Basic remediation steps such as:

do not resolve the underlying issue, because the problem is structural: users lack a secure self-service mechanism.

Context

The root cause is the absence of Self-Service Password Reset capability integrated with the organisation’s identity infrastructure.

In hybrid identity environments, password changes must occur across two identity planes:

User → Entra ID Authentication
       ↓
SSPR Validation (Authenticator / SMS / Questions)
       ↓
Entra ID Password Reset Engine
       ↓
Password Writeback via Entra Connect
       ↓
On-Prem Active Directory Password Update
       ↓
Password Sync Back to Entra ID
Normal Process (with SSPR)

  1. User initiates password reset.

  2. Entra ID verifies identity using configured authentication methods.

  3. Password reset is approved.

  4. Password writeback sends the new password to on-prem AD.

  5. Entra Connect synchronises the updated password hash.

What Breaks Without SSPR
Known Triggers for Password Reset Demand
Before You Start
Check Where
Entra ID P1 or P2 licenses assigned Microsoft 365 Admin Center
Microsoft Entra Connect Sync installed On-prem identity server
Password Writeback feature enabled Entra Connect configuration
Hybrid identity synchronisation healthy Entra Connect Health
Security group created for SSPR pilot scope Entra ID → Groups
Users registered for authentication methods Security Info portal
Required firewall ports open Identity infrastructure
Implementation steps

Step 1: Create the SSPR Security Group

1. Open the Microsoft Entra Admin Center

https://entra.microsoft.com

2. Navigate to:

Identity > Groups

3. Select New Group

Configuration:

Setting Value
Group Type Security
Name SSPR-Enabled-Users
Membership Assigned

4. Add users who should have SSPR enabled.

This group will be used to scope the SSPR policy.

Step 2: Enable Self-Service Password Reset

Navigate to:

Entra ID > Password Reset
Setting Value
Self Service Password Reset Enabled Selected
Selected Group SSPR-Enabled-Users

Save the configuration.

Step 3: Configure Authentication Methods

Navigate to:

Entra ID > Authentication Methods
Method Enabled
Microsoft Authenticator Enabled
SMS Enabled
Email OTP Enabled

Choose and enable all required Auth methods and add the Entra ID group with the SSPR-Enabled-Users group to the policy.

Navigate to: 

Entra ID > Password Reset > Authentication Methods
Setting Value
Number of methods required 1

Choose the desired number of authentication methods required to reset a password and save.

Step 4: Enable Password Writeback

Open the Microsoft Entra Connect Windows Server.

Launch:

Azure AD Connect

Select:

Configure → Customize synchronization options

During configuration:

Enable:

Password writeback

Entra ID Connect setup.png

Complete the configuration wizard.

Verify status in:

Entra Admin Center
Identity → Hybrid Management → Entra Connect

Password writeback must show Enabled.

Step 5: Enable Administrator SSPR

In Entra ID navigate to:

Entra ID > Password Reset > Administration Policy

Administrators require stricter security.

Setting Value
Number of authentication methods required 2
Allowed methods Authenticator, SMS

Security questions are not recommended for administrators.

Step 6:  Verify Combined Security Information Registration

Combined registration allows users to configure MFA and Self-Service Password Reset authentication methods in a single workflow.

Navigate to:

Entra ID > Authentication Methods > Settings

Verify the tenant is using the modern Authentication Methods policy framework.

If the Combined registration toggle is not visible, the feature is already enabled by Microsoft and no further configuration is required.

User registration portal:

https://aka.ms/mysecurityinfo

Users will register the following methods during onboarding:

This portal supports both MFA and SSPR authentication method registration.

Step 7: Configure User Notification Settings

Navigate to:

Password Reset > Notifications
Setting Value
Notify users on password reset Enabled
Notify admins on admin password reset Enabled

==================================== Monitoring and Reporting ==============================

Entra Audit Logs

Navigate to:

Entra Admin Center
Password reset > Audit Logs

Filter for:

Activity: Self-service password reset

Events recorded:

Sign-In Logs

Navigate to:

Password reset > Audit Logs

Review authentication challenges and method usage.

SSPR Usage Reports

Navigate to:

Entra ID > Password Reset > Usage & Insights

Metrics include:

Metric Description
Password resets Total resets performed
Registrations Users who registered authentication methods
Success rate Successful resets vs attempts

These reports help measure adoption and identify issues.

============================Troubleshooting=====================
Password Writeback Failed

Error example:

Password reset failed to write back to on-premises directory

Possible causes:

Resolution:

  1. Verify Entra Connect service status.

  2. Confirm writeback is enabled.

  3. Check Event Viewer - Application Logs on the Entra Connect server.

User Not Allowed to Reset Password

Possible cause:

User not included in the SSPR security group.

Resolution:

  1. Add the user to the SSPR group.

  2. Wait for directory replication.

User Not Registered for Authentication

Error example:

You need to register for password reset

Resolution:

Direct the user to:

https://aka.ms/mysecurityinfo

https://aka.ms/mysecurityinfo

Complete registration before attempting password reset.

Administrator Reset Fails

Possible cause:

Administrator policy requires stronger authentication.

Resolution:

Ensure the administrator has registered:

Expected Outcome
Metric Result
Resolution Time Immediate user password reset
User Impact Reduced helpdesk dependency
Recurrence Risk Low once authentication registration is completed

SAML Transformation Fallback Workaround (Microsoft Entra ID)

Field

Details

Document Type

How-To Guide - SSO SAML Transformation Runbook

Applies To

Microsoft Entra ID, 3rd-Party WebApps & Single-name user accounts

Audience

2nd Line / Entra ID Admins / IT Engineer

Author

AK. Udofeh

Last Updated

Jan 2026
Overview

This document describes a targeted workaround implemented within Microsoft Entra ID to address a SAML single sign-on (SSO) integration limitation with 3rd-Party or InHouse LOB WebApp, where the service provider requires the givenName (first name) attribute to be present during authentication.

The workaround enables successful authentication for users who have a single name recorded in Entra ID (i.e. no givenName or surname attribute populated), without modifying directory data.

Background

During an investigation of a user login issue raised by a 3rd-Party Service Provider support team, it was identified that:

This behaviour is Service Provider side and outside of Entra ID control. However, a controlled, application-scoped workaround is possible using SAML claim transformations.

Design Principles

The workaround was designed with the following principles in mind:

Technical Summary

The SAML givenName claim for the WebApp Enterprise Application is configured using a conditional transformation:

This ensures that the WebApp always receives a non-null givenName value, allowing authentication to complete successfully.

No other SAML claims are affected.

Implementation Details

Microsoft Entra ID > Enterprise Applications > WebApp > Single sign-on >Attributes & Claims

Claim:
Transformation Logic:

  1. IfNotEmpty(user.surname) > output user.surname

  2. IfEmpty(previous output) > output user.givenname

f173a4ac-8b74-4c80-87e1-36e746334983.png

This transformation is evaluated at authentication time and does not write back to Entra ID.

Impact Assessment
Who is affected:
What changes:
What does NOT change:
Risks and Considerations

This implementation should not be used as a general pattern unless explicitly required.

Configuring Phishing‑Resistant MFA (PR‑MFA) in Entra ID Conditional Access

Field

Details

Document Type

How-To Guide - Configure Phishing‑Resistant MFA (PR‑MFA)

Applies To

Microsoft Entra ID, Conditional Access policy

Audience

2nd Line / Entra ID Admins / IT Engineer

Author

AK. Udofeh

Last Updated

March 2026
Overview

Phishing‑Resistant MFA (PR‑MFA) is the strongest authentication assurance level available in Microsoft Entra ID. It requires cryptographically bound authentication methods such as FIDO2 security keys, device‑bound passkeys, or Windows Hello for Business.

Microsoft formally introduced Phishing‑resistant MFA Authentication Strength as part of Conditional Access by 2025. This prevents attackers from bypassing MFA via techniques like real‑time phishing proxies, MFA fatigue, push spam, or OTP interception.

Use Cases

Use PR‑MFA for:

Prerequisites
Licensing

Technical Requirements

Supported Authenticators

Do not enforce PR‑MFA without ensuring users have registered the required method. Risk of tenant lockout. Break‑glass (emergency access) accounts must be excluded. Legacy apps that do not support modern authentication may require exceptions or re‑architecture.

Step‑by‑Step Configuration

Step 1:  Enable Phishing‑Resistant Authentication Methods

Step 2: Create a Security Group for Pilot Users

Step 3: Configure Authentication Strength

This explicitly enforces device‑bound cryptographic methods.

Step 4: Create the PR‑MFA Conditional Access Policy

Validation Steps

These should satisfy the authentication requirement if configured correctly.

====================== Troubleshooting =========================

Issue Resolution
Users locked out Confirm registration at https://aka.ms/mysecurityinfo and exclude user temporarily
FIDO2 key not accepted Ensure attestation not restricted & key model supported
Windows Hello not offered Check if device is Entra‑joined/registered
App can't satisfy PR‑MFA App may be legacy / does not support modern auth

Enabling Token Protection in Entra ID Conditional Access

Field

Details

Document Type

How-To Guide - Enable Token Protection in Entra ID Conditional Access

Applies To

Microsoft Entra ID, Conditional Access policy

Audience

2nd Line / Entra ID Admins / IT Engineer

Author

AK. Udofeh

Last Updated

March 2026
Overview

Token Protection is a Conditional Access session control that cryptographically binds authentication tokens (e.g., Primary Refresh Tokens) to a specific device. This prevents token replay, pass‑the‑cookie attacks, and AiTM token theft. It ensures that even if an attacker steals a token, they cannot use it on another machine.

Use Cases

Use Token Protection when:

Prerequisites

Licensing - Microsoft Entra ID P1 is required for Token Protection.

Device Requirements
Supported Platforms (per Microsoft):

Platform Support Level Requirements
Windows 10+ GA Entra‑joined, Hybrid‑joined, or Entra‑registered devices
macOS 14+ Preview Must be MDM‑managed + Enterprise SSO plug‑in
iOS/iPadOS 16+ Preview Must be MDM‑managed + Enterprise SSO plug‑in
Android ❌ Not Supported - 

Application Requirements
Token Protection currently supports:

Browser‑based sessions NOT supported (only native apps). Deploy in Report‑only mode first to prevent app/device disruption. MDM is required for macOS/iOS preview support.

Step‑by‑Step Configuration

Step 1:  Validate Device Registration
Devices must be:

Step 2:  Create a Pilot Group
Create group: TokenProtection‑Pilot.

Step 3:  Create Token Protection Conditional Access Policy

The Conditional Access policy should only be configured for these applications. Selecting the Office 365 application group might result in unintended failures. This change is an exception to the general rule that the Office 365 application group should be selected in a Conditional Access policy. - According to Microsoft Learn.

Not configuring the Client Apps condition, or leaving Browser selected might cause applications that use MSAL.js, such as Teams Web to be blocked.

Step 4:  Move to Full Enforcement
After reviewing logs:

Validation Steps
Capture logs and analyze

Monitor Conditional Access enforcement of token protection before and after enforcement by using features like Policy impact, Sign-in logs, and Log Analytics.

Sign-in logs

Use Microsoft Entra sign-in log to verify the outcome of a token protection enforcement policy in report only mode or in enabled mode.

  1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
  2. Browse to Entra ID > Monitoring & health > Sign-in logs.
  3. Select a specific request to determine if the policy is applied or not.
  4. Go to the Conditional Access or Report-Only pane depending on its state and select the name of your policy requiring token protection.
  5. Under Session Controls check to see if the policy requirements were satisfied or not.
  6. To find more details about the binding state of the request, select the pane Basic Info and see the field Token Protection - Sign In Session. Possible values are:
    1. Bound: the request was using bound protocols. Some sign-ins might include multiple requests, and all requests must be bound to satisfy the token protection policy. Even if an individual request appears to be bound, it doesn't ensure compliance with the policy if other requests are unbound. To see all requests for a sign-in, you can filter all requests for a specific user or look by correlation ID.
    2. Unbound: the request wasn't using bound protocols. Possible statusCodes when request is unbound are:
      1. 1002: The request is unbound due to the lack of Microsoft Entra ID device state.
      2. 1003: The request is unbound because the Microsoft Entra ID device state doesn't satisfy Conditional Access policy requirements for token protection. This error could be due to an unsupported device registration type, or the device wasn't registered using fresh sign-in credentials.
      3. 1005: The request is unbound for other unspecified reasons.
      4. 1006: The request is unbound because the OS version is unsupported.
      5. 1008: The request is unbound because the client isn't integrated with the platform broker, such as Windows Account Manager (WAM).

image.png

 
======================== Troubleshooting =======================
Issue Cause Solution
User blocked from Outlook/Teams Device not registered / not supported Verify Entra join/registration status
macOS/iOS failing Not MDM‑managed Enforce MDM requirement for preview support
Browser apps unaffected Browsers not supported Use native apps or combine with CA blocking controls
Token still reusable App not in supported list Only Teams/SharePoint/Exchange supported currently

Passwordless MFA Method Registration in Entra ID

Field

Details

Document Type

How-To Guide / Runbook

Applies To

Microsoft Entra ID, Microsoft 365, Windows 10/11, Web sign-ins

Audience

Entra ID / Microsoft 365 Administrators (2nd Line / Systems Admin)

Author

AK. Udofeh

Last Updated

March 2026
Overview

This document explains how to enable and configure passwordless authentication methods (Microsoft Authenticator phone sign-in, FIDO2 / Passkey security keys, and Windows Hello for Business) in Microsoft Entra ID, and how admins should guide users to register them. It is intended for Entra ID administrators responsible for identity security, MFA, and Conditional Access in Microsoft 365 environments.

Background

Basic steps that do not resolve the issue on their own:

Other affected services/systems:

Current setup
Desired End state 

  1. Admin enables passwordless authentication methods in Entra admin center > Protection > Authentication methods and targets appropriate groups.

  2. Users register Microsoft Authenticator phone sign-in, FIDO2 / Passkey security keys, or Windows Hello for Business via My Sign-ins or Windows enrolment flows.

  3. Conditional Access and authentication strengths can then require passwordless / phishing-resistant MFA for specific users and apps.

What currently missing:

Known triggers:

​Before You Start

Use this checklist before enabling passwordless methods.

Check Where
Confirm you have at least Authentication Administrator / Authentication Policy Administrator role Entra admin centre > Roles and administrators​
Ensure modern MFA is already in use (at least for admins) Entra admin centre > Protection > MFA or Conditional Access​
Identify break-glass / emergency access accounts and exclude them from strong requirements initially Entra admin centre > Users > Filter for emergency accounts​
Verify users have compatible devices (iOS/Android for Authenticator, Windows 10/11 for Hello, supported FIDO2 keys) Hardware/software inventory, Intune, or asset list
Communicate upcoming changes and registration steps to end users Internal IT communications plan​
Implementation Steps
1. Enable Microsoft Authenticator Passwordless Sign-in
  1. Sign in to https://entra.microsoft.com with an account that has Authentication Policy Administrator or Global Administrator role.
  2. Go to Entra ID > Authentication methods > Policies.​
  3. Select Microsoft Authenticator from the list of built-in methods.
  4. Set Enable to On.​
  5. Under Target, select All users or a dedicated pilot group (recommended initially). 

Be sure that at least two admins are in the pilot group.

     6. Confirm Authentication mode includes Passwordless sign-in (phone sign-in) as allowed.​

     7 Click Save.​

2. Enable FIDO2 / Passkey Security Keys

  1. In Authentication methods > Policies, select Passkey (FIDO2) (may appear as FIDO2 security key in some portals).

  2. Set Enable to On.​

  3. Under Target, select a pilot group or All users depending on readiness.

 Start with a small group if you have never deployed keys before.​

   4. Open the Configure tab and ensure Allow self-service setup is enabled so users can register keys at   

     https://mysignins.microsoft.com/security-info​

   5. (Optional but recommended) In the same Configure tab:

     6. Click Save.​

3. Configure Windows Hello for Business (if required)

  1. Confirm devices run Windows 10 version 1809+ or Windows 11 and are Entra-joined or hybrid-joined as per your design.

  2. Configure Windows Hello for Business via Intune device configuration or Group Policy according to Microsoft guidance (PIN and biometrics on devices with TPM).​

  3. Ensure Windows Hello for Business is enabled as an authentication method in Authentication methods > Policies and targeted to groups/devices that meet prerequisites.​

  4. For hybrid environments requiring on-prem sign-in with FIDO2, ensure you also follow passwordless security key sign-in to on-premises resources guidance.​

4. Instruct Users to Register Passwordless Methods

  1. Ask users in the pilot group to sign in to https://mysignins.microsoft.com/security-info​

  2. For Microsoft Authenticator phone sign-in:

    1. Install the Microsoft Authenticator app on iOS/Android.

    2. Add the work/school account and enable phone sign-in when prompted in the app.

  3. For FIDO2 / Passkey security keys:

    1. Users open Security info > Add sign-in method.

    2. Choose Security key and follow browser prompts to register the FIDO2 key (USB/NFC/Bluetooth).

  4. For Windows Hello for Business:

    1. During Windows out-of-box experience or after sign-in, users will be prompted or can go to Settings > Accounts > Sign-in options to configure PIN and biometric sign-in.​

  5. Confirm that at least two passwordless-capable methods are configured for each admin account where possible.​

5. Validate Sign-in Behaviour

  1. In a test browser, go to https://portal.office.com or https://portal.azure.com and initiate sign-in as a pilot user.​

  2. Verify that passwordless options (Authenticator notification number match, security key, or Windows Hello) are available and functioning.

  3. Check Entra admin centre > Protection > Authentication methods > Activity or sign-in logs to confirm passwordless usage.

Automated / Script Option (PowerShell for Policy Creation – Example for FIDO2)

This is an example script using Microsoft Graph PowerShell to enable FIDO2 (Passkey) for all users; adjust scoping for production.

# Connect to Microsoft Graph with appropriate scopesConnect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.AuthenticationMethod"# Get existing FIDO2 authentication method policy$fidoPolicy = Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `  -Filter "id eq 'Fido2'"# If the policy does not exist, throw an errorif (-not $fidoPolicy) {    throw "FIDO2 authentication method policy not found."}# Enable the FIDO2 policy and target all users$updateBody = @{    state  = "enabled"                       # Turn the method on    includeTargets = @(        @{            id   = "all_users"              # Target all users (adjust for groups if needed)            targetType = "group"            # TargetType can be group or user            isRegistrationRequired = $true  # Require registration        }    )}# Update the FIDO2 policyUpdate-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `  -AuthenticationMethodConfigurationId $fidoPolicy.Id `  -BodyParameter $updateBody# Output the updated policy to confirm changesGet-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `  -AuthenticationMethodConfigurationId $fidoPolicy.Id

Expected output / success indicators:

Script Breakdown
Troubleshooting

​Users do not see passwordless options at sign-in

FIDO2 key registration fails in the browser

Windows Hello for Business not offered

Graph script fails with permission/403 errors

Expected Outcome
Item Detail
Resolution time 30–90 minutes for tenant policy configuration, plus phased user enrolment over days/weeks
User impact Users see new sign-in experiences (Authenticator notification, FIDO2 key prompts, Windows Hello) and fewer password prompts
Recurrence risk Low once configured; periodic review needed for new apps, roles, and user groups​

Configure Phishing-Resistant MFA Policy in Entra ID

Field

Details

Document Type

How-To Guide / Runbook

Applies To

Microsoft Entra ID, Microsoft 365, Azure portals, Cloud Apps integrated with Entra ID

Audience

Entra ID / Security Administrators (2nd Line / Systems Admin / Security Ops)

Author

AK. Udofeh

Last Updated

March 2026
Overview

This document explains how to configure a phishing-resistant MFA Conditional Access policy using Authentication Strengths in Microsoft Entra ID. It covers report-only testing, scope control, and safe enforcement for privileged roles and high-value applications.

Background

Basic steps that do not resolve this:

Other affected services/systems:

Usecase
Desired End State

  1. Admins enable passwordless / phishing-resistant methods (Authenticator phone sign-in, FIDO2, etc.).

  2. Admins create Conditional Access policies that require Phishing-resistant MFA strength or Passwordless MFA strength for sensitive scenarios.

  3. Users in scope can satisfy the policy only with compliant strong methods; weaker methods are rejected.​

What currently breaks:

Known triggers:

Before You Start
Check Where
Confirm passwordless / phishing-resistant methods are configured and piloted (Authenticator phone sign-in, FIDO2, etc.) See the previous document and Entra > Protection > Authentication methods
Ensure you have break-glass accounts excluded from Conditional Access Entra admin centre > Users / Groups list​
Verify you have Conditional Access Administrator or equivalent permissions Entra admin centre > Roles and administrators​
Identify target scope (directory roles/groups/apps) and rollout phases Security design docs/identity architecture
Confirm security defaults or conflicting policies won’t block testing Entra > Protection > Conditional Access > Policies​
Implementation Steps 
1. Create a Report-Only Phishing-Resistant Policy

  1. Sign in to https://entra.microsoft.com as a Conditional Access or Security Administrator.

  2. Go to Entra ID > Conditional Access > Policies and select New policy.

  3. Name the policy clearly, for example: CA01 - Phishing-resistant MFA for Admins (Report-only).

  4. Under Assignments > Users, select Directory roles and choose roles such as Global Administrator, Security Administrator, Exchange Administrator, and other privileged roles. (Ensure to exclude break glass and service accounts)

  5. Under Cloud apps or actions, select All cloud apps or a subset of high-value apps (Exchange Online, SharePoint Online, Entra admin centre, Azure portal).

  6. Under Conditions, configure any additional conditions as needed (e.g. include all device platforms initially, or exclude trusted Workload identities).​

  7. Under Access controls > Grant, choose Require authentication strength and select Phishing-resistant MFA strength.​

  8. Set Enable policy to Report-only.

 This allows sign-ins to proceed but logs whether they would satisfy the policy.​

    9. Click Create to save the policy.​

2. Monitor Report-Only Results

  1. Allow at least some days of normal usage for covered users.

  2. In the Entra admin centre, go to Entra ID > Conditional Access > Insights and reporting and review the policy’s impact.​

  3. Use filters such as Policy not satisfied to identify sign-ins that would be blocked if enforced (e.g. users still using SMS).​

  4. Export reports for further analysis and plan user remediation or enrolment in passwordless methods where required.​

3. Create / Adjust Production Enforcement Policy

  1. Duplicate the tested report-only policy or create a new production policy with the same conditions.

  2. Under Assignments > Users, keep scope limited initially (e.g. only core admin roles or a pilot group).

Avoid tenant-wide enforcement until adoption is high.

    3. Under Assignments > Users > Exclude, add:

    4. Under Access controls > Grant, ensure Require authentication strength is set to Phishing-resistant MFA strength (or a custom

        strength including FIDO2, etc.).

     5. Set Enable policy to On.

     6. Save the policy and notify in-scope admins to use their phishing-resistant methods going forward.​

4. (Optional) Use Authentication Strength with Passwordless MFA
Automated / Script Option (Graph PowerShell Example)

Example policy that creates a report-only Conditional Access policy requiring phishing-resistant MFA strength for key admin roles.

# Connect to Microsoft Graph with appropriate scopes
Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess"

# Built-in Phishing-resistant MFA authentication strength ID
$phishResistantStrengthId = "00000000-0000-0000-0000-000000000004"

# Define key admin roles (template IDs)
$adminRoles = @(
    "62e90394-69f5-4237-9190-012177145e10", # Global Administrator
    "194ae4cb-b126-40b2-bd5b-6091b380977d", # Security Administrator
    "29232cdf-9323-42fd-ade2-1d097af3e4de"  # Exchange Administrator
)

# Build the Conditional Access policy body
$policyParams = @{
    DisplayName = "Require phishing-resistant MFA for admins (Report-only)"
    State       = "enabledForReportingButNotEnforced" # Report-only mode
    Conditions  = @{
        Users = @{
            IncludeRoles = $adminRoles             # Target listed directory roles
        }
        Applications = @{
            IncludeApplications = @("All")         # All cloud apps
        }
    }
    GrantControls = @{
        Operator = "OR"
        AuthenticationStrength = @{
            Id = $phishResistantStrengthId        # Built-in Phishing-resistant MFA strength
        }
    }
}

# Create the Conditional Access policy
New-MgIdentityConditionalAccessPolicy -BodyParameter $policyParams
Deployment notes:

Expected output / success indicators:

Script Breakdown
Troubleshooting

Users are blocked after policy enforcement

Policy does not appear to have any effect

Graph script fails with insufficient privileges

Conflicts with existing policies

Expected Outcome
Item Detail
Resolution time 30–60 minutes to create report-only and enforcement policies plus a 7–10 day observation window
User impact Privileged users and scoped users must use phishing-resistant or passwordless MFA methods to access targeted apps; legacy MFA may no longer be accepted
Recurrence risk Low once adopted; policies should be reviewed periodically as roles, apps, and methods evolve

How-To: Set Up App Registrations for Automated Entra ID Administration

Field

Details

Document Type

How-To Guide / Runbook

Applies To

Microsoft Entra ID, PowerShell, Microsoft Graph SDK

Audience

Systems Administrators / DevOps

Author

AK. Udofeh

Last Updated

April 2026
Overview
This article provides a structured guide on creating and configuring a Microsoft Entra ID App Registration. This setup allows for secure authentication from a local terminal or automated scripts to perform administrative tasks such as SSO configuration and directory management.
Background

To interact with Entra ID via automation or the command line without using personal user credentials, a Service Principal is required. Standard user accounts often have MFA or conditional access policies that interfere with headless automation; an App Registration provides a controlled, auditable, and secure method for programmatic access.

Before You Start
Check Where
Sufficient Permissions Ensure you have 'Application Developer' or 'Cloud Application Administrator' roles.
Microsoft Graph SDK Install the module: Install-Module Microsoft.Graph
Client Credentials Have a naming convention ready (e.g., Svc-Entra-Config).
Configuration Steps
  1. Register the Application:
    • Navigate to https://entra.microsoft.com> Entra ID > App Registrations > New Registration.
    • Enter a meaningful display name (e.g. AppName SSO).
    • Under Supported account types, select Accounts in this organisational directory only (Single tenant) unless multi-tenant access is required.
    • Leave the Redirect URI blank.
    • Click Register.
  2. Generate Credentials:
    • Go to Certificates & secrets > Client secrets.
    • Create a new secret.
    • Give it a description for future reference.

Copy the secret Value immediately; it will be masked permanently once you leave the blade.

     3. Configure API Permissions:

    • Go to API permissions > Add a permission > Microsoft Graph.
    • Select Application permissions.
    • Add Application.ReadWrite.All (for SSO/App config) and Directory.Read.All.
    • Select:, Grant admin consent for [Tenant].

    4.  Elevate via Directory Roles (Conditional):

Only perform this step if API permissions above result in "Access Denied" for specific administrative tasks.

Automated / Script Option - PowerShell
# Define connection variables
$TenantId = "your-tenant-id"
$ClientId = "your-client-id"
$ClientSecret = "your-client-secret" | ConvertTo-SecureString -AsPlainText -Force

# Create credential object for non-interactive login
$Credential = New-Object System.Management.Automation.PSCredential($ClientId, $ClientSecret)

# Connect to Microsoft Graph using the App Registration
# This uses the Client Credentials flow
Connect-MgGraph -TenantId $TenantId -Credential $Credential

# Success Indicator: Retrieve Tenant details to verify connection
Get-MgOrganization | Select-Object DisplayName, Id
Script Breakdown
Automated / Script Option - zsh
export ARM_CLIENT_ID="your-app-id"
export ARM_CLIENT_SECRET="your-app-password"
export ARM_SUBSCRIPTION_ID="your-sub-id"
export ARM_TENANT_ID="your-tenant-id"

 

Troubleshooting
Access Denied (403 Error)
Conflicting Authentication Context
Expected Outcome
Metric Detail
Resolution Time 10–15 Minutes
User Impact None (Backend configuration only)
Recurrence Risk Low (Credentials expire based on secret lifetime)

Blocking Device Code Flow in Microsoft Entra ID

Field

Details

Document Type

Blocking Device Code Flow in Microsoft Entra ID

Applies To

Microsoft Entra ID, Conditional Access policy

Audience

2nd Line / Entra ID Admins / IT Engineer

Author

AK. Udofeh

Last Updated

April 2026
Overview

Device Code Flow allows users to authenticate on one device by entering a code on another. While useful for devices with limited input, it introduces significant phishing risk and can enable access from unmanaged devices.

This guide walks through configuring a Conditional Access policy to block Device Code Flow.

Prerequisites
Step 1: Access Conditional Access Policies
  1. Sign in to the Microsoft Entra admin center
  2. Navigate to:
    Entra ID > Conditional Access > Policies
  3. Select + New policy
Step 2: Define Policy Scope

Users

Always maintain at least one account excluded to prevent lockout

Step 3: Target Resources
Step 4: Configure Authentication Flow Condition
  1. Navigate to:
    Conditions > Authentication Flows
  2. Set Configure = Yes
  3. Select:
    • Device Code Flow
  4. Click Done
Step 5: Block Access
  1. Go to:
    Access Controls > Grant
  2. Select:
    • Block access
  3. Click Select
Step 6: Enable in Report-Only Mode (Recommended)

This allows you to assess impact before enforcing

Step 7:  Validate Impact

Identify:

Step 8: Enforce Policy

Once validated:

Important Considerations

Microsoft recommends blocking unless explicitly required

Best Practices
Summary

Blocking Device Code Flow reduces exposure to phishing attacks that exploit cross-device authentication. This control strengthens identity security by eliminating a high-risk authentication path.

Blocking Authentication Transfer in Microsoft Entra ID

Field

Details

Document Type

Blocking Authentication Transfer in Microsoft Entra ID

Applies To

Microsoft Entra ID, Conditional Access policy

Audience

2nd Line / Entra ID Admins / IT Engineer

Author

AK. Udofeh

Last Updated

April 2026
Overview

Authentication Transfer allows a user to authenticate on one device and transfer that session to another (e.g. scanning a QR code to sign into a mobile app).

While convenient, it introduces risks where authentication can be extended to unmanaged or untrusted devices.

This guide shows how to restrict or block this behaviour using Conditional Access.

Prerequisites
Step 1: Access Conditional Access Policies
  1. Sign in to the Microsoft Entra admin center
  2. Navigate to:
    Entra ID > Conditional Access > Policies
  3. Select + New policy
Step 2: Define Policy Scope
Users

Exclusions should be tightly controlled and reviewed regularly

Step 3: Target Resources
Step 4:  Configure Authentication Flow Condition
  1. Navigate to:
    Conditions > Authentication Flows
  2. Set Configure = Yes
  3. Select:
    • Authentication Transfer
  4. Click Done
Step 5: Block Access
  1. Go to:
    Access Controls > Grant
  2. Select:
    • Block access
  3. Click Select
Step 6: Enable Policy
Step 7: Validate Behaviour
Important Considerations

Blocking Authentication Transfer may impact:

This feature is enabled by default and must be explicitly controlled via policy

Best Practices
Summary

Blocking Authentication Transfer prevents authentication from being silently extended across devices, reducing the risk of unauthorized access from unmanaged endpoints.

This ensures authentication remains tied to trusted and controlled environments.

Configuring Entra ID CA Policies for Authentication Flows

Field

Details

Document Type

Configuring Entra ID CA Policies for Authentication Flows

Applies To

Microsoft Entra ID, Conditional Access policy

Audience

2nd Line / Entra ID Admins / IT Engineer

Author

AK. Udofeh

Last Updated

May 2026
Overview

This guide outlines how to configure Conditional Access policies in Microsoft Entra ID to control:

 * Device Code Flow

 * Authentication Transfer

These authentication methods can introduce elevated phishing and unmanaged device risks if not explicitly governed.

Device Code Flow

Device Code Flow is similar to signing in to Netflix or Xbox on a Smart TV, where the TV displays a code and instructs the user to complete sign-in on another device such as a phone or laptop. Once authentication is completed, the Smart TV is automatically signed in.

Example:

Example: Go to https://microsoft.com/devicelogin or https://www.netflix.com/tv2 and enter this code.

Authentication Transfer

Authentication Transfer is similar to being signed in on Device A and then scanning a QR code using Device B, allowing the authenticated session or trust to be transferred so that Device B becomes signed in without performing a full standalone authentication process again.

This guide demonstrates how to govern these flows using Conditional Access policies to reduce exposure to indirect authentication attacks.

 Prerequisites

     *  Microsoft Entra ID P1 or higher

   * Conditional Access Administrator role

   * Emergency / break-glass accounts identified

   * Access to Microsoft Entra admin center

Step 1:  Create New Conditional Access Policy

1. Sign in to the Microsoft Entra admin center

2. Navigate to: Entra ID > Protection > Conditional Access > Policies

3. Select + New policy

4. Enter a policy name:

        *   Example: CA - Block Authentication Flows

Step 2: Configure User Scope

Under Assignments → Users:

       *  Include:

All users (recommended)

        * Exclude:

 * Emergency access accounts

 *  Break-glass administrator accounts

Avoid applying policies to all accounts without exclusions.

Step 3: Configure Target Resources

Under Assignments → Target resources:

*  Select:

     *. All cloud apps

This ensures consistent enforcement across Microsoft 365 resources.

Step 4: Configure Authentication Flows

1. Navigate to:
Conditions > Authentication flows

2. Set:

     *  Configure = Yes

1. Select required flows:

    * Device Code Flow

     * Authentication Transfer

2. Click Done

Step 5:  Configure Access Control

Under Access controls → Grant:

  * Select:

  * Block access

  * Click Select

This blocks authentication attempts using the selected flows.

Step 6: Enable Report-Only Mode

Before enforcement:

 *  Set policy state to:

 * Report-only

  * Click Create

This allows impact analysis without disrupting users.

Validation

Review:

*  Entra ID > Monitoring > Sign-in logs

Validate:

* Impacted users

* Authentication flow usage

* Conditional Access evaluation results

Monitor for:

* Developer tooling dependencies

* Shared device authentication

* QR-based onboarding scenarios

Enforcement

Once validated:

1. Edit the Conditional Access policy

2. Change:

*  Report-only > On

3. Continue monitoring sign-in activity and failures post-deployment.

️ Flow Overview

User Authentication Attempt
* Authentication Flow Detection
* Conditional Access Evaluation
* Block / Allow Decision
* Resource Access Outcome

Security Control Points:

· Device Code Flow restriction

· Authentication Transfer restriction

· Sign-in logging and monitoring

Summary

This configuration strengthens Microsoft Entra ID security posture by restricting high-risk authentication flows commonly associated with phishing and indirect access scenarios.