📋 Microsoft Entra Documentation Changes

Daily summary for changes since May 19th 2026, 11:19 PM PDT

Report generated on May 20th 2026, 11:19 PM PDT

📊 Summary

19
Total Commits
0
New Files
6
Modified Files
0
Deleted Files
11
Contributors

📝 Modified Documentation Files

MODIFIED docs/identity/authentication/how-to-mfa-registration-campaign.md
Modified by Justinha on May 20, 2026 3:28 PM
📖 View on learn.microsoft.com
+7 / -3 lines changed
Commit: Add note about snooze count persistence in registration campaign
Changes:
Before
After
title: Run a registration campaign to set up passkey or Microsoft Authenticator
description: Learn how to run a registration campaign in Microsoft Entra ID to nudge users toward passkeys or Microsoft Authenticator for stronger sign-in security.
ms.topic: how-to
ms.date: 05/04/2026
author: justinha
ms.reviewer: marisanchez
ai-usage: ai-assisted
 
Registration campaigns support two authentication methods:
 
 
- **Passkey (FIDO2)** — Nudge users to register a passkey, which includes both synced passkeys and device-bound passkeys.
- - **Microsoft Authenticator** — Nudge users to download and set up the Authenticator app for push notifications.
 
> [!NOTE]
> A registration campaign can only target one authentication method at a time. You can't run campaigns for both Microsoft Authenticator and passkeys simultaneously in the same tenant.
If the registration campaign state is set to **Enabled**, you can configure the experience for end users by using **Limited number of snoozes**:
- If **Limited number of snoozes** is Enabled, users can skip the interrupt prompt 3 times, after which they're forced to register the targeted authentication method.
- If **Limited number of snoozes** is Disabled, users can snooze an unlimited number of times and avoid registration.
title: Run a registration campaign to set up passkey or Microsoft Authenticator
description: Learn how to run a registration campaign in Microsoft Entra ID to nudge users toward passkeys or Microsoft Authenticator for stronger sign-in security.
ms.topic: how-to
ms.date: 05/20/2026
author: justinha
ms.reviewer: marisanchez
ai-usage: ai-assisted
 
Registration campaigns support two authentication methods:
 
- **Passkey (FIDO2)** — Nudge users to register a passkey, which includes both synced passkeys and device-bound passkeys.
- **Microsoft Authenticator** — Nudge users to download and set up the Authenticator app for push notifications.
 
> [!NOTE]
> A registration campaign can only target one authentication method at a time. You can't run campaigns for both Microsoft Authenticator and passkeys simultaneously in the same tenant.
If the registration campaign state is set to **Enabled**, you can configure the experience for end users by using **Limited number of snoozes**:
- If **Limited number of snoozes** is Enabled, users can skip the interrupt prompt 3 times, after which they're forced to register the targeted authentication method.
- If **Limited number of snoozes** is Disabled, users can snooze an unlimited number of times and avoid registration.
 
> [!NOTE]
MODIFIED docs/identity-platform/tutorial-native-authentication-android-custom-headers.md
Modified by henrymbuguakiarie on May 20, 2026 4:07 PM
📖 View on learn.microsoft.com
+4 / -4 lines changed
Commit: Change native auth to native authentication
Changes:
Before
After
---
title: Add custom headers to native auth requests in Android (Kotlin)
description: Learn how to attach custom x-* headers to native auth network requests in an Android (Kotlin) app to integrate fraud-detection SDKs with Microsoft Entra External ID.
author: henrymbuguakiarie
manager: pmwongera
 
ms.custom: msecd-doc-authoring-105
ms.date: 05/15/2026
ai-usage: ai-assisted
#Customer intent: As an Android developer, I want to attach custom headers to native auth network requests so that I can integrate fraud and bot-detection SDKs with my Microsoft Entra External ID app.
---
 
# Tutorial: Add custom headers to native auth network requests in Android (Kotlin)
 
[!INCLUDE [applies-to-external-only](../external-id/includes/applies-to-external-only.md)]
 
