đź“‹ Microsoft Entra Documentation Changes

Daily summary for changes since March 15th 2026, 9:25 PM PDT

Report generated on March 16th 2026, 9:25 PM PDT

📊 Summary

68
Total Commits
0
New Files
47
Modified Files
0
Deleted Files
16
Contributors

📝 Modified Documentation Files

Modified by Ken Withee on Mar 16, 2026 8:58 PM
đź“– View on learn.microsoft.com
+43 / -43 lines changed
Commit: Editorial pass: using-facecheck.md (49 fixes)
Changes:
Before
After
---
title: Tutorial - Using Face Check with Microsoft Entra Verified ID and unlocking high assurance verifications at scale
description: In this tutorial, you learn how to use Face Check with Microsoft Entra Verified ID.
ms.topic: tutorial
ms.date: 04/30/2025
# Customer intent: As an enterprise, we want to enable customers to manage information about themselves by using verifiable credentials.
---
 
# Using Face Check with Microsoft Entra Verified ID and unlocking high assurance verifications at scale
 
Face Check is a privacy-respecting facial matching. It allows enterprises to perform high-assurance verifications securely, simply, and at scale. Face Check adds a critical layer of trust by performing facial matching between a user’s real-time selfie and a photo. The facial matching is powered by Azure AI services. Face Check protects user privacy by sharing only the match results and not any sensitive identity data, while allowing organizations to be sure the person claiming an identity is really them.
 
 
Face Check is a premium feature within Verified ID. You need to enable the Face Check Add-on in your Microsoft Entra Verified ID setup before doing Face Check verifications.
 
