📋 Microsoft Entra Documentation Changes

## SMS and Voice Verification

For SMS and Voice verification, the following region codes require an opt-in. This means that if you'd like to use telecom in these regions, you'll have to reach out to support.

| 7 | Russia |

| 20 | Egypt |

| 27 | South Africa |

| 30 | Greece |

| 31 | Netherlands |

| 32 | Belgium |

| 36 | Hungary |

| 39 | Italy |

| 40 | Romania |

| 41 | Switzerland |

| 43 | Austria |

## Overview

Microsoft embeds specific identifiers in all access tokens that enable the correlation of activities back to a single root authentication event. These linkable identifiers are surfaced in customer-facing logs to support threat hunters and security analysts in investigating and mitigating identity-based attacks. By leveraging these identifiers, security professionals can more effectively trace, analyze, and respond to malicious activity across sessions and tokens, enhancing both the transparency and security of the environment.

There are two types of linkable identifiers used to to support advanced identity investigation and threat hunting scenarios:

**Session ID (SID)-Based Identifier**

The SID-based identifier enables correlation of all authentication artifacts such as [access token (AT)](/entra/identity-platform/access-tokens), [refresh token (RT)](/entra/identity-platform/refresh-tokens), and session cookies issued from a single root authentication event. This identifier is especially useful for tracking activity across a session.

Common SID-based investigation scenarios include:

- Correlating activity across services: Start with a session ID from Microsoft Entra sign-in logs and join it with workload logs (e.g., Exchange Online audit logs or Microsoft Graph activity logs) to identify all actions performed by access tokens sharing the same session ID.

- Filtering by user or device: Narrow results using UserId, DeviceId, or by filtering tokens issued within a specific session timeframe.

Session enumeration: Determine how many active sessions exist for a specific user (UserId) or device (DeviceId).

- The SID claim is generated during interactive authentication and included in the primary refresh token (PRT), refresh token, or session cookie. All access tokens issued from these sources inherit the same SID, enabling consistent linkage across authentication artifacts.

**Unique Token Identifier (UTI)**

title: Plan a Tenant Restrictions v1 Migration to Tenant Restrictions v2

description: Learn about tenant-level restrictions and controls for users, groups, and applications, along with policy management in a cloud-based portal.

Administrators use [tenant restrictions v1](~/identity/enterprise-apps/tenant-restrictions.md) to control user access to external tenants on their network. However, [tenant restrictions v2](tenant-restrictions-v2.md) with cross-tenant access settings adds tenant-level restrictions. Tenant restrictions v2 also adds more granularity, such as individual user, group, and application controls.

Tenant restrictions v2 moves policy management from network proxies to a cloud-based portal. Organizations no longer hit a maximum number of targeted tenants due to size limitations for proxy headers.

Migration from tenant restrictions v1 to tenant restrictions v2 is a one-time process with no other licensing requirements. As you plan the migration, include stakeholders from network and identity teams.

## Prerequisites

* Administrator access to proxies that inject the tenant restrictions v1 headers. Proxies can be on-premises or from a cloud-based service.

* [Microsoft Entra ID P1 or P2](~/fundamentals/get-started-premium.md) license.