---
title: Add custom headers to native authentication requests in Android (Kotlin)
description: Learn how to attach custom x-* headers to native authentication network requests in an Android (Kotlin) app to integrate fraud-detection SDKs with Microsoft Entra External ID.
author: henrymbuguakiarie
manager: pmwongera
 
ms.custom: msecd-doc-authoring-105
ms.date: 05/15/2026
ai-usage: ai-assisted
#Customer intent: As an Android developer, I want to attach custom headers to native authentication network requests so that I can integrate fraud and bot-detection SDKs with my Microsoft Entra External ID app.
---
 
# Tutorial: Add custom headers to native authentication network requests in Android (Kotlin)
 
[!INCLUDE [applies-to-external-only](../external-id/includes/applies-to-external-only.md)]
 
MODIFIED docs/identity-platform/tutorial-native-authentication-ios-swift-custom-headers.md
Modified by henrymbuguakiarie on May 20, 2026 4:07 PM
📖 View on learn.microsoft.com
+4 / -4 lines changed
Commit: Change native auth to native authentication
Changes:
Before
After
---
title: Add custom headers to native auth network requests in iOS (Swift)
description: Learn how to attach custom x-* headers to native auth network requests in an iOS (Swift) app to integrate fraud-detection SDKs with Microsoft Entra External ID.
author: henrymbuguakiarie
manager: pmwongera
 
ms.custom: msecd-doc-authoring-105
ms.date: 04/29/2026
ai-usage: ai-assisted
#Customer intent: As an iOS developer, I want to attach custom headers to native auth network requests so that I can integrate fraud and bot-detection SDKs with my Microsoft Entra External ID app.
---
 
# Tutorial: Add custom headers to native auth network requests in iOS (Swift)
 
[!INCLUDE [applies-to-external-only](../external-id/includes/applies-to-external-only.md)]
 
---
title: Add custom headers to native authentication network requests in iOS (Swift)
description: Learn how to attach custom x-* headers to native authentication network requests in an iOS (Swift) app to integrate fraud-detection SDKs with Microsoft Entra External ID.
author: henrymbuguakiarie
manager: pmwongera
 
ms.custom: msecd-doc-authoring-105
ms.date: 04/29/2026
ai-usage: ai-assisted
#Customer intent: As an iOS developer, I want to attach custom headers to native authentication network requests so that I can integrate fraud and bot-detection SDKs with my Microsoft Entra External ID app.
---
 
# Tutorial: Add custom headers to native authentication network requests in iOS (Swift)
 
[!INCLUDE [applies-to-external-only](../external-id/includes/applies-to-external-only.md)]
 