- Make sure Microsoft Entra Verified ID is [setup in your tenant](verifiable-credentials-configure-tenant-quick.md) before using Face Check.
- [Associate or add an Azure subscription to your Microsoft Entra tenant](/entra/fundamentals/how-subscriptions-associated-directory)
- Make sure the user setting up Face Check has [Contributor role for the Azure subscription](/azure/role-based-access-control/built-in-roles/general#contributor)
 
## Setting up Face Check with Microsoft Entra Verified ID
---
title: Tutorial - Use Face Check with Microsoft Entra Verified ID and unlocking high assurance verifications at scale
description: In this tutorial, you learn how to use Face Check with Microsoft Entra Verified ID.
ms.topic: tutorial
ms.date: 04/30/2025
# Customer intent: As an enterprise, we want to enable customers to manage information about themselves by using verifiable credentials.
---
 
# Use Face Check with Microsoft Entra Verified ID and unlocking high assurance verifications at scale
 
Face Check is a privacy-respecting facial matching. It allows enterprises to perform high-assurance verifications securely, simply, and at scale. Face Check adds a critical layer of trust by performing facial matching between a user’s real-time selfie and a photo. The facial matching is powered by Azure AI services. Face Check protects user privacy by sharing only the match results and not any sensitive identity data, while allowing organizations to be sure the person claiming an identity is really them.
 
 
Face Check is a premium feature within Verified ID. You need to enable the Face Check Add-on in your Microsoft Entra Verified ID setup before doing Face Check verifications.
 
- Make sure Microsoft Entra Verified ID is [set up in your tenant](verifiable-credentials-configure-tenant-quick.md) before using Face Check.
- [Associate or add an Azure subscription to your Microsoft Entra tenant](/entra/fundamentals/how-subscriptions-associated-directory)
- Make sure the user setting up Face Check has [Contributor role for the Azure subscription](/azure/role-based-access-control/built-in-roles/general#contributor)
 
## Set up Face Check with Microsoft Entra Verified ID
Modified by Ken Withee on Mar 16, 2026 8:58 PM
đź“– View on learn.microsoft.com
+42 / -39 lines changed
Commit: Editorial pass: admin-api.md (38 fixes)
Changes:
Before
After
 
# Verifiable credentials admin API
 
The Microsoft Entra Verified ID Admin API enables you to manage all aspects of the Verifiable Credential service. It offers a way to set up a brand new service, manage and create Verifiable Credential contracts, revoke Verifiable Credentials and completely opt out the service as well.
 
> [!NOTE]
> The API is intended for developers comfortable with RESTful APIs and enough permissions on the Microsoft Entra tenant to enable the service.
 
## Base URL
 
The Admin API is server over HTTPS. All URLs referenced in the documentation have the following base: `https://verifiedid.did.msidentity.com`.
 
## Authentication
 
 
The app registration needs to have the API Permission for `Verifiable Credentials Service Admin` and permissions required from the table. When an app acquires an access token, via the [client credentials flow](~/identity-platform/v2-oauth2-client-creds-grant-flow.md), the app should use scope `6a8b4b39-c021-437c-b060-5a14a3fd65f3/.default`.
 
If the app intends to create a new authority, it needs two things. First, the app registration needs the `VerifiableCredential.Authority.ReadWrite` permission. Second, the app needs have `Create Key` permission in Key Vaults Access Policies. If the app only read/writes existing authorities, it doesn't need the Key Vault permission.
 
## Onboarding
 
# Verifiable credentials admin API
 
The Microsoft Entra Verified ID Admin API enables you to manage all aspects of the Verifiable Credential service. It offers a way to set up a brand new service, manage and create Verifiable Credential contracts, revoke Verifiable Credentials, and completely opt out of the service.
 
> [!NOTE]
> The API is intended for developers comfortable with RESTful APIs and enough permissions on the Microsoft Entra tenant to enable the service.
 
## Base URL
 
The Admin API is served over HTTPS. All URLs referenced in the documentation have the following base: `https://verifiedid.did.msidentity.com`.
 
## Authentication
 
 
The app registration needs to have the API Permission for `Verifiable Credentials Service Admin` and permissions required from the table. When an app acquires an access token, via the [client credentials flow](~/identity-platform/v2-oauth2-client-creds-grant-flow.md), the app should use scope `6a8b4b39-c021-437c-b060-5a14a3fd65f3/.default`.
 
If the app intends to create a new authority, it needs two things. First, the app registration needs the `VerifiableCredential.Authority.ReadWrite` permission. Second, the app needs to have `Create Key` permission in Key Vaults Access Policies. If the app only read/writes existing authorities, it doesn't need the Key Vault permission.
 
## Onboarding
Modified by Justin Ploegert on Mar 16, 2026 5:13 PM
đź“– View on learn.microsoft.com
+22 / -45 lines changed
Commit: Learn Editor: Update whats-new-linux.md
Changes:
Before
After
 
This article provides information about the latest updates to Microsoft single sign-on for Linux.
 
### Package Repositories
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.
 
#### [Ubuntu20.04](#tab/ubuntu2004)
 
- [microsoft-identity-broker](https://packages.microsoft.com/ubuntu/20.04/prod/pool/main/m/msft-identity-broker/)
 
#### [Ubuntu22.04](#tab/ubuntu2204)
 
- [microsoft-identity-broker](https://packages.microsoft.com/ubuntu/22.04/prod/pool/main/m/microsoft-identity-broker/)
- [microsoft-identity-diagnostics](https://packages.microsoft.com/ubuntu/22.04/prod/pool/main/m/microsoft-identity-diagnostics/)
 
#### [Ubuntu24.04](#tab/ubuntu2404)
 
- [microsoft-identity-broker](https://packages.microsoft.com/ubuntu/24.04/prod/pool/main/m/microsoft-identity-broker/)
- [microsoft-identity-diagnostics](https://packages.microsoft.com/ubuntu/24.04/prod/pool/main/m/microsoft-identity-diagnostics/)
 
 
This article provides information about the latest updates to Microsoft single sign-on for Linux.
 
## Microsoft-Identity-Broker - Version Lifecycle and Support Matrix
 
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.
 
|Major Version |Primary Purpose|Latest Version| Supported| Source|
| --------|--------------| -------- |---------------------|--------------|
Add the Microsoft repository.
 
```bash
# Legacy key (needed for Edge)
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
# Key for RHEL 10 packages
sudo rpm --import https://packages.microsoft.com/rhel/10/insiders-fast/repodata/repomd.xml.key
 
sudo dnf install -y dnf-plugins-core
 
Modified by Ken Withee on Mar 16, 2026 8:59 PM
đź“– View on learn.microsoft.com
+32 / -32 lines changed
Commit: Editorial pass: planning and overview articles (52 fixes)
Changes:
Before
After
 
- Entra Verified ID is supported on Microsoft GCC environments.
>[!NOTE]
> This is GCC only and not GCC High.
 
- Updates to the IDV Partner Gallery
 
## June 2024
 
- [FaceCheck](using-facecheck.md) introducing the Face Check Addon as an incremental update to the Face Check public preview. Face Check is a premium feature within Microsoft Entra Verified ID free to use during the public preview period ending on August 12.
 
## April 2024
 
- [Quick setup](verifiable-credentials-configure-tenant-quick.md) Generally available, it enables an admin to onboard Microsoft Entra Verified ID in a Microsoft Entra tenant with just one select of a button.
 
## March 2024
 
 
## February 2024
 
- Entra Verified ID is supported on Microsoft GCC environments.
> [!NOTE]
> This is GCC only and not GCC High.
 
- Updates to the IDV Partner Gallery
 
## June 2024
 
- [FaceCheck](using-facecheck.md) introduces the Face Check Addon as an incremental update to the Face Check public preview. Face Check is a premium feature within Microsoft Entra Verified ID free to use during the public preview period ending on August 12.
 
## April 2024
 
- [Quick setup](verifiable-credentials-configure-tenant-quick.md) is now generally available. It enables an admin to onboard Microsoft Entra Verified ID in a Microsoft Entra tenant with just one select of a button.
 
## March 2024
 
 
## February 2024
Modified by Ken Withee on Mar 16, 2026 8:59 PM
đź“– View on learn.microsoft.com
+27 / -27 lines changed
Commit: Editorial pass: planning and overview articles (52 fixes)
Changes:
Before
After
 
Microsoft’s Microsoft Entra Verified ID (Microsoft Entra VC) service enables you to trust proofs of user identity without expanding your trust boundary. With Microsoft Entra VC, you create accounts or federate with another identity provider. When a solution implements a verification exchange using verifiable credentials, it enables applications to request credentials that aren't bound to a specific domain. This approach makes it easier to request and verify credentials at scale.
 
If you haven’t already, we suggest you review the [Microsoft Entra Verified ID architecture overview](introduction-to-verifiable-credentials-architecture.md). You also want to review [Plan your Microsoft Entra Verified ID issuance solution](plan-issuance-solution.md).
 
## Scope of guidance
 
 
Supporting technologies that aren't specific to verification solutions are out of scope. For example, websites are used in a verifiable credential verification solution but planning a website deployment isn't covered in detail.
 
As you plan your verification solution, you must consider what business capability is being added or modified. You must also consider what IT capabilities can be reused, and what capabilities must be added to create the solution. Also consider what training is needed for the people involved in the business process and the people that support the end users and staff of the solution. These articles aren't covered in this content. We recommend reviewing the [Microsoft Azure Well-Architected Framework](/azure/well-architected/) for information covering these articles.
 
## Components of the solution
 
 
:::image type="content" source="./media/plan-verification-solution/plan-verification-solution-key-vault.png" alt-text="Diagram of the components of a verification solution with Azure Key Vault highlighted.":::
 
The Azure Key Vault service stores your verifier keys, which are generated when you enable the Microsoft Entra Verified ID issuance service. The keys are used to provide message security. Each verifier has a single key set used for signing, updating, and recovering VCs. Verified ID uses this key set each time you service a verification request. Microsoft key set currently uses Elliptic Curve Cryptography (ECC) [SECP256k1](https://en.bitcoin.it/wiki/Secp256k1). We're exploring other cryptographic signature schemas that are adopted by the broader DID community.
 
### Request Service API
 
Microsoft’s Microsoft Entra Verified ID (Microsoft Entra VC) service enables you to trust proofs of user identity without expanding your trust boundary. With Microsoft Entra VC, you create accounts or federate with another identity provider. When a solution implements a verification exchange using verifiable credentials, it enables applications to request credentials that aren't bound to a specific domain. This approach makes it easier to request and verify credentials at scale.
 
If you haven’t already, review the [Microsoft Entra Verified ID architecture overview](introduction-to-verifiable-credentials-architecture.md). Also review [Plan your Microsoft Entra Verified ID issuance solution](plan-issuance-solution.md).
 
## Scope of guidance
 
 
Supporting technologies that aren't specific to verification solutions are out of scope. For example, websites are used in a verifiable credential verification solution but planning a website deployment isn't covered in detail.
 
As you plan your verification solution, you must consider what business capability is being added or modified. You must also consider what IT capabilities can be reused, and what capabilities must be added to create the solution. Also consider what training is needed for the people involved in the business process and the people that support the end users and staff of the solution. These topics aren't covered in this content. For more information, review the [Microsoft Azure Well-Architected Framework](/azure/well-architected/).
 
## Components of the solution
 
 
:::image type="content" source="./media/plan-verification-solution/plan-verification-solution-key-vault.png" alt-text="Diagram of the components of a verification solution with Azure Key Vault highlighted.":::
 
The Azure Key Vault service stores your verifier keys, which are generated when you enable the Microsoft Entra Verified ID issuance service. The keys are used to provide message security. Each verifier has a single key set used for signing, updating, and recovering VCs. Verified ID uses this key set each time you service a verification request. Microsoft key set currently uses Elliptic Curve Cryptography (ECC) [SECP256k1](https://en.bitcoin.it/wiki/Secp256k1). Other cryptographic signature schemas adopted by the broader DID community are also being evaluated.
 
### Request Service API
Modified by Ken Withee on Mar 16, 2026 8:58 PM
đź“– View on learn.microsoft.com
+26 / -25 lines changed
Commit: Editorial pass: plan-issuance-solution.md (38 fixes)
Changes:
Before
After
 
 
It’s important to plan your issuance solution so that in addition to issuing credentials, you have a complete view of the architectural and business impacts of your solution. If you haven’t, we recommend you view the [Microsoft Entra Verified ID architecture overview](introduction-to-verifiable-credentials-architecture.md) for foundational information.
 
## Scope of guidance
 
<a name='azure-active-directory-tenant'></a>
 
### Microsoft Entra tenant
You need access to a Microsoft Entra tenant to host Microsoft Entra Verified ID. The Microsoft Entra tenant provides an Identity and Access Management (IAM) control plane for the resources part of the solution.
 
Each tenant uses the multitenant Microsoft Entra Verified ID service, and has a decentralized identifier (DID). The DID provides proof that the issuer owns the domain incorporated into the DID. The DID is used by the subject and the verifier to validate the issuer.
 
* Display definitions determine how claims are displayed in the holder’s wallet and also includes branding and other elements. The Display definition can be localized into multiple languages. See [How to customize your verifiable credentials](~/verified-id/credential-design.md).
 
* Rules are an issuer-defined model that describes the required inputs of a verifiable credential. Rules also defined trusted input sources, and the mapping of input claims to output claims stored in the VC. Depending on the type of attestation defined in the rules definition, the input claims can come from different providers. Input claims may come from an OIDC Identity Provider, from an id_token_hint, or from self asserted claims during issuance via user input in the wallet.
 
* **Input** – Are a subset of the model in the rules file for client consumption. The subset must describe the set of inputs, where to obtain the inputs and the endpoint to call to obtain a verifiable credential.
 
 
 
It’s important to plan your issuance solution so that in addition to issuing credentials, you have a complete view of the architectural and business impacts of your solution. If you haven’t, review the [Microsoft Entra Verified ID architecture overview](introduction-to-verifiable-credentials-architecture.md) for foundational information.
 
## Scope of guidance
 
<a name='azure-active-directory-tenant'></a>
 
### Microsoft Entra tenant
 
You need access to a Microsoft Entra tenant to host Microsoft Entra Verified ID. The Microsoft Entra tenant provides an Identity and Access Management (IAM) control plane for the resources part of the solution.
 
Each tenant uses the multitenant Microsoft Entra Verified ID service, and has a decentralized identifier (DID). The DID provides proof that the issuer owns the domain incorporated into the DID. The DID is used by the subject and the verifier to validate the issuer.
 
* Display definitions determine how claims are displayed in the holder’s wallet and also includes branding and other elements. The Display definition can be localized into multiple languages. See [How to customize your verifiable credentials](~/verified-id/credential-design.md).
 
* Rules are an issuer-defined model that describes the required inputs of a verifiable credential. Rules also define trusted input sources, and the mapping of input claims to output claims stored in the VC. Depending on the type of attestation defined in the rules definition, the input claims can come from different providers. Input claims may come from an OIDC Identity Provider, from an id_token_hint, or from self-asserted claims during issuance via user input in the wallet.
 
* **Input** – A subset of the model in the rules file for client consumption. The subset must describe the set of inputs, where to obtain the inputs and the endpoint to call to obtain a verifiable credential.
+25 / -25 lines changed
Commit: Editorial pass: user-facing articles (41 fixes)
Changes:
Before
After
---
title: Tutorial - Issue a Microsoft Entra Verified ID credential for directory based claims
description: In this tutorial, you learn how to issue verifiable credentials, from directory based claims, by using a sample app.
ms.topic: tutorial
ms.date: 01/31/2025
---
 
 
# Issue a Verifiable Credential for directory based claims
 
Employees with accounts in your Microsoft Entra ID environment can have Verifiable Credentials of the type VerifiedEmployee, created with claims sourced from their user profiles. In this tutorial, we create a credential with claims sourced from a user's profile in Microsoft Entra ID.
 
You can create VerifiedEmployee credentials using the [Quick setup](verifiable-credentials-configure-tenant-quick.md) or the [advanced setup](verifiable-credentials-configure-tenant.md). If you use the quick setup, the VerifiedEmployee credential is automatically created for you in a workforce tenant. If you use the advanced setup, you need to manually create the VerifiedEmployee credential as explained in this guide.
 
Issuing a VerifiedEmployee credential is now supported in [MyAccount](https://myaccount.microsoft.com). Instructions to enable it in Verified ID are available [here](verifiable-credentials-configure-tenant-quick.md#myaccount-available-now-to-simplify-issuance-of-workplace-credentials). Configuring a sample to issue VerifiedEmployee credentials is only necessary if you would like to handle issuance in your own app.
 
In this article, you learn how to:
 
> [!div class="checklist"]
>
---
title: Tutorial - Issue a Microsoft Entra Verified ID credential for directory-based claims
description: In this tutorial, you learn how to issue verifiable credentials, from directory based claims, by using a sample app.
ms.topic: tutorial
ms.date: 01/31/2025
---
 
 
# Issue a Verifiable Credential for directory-based claims
 
Employees with accounts in your Microsoft Entra ID environment can have Verifiable Credentials of the type VerifiedEmployee, created with claims sourced from their user profiles. In this tutorial, you create a credential with claims sourced from a user's profile in Microsoft Entra ID.
 
You can create VerifiedEmployee credentials using the [Quick setup](verifiable-credentials-configure-tenant-quick.md) or the [advanced setup](verifiable-credentials-configure-tenant.md). If you use the quick setup, the VerifiedEmployee credential is automatically created for you in a workforce tenant. If you use the advanced setup, you need to manually create the VerifiedEmployee credential as explained in this guide.
 
Issuing a VerifiedEmployee credential is now supported in [MyAccount](https://myaccount.microsoft.com). Instructions to enable it in Verified ID are available in the [quick setup guide](verifiable-credentials-configure-tenant-quick.md#myaccount-available-now-to-simplify-issuance-of-workplace-credentials). Configuring a sample to issue VerifiedEmployee credentials is only necessary if you would like to handle issuance in your own app.
 
In this article, you learn how to:
 
> [!div class="checklist"]
>
Modified by Ken Withee on Mar 16, 2026 8:59 PM
đź“– View on learn.microsoft.com
+25 / -25 lines changed
Commit: Editorial pass: user-facing articles (41 fixes)
Changes:
Before
After
# Customer intent: As an enterprise, we want to enable customers to manage information about themselves by using verifiable credentials.
---
 
# Using the Microsoft Authenticator with Verified ID
 
In this tutorial, you learn how to install the **Microsoft Authenticator** app and use it for the first time with Verified ID. You use the public end to end demo webapp to issue a verifiable credential to the **Authenticator** and present verifiable credentials from the **Authenticator**.
 
 
:::image type="content" source="media/using-authenticator/accept-screen.png" alt-text="Screenshot of Microsoft Authenticator app welcome screen with Accept button to agree to terms and conditions.":::
 
2. Select your choice of sharing app usage data and press **Continue**.
 
:::image type="content" source="media/using-authenticator/app-usage-sharing-screen.png" alt-text="Screenshot of Microsoft Authenticator app usage data sharing options screen with Continue button.":::
 
3. Press **Skip** in the upper right corner of the screen asking you to **Sign in with Microsoft**.
 
:::image type="content" source="media/using-authenticator/skip-signin-with-microsoft-screen.png" alt-text="Screenshot of Microsoft Authenticator sign-in screen with Skip button in the upper right corner.":::
 
 
When the Microsoft Authenticator app is installed and ready, you use the public end to end demo webapp to issue your first verifiable credential onto the Authenticator.
# Customer intent: As an enterprise, we want to enable customers to manage information about themselves by using verifiable credentials.
---
 
# Use the Microsoft Authenticator with Verified ID
 
In this tutorial, you learn how to install the **Microsoft Authenticator** app and use it for the first time with Verified ID. You use the public end to end demo webapp to issue a verifiable credential to the **Authenticator** and present verifiable credentials from the **Authenticator**.
 
 
:::image type="content" source="media/using-authenticator/accept-screen.png" alt-text="Screenshot of Microsoft Authenticator app welcome screen with Accept button to agree to terms and conditions.":::
 
1. Select your choice of sharing app usage data and press **Continue**.
 
:::image type="content" source="media/using-authenticator/app-usage-sharing-screen.png" alt-text="Screenshot of Microsoft Authenticator app usage data sharing options screen with Continue button.":::
 
1. Press **Skip** in the upper right corner of the screen asking you to **Sign in with Microsoft**.
 
:::image type="content" source="media/using-authenticator/skip-signin-with-microsoft-screen.png" alt-text="Screenshot of Microsoft Authenticator sign-in screen with Skip button in the upper right corner.":::
 
 
When the Microsoft Authenticator app is installed and ready, you use the public end to end demo webapp to issue your first verifiable credential onto the Authenticator.
+24 / -24 lines changed
Commit: Editorial pass: architecture articles (48 fixes)
Changes:
Before
After
---
title: Introduction to Microsoft Entra Verified ID
description: An overview Microsoft Entra Verified ID.
ms.topic: overview
ms.date: 06/25/2025
ms.reviewer:
 
# Introduction to Microsoft Entra Verified ID
 
In today's world, our digital and physical lives are becoming increasingly intertwined with the apps, services, and devices we use. This digital revolution opened a world of possibilities, allowing us to connect with countless companies and individuals in ways that were once unimaginable.
 
This increased connectivity introduces a greater risk of identity theft and data breaches. These breaches can be devastating to our personal and professional lives. Microsoft actively collaborates with various organizations and standards bodies to create a Decentralized Identity solution that puts individuals in control of their own digital identities. Decentralized identity technologies provide a secure and private way to manage identity data without relying on centralized authorities or intermediaries.
 
## Why we need decentralized identity
 
Today we use our digital identity at work, at home, and across every app, service, and device we use. This identity is made up of everything we say, do, and experience in our lives—purchasing tickets for an event, checking into a hotel, or even ordering lunch. Currently, our identity and all our digital interactions are dependent on third parties, in some cases, even without our knowledge.
 
Every day users grant apps and devices access to their data. A great deal of effort would be required for them to keep track of who has access to which pieces of information. On the enterprise front, collaboration with consumers and partners requires high-touch orchestration to securely exchange data in a way that maintains privacy and security for all involved.
 
We believe a standards-based Decentralized Identity system can unlock a new set of experiences that give users and organizations greater control over their data—and deliver a higher degree of trust and security for apps, devices, and service providers.
---
title: Introduction to Microsoft Entra Verified ID
description: An overview of Microsoft Entra Verified ID.
ms.topic: overview
ms.date: 06/25/2025
ms.reviewer:
 
# Introduction to Microsoft Entra Verified ID
 
In today's world, your digital and physical life is becoming increasingly intertwined with the apps, services, and devices you use. This digital revolution opened a world of possibilities, allowing you to connect with countless companies and individuals in ways that were once unimaginable.
 
This increased connectivity introduces a greater risk of identity theft and data breaches. These breaches can be devastating to personal and professional lives. Microsoft actively collaborates with various organizations and standards bodies to create a Decentralized Identity solution that puts individuals in control of their own digital identities. Decentralized identity technologies provide a secure and private way to manage identity data without relying on centralized authorities or intermediaries.
 
## Why decentralized identity matters
 
Today you use your digital identity at work, at home, and across every app, service, and device you use. This identity is made up of everything you say, do, and experience in your life—purchasing tickets for an event, checking into a hotel, or even ordering lunch. Currently, your identity and all your digital interactions are dependent on third parties, in some cases, even without your knowledge.
 
Every day, users grant apps and devices access to their data. A great deal of effort would be required for them to keep track of who has access to which pieces of information. On the enterprise front, collaboration with consumers and partners requires high-touch orchestration to securely exchange data in a way that maintains privacy and security for all involved.
 
A standards-based Decentralized Identity system can unlock a new set of experiences that give users and organizations greater control over their data—and deliver a higher degree of trust and security for apps, devices, and service providers.
+23 / -23 lines changed
Commit: Editorial pass: quarantine-unsanctioned-tenants.md (28 fixes)
Changes:
Before
After
 
# Quarantine unsanctioned tenants
 
>[!IMPORTANT]
> Refer to this article only after reviewing [the Microsoft Cloud Footprint FAQ](/azure/cost-management-billing/manage/discover-cloud-footprint) to discover your organization's inventory of tenants. This article outlines the specific existing Microsoft Entra capabilities administrators can leverage within their primary tenant to quarantine suspected unsanctioned tenants in their discovered list of tenants.
 
## What does it mean to quarantine a tenant?
 
Quarantine involves isolating suspected unsanctioned tenants by using existing Microsoft Entra capabilities. This immediately reduces security risk that exists from exposure to such tenants that you do not have administrative control of within your environment. By isolating, you introduce friction between your tenant and theirs, which acts as a scream test. This friction prompts administrators of the suspected tenants to contact you in need of assistance, giving you the opportunity to verify the legitimacy of the relationships with these tenants and/or regain control over them. If no one is to contact you, then you can leave the tenants in the quarantined state indefinitely.
 
 
## When should I quarantine a tenant?
 
You are an IT Admin for the company "Contoso" with the primary tenant of "Contoso.com." To secure data in the central Contoso tenant, you need to ensure users and applications with privileged access to your tenant are in tenants that properly secure these resources. Likewise, you want to ensure that external tenants in which your tenant has permissions into are known and following secure practices. To secure Contoso, you want to find all tenants that have inbound or outbound relationships with your primary tenant.
After following the [Microsoft Cloud Footprint FAQ](/azure/cost-management-billing/manage/discover-cloud-footprint), you have identified a few potential tenants that may or may not belong to your company. Let's call these tenants ContosoTest.com and ContosoDemo.com for scenario purposes. Because you don't know who the global admins are for these tenants, you worry they are possibly employee-managed and do not comply with your organization's security policies. This poses a major security risk to your environment if they stay unmanaged.
Since you don't have direct control over ContosoTest.com and ContosoDemo.com, you can only modify settings on the Contoso.com tenant. You want to quarantine them to minimize potential vulnerabilities that come from the exposure to these tenants. However, it's crucial that any changes you make are easily reversible, ensuring that no critical systems are unintentionally affected in the process. After quarantine, you introduced enough friction between your tenant and the suspected tenants to encourage the administrators of the tenants to contact your helpdesk.
 
 
:::image type="content" source="media/quarantine-unsanctioned-tenant/identified.png" alt-text="Diagram that showed unsactioned tenants discovered in the environment.":::
 
 
# Quarantine unsanctioned tenants
 
> [!IMPORTANT]
> Refer to this article only after reviewing [the Microsoft Cloud Footprint FAQ](/azure/cost-management-billing/manage/discover-cloud-footprint) to discover your organization's inventory of tenants. This article outlines the specific existing Microsoft Entra capabilities you can use within your primary tenant to quarantine suspected unsanctioned tenants in their discovered list of tenants.
 
## What does it mean to quarantine a tenant?
 
Quarantine involves isolating suspected unsanctioned tenants by using existing Microsoft Entra capabilities. This immediately reduces security risk that exists from exposure to such tenants that you don't have administrative control of within your environment. By isolating, you introduce friction between your tenant and theirs, which acts as a scream test. This friction prompts administrators of the suspected tenants to contact you in need of assistance, giving you the opportunity to verify the legitimacy of the relationships with these tenants or regain control over them. If no one contacts you, then you can leave the tenants in the quarantined state indefinitely.
 
 
## When should I quarantine a tenant?
 
You are an IT Admin for the company "Contoso" with the primary tenant of "Contoso.com." To secure data in the central Contoso tenant, you need to ensure users and applications with privileged access to your tenant are in tenants that properly secure these resources. Likewise, you want to ensure that external tenants in which your tenant has permissions into are known and following secure practices. To secure Contoso, you want to find all tenants that have inbound or outbound relationships with your primary tenant.
After following the [Microsoft Cloud Footprint FAQ](/azure/cost-management-billing/manage/discover-cloud-footprint), you have identified a few potential tenants that might or might not belong to your company. Let's call these tenants ContosoTest.com and ContosoDemo.com for scenario purposes. Because you don't know who the global admins are for these tenants, you worry they are possibly employee-managed and do not comply with your organization's security policies. This poses a major security risk to your environment if they stay unmanaged.
Since you don't have direct control over ContosoTest.com and ContosoDemo.com, you can only modify settings on the Contoso.com tenant. You want to quarantine them to minimize potential vulnerabilities that come from the exposure to these tenants. However, it's crucial that any changes you make are easily reversible, ensuring that no critical systems are unintentionally affected in the process. After quarantine, you introduce enough friction between your tenant and the suspected tenants to encourage the administrators of the tenants to contact your helpdesk.
 
 
:::image type="content" source="media/quarantine-unsanctioned-tenant/identified.png" alt-text="Diagram that shows unsanctioned tenants discovered in the environment.":::
 
+20 / -20 lines changed
Commit: Editorial pass: architecture articles (48 fixes)
Changes:
Before
After
 
 
It’s important to plan your verifiable credential solution so that in addition to issuing and or validating credentials, you have a complete view of the architectural and business impacts of your solution. If you haven’t reviewed them already, we recommend you review [Introduction to Microsoft Entra Verified ID](decentralized-identifier-overview.md) and the [FAQs](verifiable-credentials-faq.md), and then complete the [Getting Started](./verifiable-credentials-configure-tenant.md) tutorial.
 
This architectural overview introduces the capabilities and components of the Microsoft Entra Verified ID service. For more detailed information on issuance and validation, see
 
 
:::image type="content" source="media/introduction-to-verifiable-credentials-architecture/decentralized-architecture.png" alt-text="Architectural diagram showing decentralized identity system with Woodgrove as issuer, Alice as holder, and Proseware as verifier, connected through verifiable credentials and decentralized identifiers.":::
 
Terminology for verifiable credentials (VCs) might be confusing if you're not familiar with VCs. The following definitions are from the [Verifiable Credentials Data Model 1.0](https://www.w3.org/TR/vc-data-model/) terminology section. After each, we relate them to entities in the preceding diagram.
 
"An ***issuer*** is a role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder."
 
 
:::image type="content" source="media/introduction-to-verifiable-credentials-architecture/inside-trust-boundary.png" alt-text="Architectural diagram showing Alice accessing Woodgrove resources within the centralized trust boundary, with identity provider controlling access to applications and services.":::
 
As an employee, Alice is operating inside of the trust boundary of Woodgrove. Woodgrove acts as the identity provider (IDP) and maintains complete control of the identity and the configuration of the apps Alice uses to interact within the Woodgrove trust boundary. To use resources in the Microsoft Entra ID trust boundary, Alice provides potentially multiple forms of proof of identification to sign in Woodgrove’s trust boundary and access the resources inside of Woodgrove’s technology environment. Multiple proofs is a typical scenario that is well served using a centralized identity architecture.
 
* Woodgrove manages the trust boundary and using good security practices provides the least-privileged level of access to Alice based on the job performed. To maintain a strong security posture, and potentially for compliance reasons, Woodgrove must also be able to track employees’ permissions and access to resources and must be able to revoke permissions when the employment is terminated.
 
 
It’s important to plan your verifiable credential solution so that in addition to issuing or validating credentials, you have a complete view of the architectural and business impacts of your solution. If you haven’t reviewed them already, review the [Introduction to Microsoft Entra Verified ID](decentralized-identifier-overview.md) and the [FAQs](verifiable-credentials-faq.md), and then complete the [Getting Started](./verifiable-credentials-configure-tenant.md) tutorial.
 
This architectural overview introduces the capabilities and components of the Microsoft Entra Verified ID service. For more detailed information on issuance and validation, see
 
 
:::image type="content" source="media/introduction-to-verifiable-credentials-architecture/decentralized-architecture.png" alt-text="Architectural diagram showing decentralized identity system with Woodgrove as issuer, Alice as holder, and Proseware as verifier, connected through verifiable credentials and decentralized identifiers.":::
 
Terminology for verifiable credentials (VCs) might be confusing if you're not familiar with VCs. The following definitions are from the [Verifiable Credentials Data Model 1.0](https://www.w3.org/TR/vc-data-model/) terminology section. After each definition, they're related to entities in the preceding diagram.
 
"An ***issuer*** is a role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder."
 
 
:::image type="content" source="media/introduction-to-verifiable-credentials-architecture/inside-trust-boundary.png" alt-text="Architectural diagram showing Alice accessing Woodgrove resources within the centralized trust boundary, with identity provider controlling access to applications and services.":::
 
As an employee, Alice is operating inside of the trust boundary of Woodgrove. Woodgrove acts as the identity provider (IDP) and maintains complete control of the identity and the configuration of the apps Alice uses to interact within the Woodgrove trust boundary. To use resources in the Microsoft Entra ID trust boundary, Alice provides potentially multiple forms of proof of identification to sign in to Woodgrove’s trust boundary and access the resources inside of Woodgrove’s technology environment. Multiple proofs is a typical scenario that is well served using a centralized identity architecture.
 
* Woodgrove manages the trust boundary and using good security practices provides the least-privileged level of access to Alice based on the job performed. To maintain a strong security posture, and potentially for compliance reasons, Woodgrove must also be able to track employees’ permissions and access to resources and must be able to revoke permissions when the employment is terminated.
+20 / -20 lines changed
Commit: Editorial pass: user management articles (33 fixes)
Changes:
Before
After
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [User Administrator](../identity/role-based-access-control/permissions-reference.md#user-administrator).
 
2. Browse to **Entra ID** > **Users**.
 
:::image type="content" source="media/how-to-manage-user-profile-info/all-users.png" alt-text="Screenshot of the All users page in Microsoft Entra ID.":::
 
3. Select a user.
 
4. There are two ways to edit user profile details. Either select **Edit properties** from the top of the page or select **Properties**.
 
:::image type="content" source="media/how-to-manage-user-profile-info/user-profile-overview.png" alt-text="Screenshot of the overview page for a selected user, with the edit options highlighted.":::
 
5. After making any changes, select the **Save** button.
 
If you selected the **Edit properties** option:
 
- **On-premises:** Accounts synced from Windows Server Active Directory include other values not applicable to Microsoft Entra accounts.
 
> [!NOTE]
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [User Administrator](../identity/role-based-access-control/permissions-reference.md#user-administrator).
 
1. Browse to **Entra ID** > **Users**.
 
:::image type="content" source="media/how-to-manage-user-profile-info/all-users.png" alt-text="Screenshot of the All users page in Microsoft Entra ID.":::
 
1. Select a user.
 
1. There are two ways to edit user profile details. Either select **Edit properties** from the top of the page or select **Properties**.
 
:::image type="content" source="media/how-to-manage-user-profile-info/user-profile-overview.png" alt-text="Screenshot of the overview page for a selected user, with the edit options highlighted.":::
 
1. After making any changes, select the **Save** button.
 
If you selected the **Edit properties** option:
 
- **On-premises:** Accounts synced from Windows Server Active Directory include other values not applicable to Microsoft Entra accounts.
 
> [!NOTE]
+20 / -20 lines changed
Commit: Editorial pass: licensing-groups-resolve-problems.md (22 fixes)
Changes:
Before
After
---
title: Resolve group license assignment problems.
description: How to identify and resolve license assignment problems when you're using Microsoft Entra group-based licensing.
keywords: Microsoft Entra ID licensing
manager: pmwongera
 
[!INCLUDE [licensing updates](~/includes/licensing-change.md)]
 
Group-based licensing (GBL) in Microsoft 365 Admin Portal, introduces the concept of users in a licensing error state. This article explains the reasons why users might end up in this state.
 
When you assign licenses directly to individual users or using group-based licensing (or both), the assignment operation might fail for reasons that are related to business logic.
Some example issues include but aren't limited to:
 
- An insufficient number of licenses
 
- Service plans in one license depend on service plans from another license
 
 
## Find license assignment errors on users members of a group when using group based licensing
---
title: Resolve group license assignment problems
description: How to identify and resolve license assignment problems when you're using Microsoft Entra group-based licensing.
keywords: Microsoft Entra ID licensing
manager: pmwongera
 
[!INCLUDE [licensing updates](~/includes/licensing-change.md)]
 
Group-based licensing (GBL) in Microsoft 365 Admin Portal, introduces the concept of users in a licensing error state. This article explains the reasons why users might end up in this state.
 
When you assign licenses directly to individual users or using group-based licensing (or both), the assignment operation might fail for reasons that are related to business logic.
Some example issues include:
 
- An insufficient number of licenses
 
- Service plans in one license depend on service plans from another license
 
 
## Find license assignment errors for group members with group-based licensing
+18 / -19 lines changed
Commit: Refine TLS inspection concept article wording and consistency
Changes:
Before
After
#customer intent: As a Global Secure Access administrator, I want to learn about the Transport Layer Security (TLS) protocol to support the creation of TLS inspection policies.
 
---
# What is Transport Layer Security inspection?
The Transport Layer Security (TLS) protocol uses certificates at the transport layer to ensure the privacy, integrity, and authenticity of data exchanged between two communicating parties. While TLS secures legitimate traffic, malicious traffic like malware and data leakage attacks can still hide behind encryption. The Microsoft Entra Internet Access TLS inspection capability provides visibility into encrypted traffic by making content available for enhanced protection, such as malware detection, data loss prevention, prompt inspection, and other advanced security controls. This article gives an overview of the TLS inspection process.
 
## The TLS inspection process
When you enable TLS inspection, Global Secure Access decrypts HTTPS requests at the service edge and applies security controls like full URL enhanced web content filtering policies. If no security control blocks the request, Global Secure Access encrypts and forwards the request to the destination.
 
To enable TLS inspection, follow these steps:
1. Generate a certificate signing request (CSR) in the Global Secure Access portal and sign the CSR using your organization's root or intermediate certificate authority.
1. Upload the signed certificate to the portal.
Global Secure Access uses this certificate as an intermediate certificate authority for TLS inspection. During traffic interception, Global Secure Access dynamically generates short lived leaf certificates using the intermediate certificate. TLS inspection establishes two separate TLS connections:
- One from the client browser to a Global Secure Access service edge
- One from Global Secure Access to the destination server
 
Global Secure Access uses leaf certificates during TLS handshakes between client devices and the service. To ensure successful handshakes, install your root certificate authority, and intermediate certificate authority if used for signing the CSR, in the trusted certificate store on all client devices.
 
<!-- Art Library Source# ConceptArt-0-000-047 -->
#customer intent: As a Global Secure Access administrator, I want to learn about the Transport Layer Security (TLS) protocol to support the creation of TLS inspection policies.
 
---
# What is Transport Layer Security Inspection?
The Transport Layer Security (TLS) protocol uses certificates at the transport layer to ensure the privacy, integrity, and authenticity of data exchanged between two communicating parties. While TLS secures legitimate traffic, malicious traffic like malware and data leakage attacks can still hide behind encryption. The Microsoft Entra Internet Access TLS inspection capability provides visibility into encrypted traffic by making content available for enhanced protection, such as malware detection, data loss prevention, prompt inspection, and other advanced security controls. This article gives an overview of the TLS inspection process.
 
## The TLS inspection process
When you enable TLS inspection, Global Secure Access decrypts HTTPS requests at the service edge. Advanced security controls, such as full URL filtering and file scan policies, are evaluated. If no security control blocks the request, Global Secure Access re-encrypts and forwards the request to the destination.
 
To enable TLS inspection, follow these steps:
1. Generate a certificate signing request (CSR) in the Global Secure Access portal and sign the CSR using your organization's root or intermediate certificate authority.
1. Upload the signed certificate to the portal.
Global Secure Access uses a two-tier certificate architecture. The customer-signed intermediate certificate is the first tier and is used to create a second short-lived intermediate certificate, which dynamically generates leaf certificates for TLS termination. TLS inspection establishes two separate TLS connections:
- One from the client browser to a Global Secure Access service edge
- One from Global Secure Access to the destination server
 
Global Secure Access uses leaf certificates during TLS handshakes between client devices and the service. To ensure successful handshakes, install your root certificate authority and the intermediate certificate authority (if used to sign the CSR) in the trusted certificate store on all client devices.
 
<!-- Art Library Source# ConceptArt-0-000-047 -->
Modified by Ken Withee on Mar 16, 2026 6:18 PM
đź“– View on learn.microsoft.com
+18 / -18 lines changed
Commit: Editorial pass: overview & getting started articles (33 fixes)
Changes:
Before
After
 
1. Create your new directory by following the steps in [Create a new tenant for your organization](./create-new-tenant.md#create-a-new-tenant-for-your-organization).
 
2. [!INCLUDE [tenant-installation-account](../includes/definitions/tenant-installation-account.md)]
 
> [!TIP]
> If you plan to federate on-premises Windows Server Active Directory with Microsoft Entra ID, then you need to select **I plan to configure this domain for single sign-on with my local Active Directory** when you run the Microsoft Entra Connect tool to synchronize your directories.
>
> You also need to register the same domain name you select for federating with your on-premises directory in the **Microsoft Entra Domain** step in the wizard. To see what that setup looks like, see [Verify the domain selected for federation](~/identity/hybrid/connect/how-to-connect-install-custom.md#verify-the-azure-ad-domain-selected-for-federation). If you don't have the Microsoft Entra Connect tool, you can download the latest version from the [Microsoft Entra Admin Center](https://entra.microsoft.com/#view/Microsoft_AAD_Connect_Provisioning/AADConnectMenuBlade/~/GetStarted) under the **Manage** tab of the **Microsoft Entra Connect | Get started** page.
 
## Add your custom domain name
 
After you create your directory, you can add your custom domain name.
 
> [!IMPORTANT]
> When updating domain information, you may be unable to complete the process and encounter an HTTP 500 Internal Server Error message. Under some conditions, this error may be expected. This message may appear if you try to use a protected DNS suffix. Protected DNS suffixes may only be used by Microsoft. If you believe that this operation should have been completed successfully, contact your Microsoft representative for assistance.
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Domain Name Administrator](~/identity/role-based-access-control/permissions-reference.md#domain-name-administrator).
 
2. Browse to **Entra ID** > **Domain names** > **Add custom domain**.
 
1. Create your new directory by following the steps in [Create a new tenant for your organization](./create-new-tenant.md#create-a-new-tenant-for-your-organization).
 
1. [!INCLUDE [tenant-installation-account](../includes/definitions/tenant-installation-account.md)]
 
> [!TIP]
> If you plan to federate on-premises Windows Server Active Directory with Microsoft Entra ID, then you need to select **I plan to configure this domain for single sign-on with my local Active Directory** when you run the Microsoft Entra Connect tool to synchronize your directories.
>
> You also need to register the same domain name you select for federating with your on-premises directory in the **Microsoft Entra Domain** step in the wizard. To see what that setup looks like, see [Verify the domain selected for federation](~/identity/hybrid/connect/how-to-connect-install-custom.md#verify-the-azure-ad-domain-selected-for-federation). If you don't have the Microsoft Entra Connect tool, you can download the latest version from the [Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_Connect_Provisioning/AADConnectMenuBlade/~/GetStarted) under the **Manage** tab of the **Microsoft Entra Connect | Get started** page.
 
## Add your custom domain name
 
After you create your directory, you can add your custom domain name.
 
> [!IMPORTANT]
> When updating domain information, you might be unable to complete the process and encounter an HTTP 500 Internal Server Error message. Under some conditions, this error might be expected. This message might appear if you try to use a protected DNS suffix. Protected DNS suffixes might only be used by Microsoft. If you believe that this operation should have been completed successfully, contact your Microsoft representative for assistance.
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Domain Name Administrator](~/identity/role-based-access-control/permissions-reference.md#domain-name-administrator).
 
1. Browse to **Entra ID** > **Domain names** > **Add custom domain**.