* Verification of migration feasibility. See the [unsupported scenarios for tenant restrictions v2](tenant-restrictions-v2.md#unsupported-scenarios).

title: Use SSH to administer servers with Microsoft Entra Private Access

# Use SSH to administer remote servers

## Establish SSH connections with Microsoft Entra Private Access

Global Secure Access supports compliance across different regulated industries and global markets. This article lists the current certifications and updates as Global Secure Access acquires new certifications.

| [Canadian Privacy Laws](https://global.azure.com/auditmanager/certificates/views/cert/217) | Canadian privacy laws aim to protect the privacy of individuals and give them the right to access information gathered about them. These privacy laws include the Privacy Act, Personal Information Protection and Electronic Documents Act (PIPEDA), Alberta Personal Information Protection Act (PIPA), and British Columbia Freedom of Information and Protection of Privacy Act (BC FIPPA). For more information, see [Canadian Privacy Laws](/azure/compliance/offerings/offering-canada-privacy-laws). | [ISO 27001:2013](https://global.azure.com/auditmanager/certificates/views/cert/95) | |

| [CDSA](https://global.azure.com/auditmanager/certificates/views/cert/94) | The Content Delivery & Security Association (CDSA) Content Protection & Security (CPS) standard provides guidance and requirements for securing media assets within a Content Security Management System (CSMS). The standard includes controls to protect intellectual property and keep media assets secure and confidential throughout the digital media supply chain. For more information, see [Content Delivery & Security Association (CDSA) - Azure Compliance](/azure/compliance/offerings/offering-cdsa). | [ISO 27001:2013](https://global.azure.com/auditmanager/certificates/views/cert/95) | Certification available |

| [CSA STAR](https://global.azure.com/auditmanager/certificates/views/cert/132) | Cloud Security Alliance (CSA) STAR certification is based on achieving ISO 27001 certification and meeting criteria in the Cloud Controls Matrix (CCM). It shows that a cloud service provider meets ISO 27001 requirements, addresses key cloud security issues in the CCM, and is assessed against the STAR Capability Maturity Model for managing activities in CCM control areas. For more information, see [CSA STAR certification](/azure/compliance/offerings/offering-csa-star-certification). | [ISO 27001:2013](https://global.azure.com/auditmanager/certificates/views/cert/95) | |

| [DoD DISA SRG Level 2](https://global.azure.com/auditmanager/certificates/views/cert/122) | The Defense Information Systems Agency (DISA) is an agency of the US Department of Defense (DoD) that is responsible for developing and maintaining the DoD Cloud Computing Security Requirements Guide (SRG). The SRG defines the baseline security requirements used by DoD to assess the security posture of a cloud service provider (CSP), supporting the decision to grant a DoD Provisional Authorization (PA) that allows a CSP to host DoD missions. It incorporates, supersedes, and rescinds the previously published DoD Cloud Security Model (CSM). For more information, see [DoD DISA SRG Level 2](/azure/compliance/offerings/offering-dod-il2). | [FedRAMP High](https://global.azure.com/auditmanager/certificates/views/cert/139) | |

| [FedRAMP High](https://global.azure.com/auditmanager/certificates/views/cert/139) | The US Federal Risk and Authorization Management Program (FedRAMP) was established in December 2011 to provide a standardized approach for assessing, monitoring, and authorizing cloud service providers (CSPs). For more information, see [FedRAMP High](/azure/compliance/offerings/offering-fedramp). | NA | |

| [FIPS 140-2](https://global.azure.com/auditmanager/certificates/views/cert/147) | The Federal Information Processing Standard (FIPS) Publication 140-2 is a US government standard that defines minimum security requirements for cryptographic modules in products and systems. Validation against the FIPS 140-2 standard is required for all US federal government agencies that use cryptography-based security systems to protect sensitive but unclassified information stored digitally. For more information, see [FIPS 140-2](/azure/compliance/offerings/offering-fips-140-2). | [FedRAMP High](https://global.azure.com/auditmanager/certificates/views/cert/139) | |

| [GDPR](https://global.azure.com/auditmanager/certificates/views/cert/218) | The General Data Protection Regulation (GDPR) is a European privacy law that became effective in May 2018. It imposes new rules on organizations that offer goods and services to people in the European Union (EU) or that collect and analyze data belonging to EU individuals. The GDPR requires that data controllers, such as organizations using Azure, only use data processors, such as Microsoft, that provide sufficient guarantees to meet key requirements of the GDPR. For more information, see [GDPR](/compliance/regulatory/gdpr). | [ISO 27001:2013](https://global.azure.com/auditmanager/certificates/views/cert/95) | |

| [GxP (FDA 21 CFR Part 11)](https://global.azure.com/auditmanager/certificates/views/cert/156) | Azure can help customers meet their requirements under Good Clinical, Laboratory, and Manufacturing Practices (GxP), as well as regulations enforced by the US Food and Drug Administration (FDA) under 21 CFR Part 11. For more information, see [GxP (FDA 21 CFR Part 11)](/azure/compliance/offerings/offering-gxp). | [ISO 27001:2013](https://global.azure.com/auditmanager/certificates/views/cert/95) | |

| [HDS (France)](https://global.azure.com/auditmanager/certificates/views/cert/209) | Microsoft Azure has the Health Data Hosting (Hébergeurs de Données de Santé, HDS) certification, which is required for all entities that host personal health data governed by French law. Microsoft is the first major cloud service provider to meet the strict French standards for storing and processing health data. For more information, see [HDS (France)](/compliance/regulatory/offering-hds-france). | [ISO 27001:2013](https://global.azure.com/auditmanager/certificates/views/cert/95) | |

title: Microsoft single sign-on For Linux

ms.date: 05/16/2025

# What is Microsoft Single Sign-on to Linux?

Microsoft Single Sign-on (SSO) for Linux is powered by a software component that can be installed onto a Linux device that integrates with Microsoft Entra ID. Microsoft SSO for Linux enable users to use their Microsoft Entra ID credentials to sign-in to other apps without being prompted for credentials each time a resource is accessed. This feature provides benefits for admins by simplifying the sign-in process for users and reducing the number of passwords they need to remember.

This feature empowers users on Linux desktop clients to register their devices with Microsoft Entra ID, enroll into Intune management, and satisfy device-based conditional access policies when accessing their corporate resources.

- [Migrating users to Microsoft Entra External ID](customers/how-to-migrate-users.md)

- [Customize the language of the authentication experience](customers/how-to-customize-languages-customers.md) - Editorial updates

- [Add OpenID Connect as an external identity provider](customers/how-to-custom-oidc-federation-customers.md) - OpenID Connect federation is generally available

- [Add Facebook as an identity provider](customers/how-to-facebook-federation-customers.md) - Facebook federation is generally available

- [Add Google as an identity provider](customers/how-to-google-federation-customers.md) - Google federation is generally available

- [Create a sign-up and sign-in user flow for an external tenant app](customers/how-to-user-flow-sign-up-sign-in-customers.md) - Removed disable sign-up in a sign-up and sign-in user flow

- [Add and manage admin accounts](customers/how-to-manage-admin-accounts.md) - Added clarification

- [Manage user accounts for consumers and business customers](customers/how-to-manage-customer-accounts.md) - Added clarification

- [Default user permissions in external tenants](customers/reference-user-permissions.md) - Updated default permissions

- [Supported features in workforce and external tenants](customers/concept-supported-features-customers.md) - Added default permissions

You can scope tenant restrictions v2 to specific users, groups, organizations, or external apps. Apps built on the networking stack for the Windows operating system are protected. The following scenarios are supported:

> Tenant restrictions v1 and v2 on the proxy require decryption of requests to sign-in URLs such as login.microsoftonline.com. Microsoft supports the decryption of traffic for those sign-in domains for the purpose of header insertion for tenant restrictions. This decryption is a valid exception to the policies at [Use third-party network devices or solutions with Microsoft 365](/microsoft-365/troubleshoot/miscellaneous/office-365-third-party-network-devices).

- [Conditional Access: Allow use of only managed or compliant devices](/mem/intune/protect/conditional-access-intune-common-ways-use#device-based-conditional-access)

- [Conditional Access: Manage access for guest or external users](/microsoft-365/security/office-365-security/identity-access-policies-guest-access)

ms.date: 05/14/2025

- [Certificate](#certificate) (for confidential client applications)

- [Federated credentials](#federated-credentials) (for confidential client applications)

MSAL.NET throws an explicit exception if both `Instance` and `AzureCloudInstance` are specified.

## Platform and browser support

 

Microsoft Entra terms of use is designed to function optimally on the following platforms and browsers.

 

Supported desktop and mobile operating systems (latest stable versions):

1. Windows

1. macOS

1. Linux

1. Android

1. iOS

Supported modern web browsers (latest stable versions):

1. Microsoft Edge

1. Mozilla Firefox

1. Google Chrome

1. Safari

 

# Turn on universal tenant restrictions

| **1** | Contoso configures a tenant restrictions v2 policy in its cross-tenant access settings to block all external accounts and external apps. Contoso enforces the policy by using Global Secure Access and universal tenant restrictions. |

| **2** | A user with a Contoso-managed device tries to access a Microsoft Entra-integrated app with an unsanctioned external identity. |

- They work with all Microsoft Entra-integrated third-party apps at the authentication plane during sign-in.

title: What's new in Microsoft Single Sign-on for Linux

description: Discusses new feature releases of Microsoft Single Sign-on for Linux

ms.service: entra-id

ms.topic: whats-new

ms.date: 05/16/2025

ms.subservice: devices

Microsoft uses the following package repositories to distribute the Microsoft Identity Broker and Microsoft Identity Diagnostics for Linux. Packages are available in either `.deb` or `.rpm` format, however only Ubuntu Long-Term Support (LTS) & Red Hat Enterprise Linux (LTS) are supported today.

ms.date: 05/14/2025

Access tokens are a type of security token designed for authorization, granting access to specific resources on behalf on an authenticated user. Information in access tokens determines whether a user has the right to access a particular resource, similar to keys unlocking specific doors in a building. These individual pieces of information that make up tokens are called claims. Therefore, they are sensitive credentials and pose a security risk if not handled correctly. Access tokens differ from [ID tokens](./id-tokens.md) which serve as proof of authentication.

Access tokens enable clients to securely call protected web APIs. Although client applications can receive and use access tokens, they should be treated as opaque strings. The client application shouldn't attempt to validate access tokens. The resource server should validate the access token before accepting it as proof of authorization. The contents of the token are intended only for the API, which means that access tokens must be treated as opaque strings. For validation and debugging purposes *only*, developers can decode JWTs using a site like [jwt.ms](https://jwt.ms). Tokens that a Microsoft API receives might not always be a JWT that can be decoded.

If none of the previously described scenarios apply, there's no need to validate the token. Public clients like native, desktop, or single-page applications don't benefit from validating ID tokens because the application communicates directly with the IDP where SSL protection ensures the ID tokens are valid. They shouldn't validate the access tokens, as they are for the web API to validate, not the client.

In the source tenant: Each user who is synchronized with cross-tenant synchronization must have a Microsoft Entra ID P1 license in their home/source tenant. Each user who is synchronized with cross-cloud synchronization must have a Microsoft Entra ID Governance or Microsoft Entra Suite license in their home/source tenant. For more information, see [Compare generally available features of Microsoft Entra ID](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing) or [Microsoft Entra ID Governance licensing fundamentals](../../id-governance/licensing-fundamentals.md).

 

In the target tenant: Licenses aren't required for cross-tenant synchronization or cross-cloud synchronization in the target tenant. However, depending on the features you are using in the target tenant, you might need additional licensing. For example, if you have Microsoft Entra External ID billing enabled, you might get charged for external guests. To understand the external identities licensing model, see [MAU billing model for Microsoft Entra External ID](../../external-id/external-identities-pricing.md).

 

ms.date: 05/14/2025

* An Azure account with an active subscription. If you don't have one, [create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

* An application registered in the [Microsoft Entra admin center](https://entra.microsoft.com/). If you don't have one, [register an application](quickstart-register-app.md#register-an-application) now.

> Ensure that an owner is assigned to both the API application and the application you want to add permissions to, otherwise the API will not be listed when requesting API permissions.