MODIFIED docs/external-id/customers/how-to-user-flow-sign-up-sign-in-customers.md
Modified by garrodonnell on May 20, 2026 1:33 PM
📖 View on learn.microsoft.com
+4 / -2 lines changed
Commit: Clarify 'Stay signed in?' prompt context (branding/MFA don't suppress it)
Changes:
Before
After
 
## Control the 'Stay signed in?' prompt
 
By default, after a customer signs in to an app that uses your user flow, they see a **Stay signed in?** prompt. The prompt appears regardless of whether the user flow is branded or whether multifactor authentication is required. If the user selects **Yes**, a persistent authentication cookie is issued and they remain signed in across browser sessions. If they select **No**, a non-persistent cookie is issued.
 
This prompt isn't a user flow setting. To change or suppress it, configure the **Persistent browser session** session control in a Conditional Access policy that targets your customers and apps:
 
- **Always persistent**: The browser session is always persisted. The **Stay signed in?** prompt isn't shown.
- **Never persistent**: The browser session ends when the browser is closed. The **Stay signed in?** prompt isn't shown.
 
 
 
## Control the 'Stay signed in?' prompt
 
By default, after a customer signs in to an app that uses your user flow, they see a **Stay signed in?** prompt asking whether to stay signed in across browser sessions. If the user selects **Yes**, a persistent authentication cookie is issued and they remain signed in across browser sessions. If they select **No**, a non-persistent cookie is issued.
 
This prompt is the default behavior for every user flow. Applying custom branding to the user flow or requiring multifactor authentication doesn't change whether the prompt appears. It's shown in all cases unless you override it with a Conditional Access policy.
 
The prompt isn't a user flow setting. To change or suppress it, configure the **Persistent browser session** session control in a Conditional Access policy that targets your customers and apps:
 
- **Always persistent**: The browser session is always persisted. The **Stay signed in?** prompt isn't shown.
- **Never persistent**: The browser session ends when the browser is closed. The **Stay signed in?** prompt isn't shown.
MODIFIED docs/external-id/direct-federation.md
Modified by vimrang on May 20, 2026 8:49 PM
📖 View on learn.microsoft.com
+1 / -1 lines changed
Commit: Update Domainless description in direct-federation.md
Changes:
Before
After
1. On the **New SAML/WS-Fed IdP** page, enter the following:
- **Display name** - Enter a name to help you identify the partner's IdP.
- **Identity provider protocol** - Select **SAML** or **WS-Fed**.
- **Domainless** - Selecting **Domainless** enforces no domain check of the user's email address. For more details, see [Domainless SAML IdP federation](./direct-federation.md#domainless-saml-idp-federation).
- **Domain name of federating IdP** - Enter your partner’s IdP target domain name for federation. During this initial configuration, enter just one domain name. You can add more domains later.
 
:::image type="content" source="media/direct-federation/new-saml-wsfed-idp-parse.png" alt-text="Screenshot showing the new SAML or WS-Fed IdP page.":::
1. On the **New SAML/WS-Fed IdP** page, enter the following:
- **Display name** - Enter a name to help you identify the partner's IdP.
- **Identity provider protocol** - Select **SAML** or **WS-Fed**.
- **Domainless** - Selecting **Domainless** enforces no domain check of the user's email address. For more details, see [Domainless SAML IdP federation](./direct-federation.md#domainless-saml-idp-federation-preview).
- **Domain name of federating IdP** - Enter your partner’s IdP target domain name for federation. During this initial configuration, enter just one domain name. You can add more domains later.
 
:::image type="content" source="media/direct-federation/new-saml-wsfed-idp-parse.png" alt-text="Screenshot showing the new SAML or WS-Fed IdP page.":::
MODIFIED docs/identity/saas-apps/samsara-tutorial.md
Modified by Regan Downer on May 20, 2026 3:34 PM
📖 View on learn.microsoft.com
+1 / -1 lines changed
Commit: Apply suggestion from @v-regandowner
Changes:
Before
After
b. Copy the link from Post-back/ACS URL field in Samsara into the **Reply URL** text box in Entra ID.
 
> [!NOTE]
> Update these values with the actual Reply URL and Identifier. Contact the [Samsara Client support team](mailto:[email protected]) to get these values, or in Samsara, go to **Settings** > **Single-Sign-On** and select the connection you want to create in order to obtain the right ACS and Identifier URLs.
 
1. On the **Set-up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find and copy the **App Federation Metadata URL** or download the **Federation Metadata XML**. In the Samsara dashboard in Settings > Single Sign-on in the relevant SSO configuration (user or driver), paste the metadata URL or upload the file. Click **Save** to apply the changes.
 
b. Copy the link from Post-back/ACS URL field in Samsara into the **Reply URL** text box in Entra ID.
 
> [!NOTE]
> Update these values with the actual Reply URL and Identifier. Contact the [Samsara Client support team](mailto:[email protected]) to get these values, or in Samsara, go to **Settings** > **single-sign-on** and select the connection you want to create in order to obtain the right ACS and Identifier URLs.
 
1. On the **Set-up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find and copy the **App Federation Metadata URL** or download the **Federation Metadata XML**. In the Samsara dashboard in Settings > Single Sign-on in the relevant SSO configuration (user or driver), paste the metadata URL or upload the file. Click **Save** to apply the changes.
 

🤖 This report was automatically generated by the Entra Docs Monitor

📧 Delivered to [email protected]

🔗 Visit Repository