From 5fa5389f20ce58652c66a5c1569a0372407c2171 Mon Sep 17 00:00:00 2001
From: mapalko <20977663+mapalko@users.noreply.github.com>
Date: Thu, 15 Sep 2022 17:19:13 -0700
Subject: [PATCH 1/5] add kerberos hash algorithm policies

---
 .../mdm/policy-csp-kerberos.md                | 227 +++++++++++++++++-
 1 file changed, 220 insertions(+), 7 deletions(-)

diff --git a/windows/client-management/mdm/policy-csp-kerberos.md b/windows/client-management/mdm/policy-csp-kerberos.md
index 0e1fdaeb77..c1c91b3fc2 100644
--- a/windows/client-management/mdm/policy-csp-kerberos.md
+++ b/windows/client-management/mdm/policy-csp-kerberos.md
@@ -31,6 +31,18 @@ manager: aaroncz
   </dd>
   <dd>
     <a href="#kerberos-pkinithashalgorithmconfiguration">Kerberos/PKInitHashAlgorithmConfiguration</a>
+  </dd>  
+  <dd>
+    <a href="#kerberos-pkinithashalgorithmsha1">Kerberos/PKInitHashAlgorithmSHA1</a>
+  </dd>
+  <dd>
+    <a href="#kerberos-pkinithashalgorithmsha256">Kerberos/PKInitHashAlgorithmSHA256</a>
+  </dd>
+  <dd>
+    <a href="#kerberos-pkinithashalgorithmsha384">Kerberos/PKInitHashAlgorithmSHA384</a>
+  </dd>
+  <dd>
+    <a href="#kerberos-pkinithashalgorithmsha512">Kerberos/PKInitHashAlgorithmSHA512</a>
   </dd>
   <dd>
     <a href="#kerberos-requirekerberosarmoring">Kerberos/RequireKerberosArmoring</a>
@@ -231,22 +243,20 @@ ADMX Info:
 
 This policy setting controls hash or checksum algorithms used by the Kerberos client when performing certificate authentication.
 
-If you enable this policy, you'll be able to configure one of four states for each algorithm:
-
-* **Default**: This state sets the algorithm to the recommended state.
-* **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
-* **Audited**: This state enables usage of the algorithm and reports an event (ID 205) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
-* **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
+If you enable this policy, you'll be able to configure one of four states for each hash algorithm (SHA1, SHA256, SHA384, and SHA512) using their respective policies.
 
 If you disable or don't configure this policy, each algorithm will assume the **Default** state.
 
+* 0 - **Disabled**
+* 1 - **Enabled**
+
 More information about the hash and checksum algorithms supported by the Windows Kerberos client and their default states can be found https://go.microsoft.com/fwlink/?linkid=2169037.
 
 <!--/Description-->
 
 <!--ADMXBacked-->
 ADMX Info:  
--   GP Friendly name: *Introducing agility to PKINIT in Kerberos protocol*
+-   GP Friendly name: *Configure Hash algorithms for certificate logon*
 -   GP name: *PKInitHashAlgorithmConfiguration*
 -   GP path: *System/Kerberos*
 -   GP ADMX file name: *Kerberos.admx*
@@ -256,6 +266,209 @@ ADMX Info:
 
 <hr/>
 
+<!--Policy-->
+<a href="" id="kerberos-pkinithashalgorithmsha1"></a>**Kerberos/PKInitHashAlgorithmSHA1**  
+
+<!--SupportedSKUs-->
+
+|Edition|Windows 10|Windows 11|
+|--- |--- |--- |
+|Home|No|No|
+|Pro|Yes|Yes|
+|Windows SE|No|Yes|
+|Business|Yes|Yes|
+|Enterprise|Yes|Yes|
+|Education|Yes|Yes|
+
+<!--/SupportedSKUs-->
+<hr/>
+
+<!--Scope-->
+[Scope](./policy-configuration-service-provider.md#policy-scope):
+
+> [!div class = "checklist"]
+> * Device
+
+<hr/>
+
+<!--/Scope-->
+<!--Description-->
+
+This policy setting controls the configuration of the SHA1 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
+
+* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
+* 1 - **Default**: This state sets the algorithm to the recommended state.
+* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
+* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
+
+If you don't configure this policy, each SHA1 will assume the **Default** state.
+
+<!--/Description-->
+
+<!--ADMXBacked-->
+ADMX Info:  
+-   GP Friendly name: *Configure Hash algorithms for certificate logon*
+-   GP name: *PKInitHashAlgorithmConfiguration*
+-   GP path: *System/Kerberos*
+-   GP ADMX file name: *Kerberos.admx*
+
+<!--/ADMXBacked-->
+<!--/Policy-->
+
+<hr/>
+
+<!--Policy-->
+<a href="" id="kerberos-pkinithashalgorithmsha256"></a>**Kerberos/PKInitHashAlgorithmSHA256**  
+
+<!--SupportedSKUs-->
+
+|Edition|Windows 10|Windows 11|
+|--- |--- |--- |
+|Home|No|No|
+|Pro|Yes|Yes|
+|Windows SE|No|Yes|
+|Business|Yes|Yes|
+|Enterprise|Yes|Yes|
+|Education|Yes|Yes|
+
+<!--/SupportedSKUs-->
+<hr/>
+
+<!--Scope-->
+[Scope](./policy-configuration-service-provider.md#policy-scope):
+
+> [!div class = "checklist"]
+> * Device
+
+<hr/>
+
+<!--/Scope-->
+<!--Description-->
+
+This policy setting controls the configuration of the SHA256 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
+
+* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
+* 1 - **Default**: This state sets the algorithm to the recommended state.
+* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
+* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
+
+If you don't configure this policy, each SHA256 will assume the **Default** state.
+
+<!--/Description-->
+
+<!--ADMXBacked-->
+ADMX Info:  
+-   GP Friendly name: *Configure Hash algorithms for certificate logon*
+-   GP name: *PKInitHashAlgorithmConfiguration*
+-   GP path: *System/Kerberos*
+-   GP ADMX file name: *Kerberos.admx*
+
+<!--/ADMXBacked-->
+<!--/Policy-->
+
+<hr/>
+
+<!--Policy-->
+<a href="" id="kerberos-pkinithashalgorithmsha384"></a>**Kerberos/PKInitHashAlgorithmSHA384**  
+
+<!--SupportedSKUs-->
+
+|Edition|Windows 10|Windows 11|
+|--- |--- |--- |
+|Home|No|No|
+|Pro|Yes|Yes|
+|Windows SE|No|Yes|
+|Business|Yes|Yes|
+|Enterprise|Yes|Yes|
+|Education|Yes|Yes|
+
+<!--/SupportedSKUs-->
+<hr/>
+
+<!--Scope-->
+[Scope](./policy-configuration-service-provider.md#policy-scope):
+
+> [!div class = "checklist"]
+> * Device
+
+<hr/>
+
+<!--/Scope-->
+<!--Description-->
+
+This policy setting controls the configuration of the SHA384 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
+
+* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
+* 1 - **Default**: This state sets the algorithm to the recommended state.
+* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
+* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
+
+If you don't configure this policy, each SHA384 will assume the **Default** state.
+
+<!--/Description-->
+
+<!--ADMXBacked-->
+ADMX Info:  
+-   GP Friendly name: *Configure Hash algorithms for certificate logon*
+-   GP name: *PKInitHashAlgorithmConfiguration*
+-   GP path: *System/Kerberos*
+-   GP ADMX file name: *Kerberos.admx*
+
+<!--/ADMXBacked-->
+<!--/Policy-->
+
+<hr/>
+
+<!--Policy-->
+<a href="" id="kerberos-pkinithashalgorithmsha512"></a>**Kerberos/PKInitHashAlgorithmSHA512**  
+
+<!--SupportedSKUs-->
+
+|Edition|Windows 10|Windows 11|
+|--- |--- |--- |
+|Home|No|No|
+|Pro|Yes|Yes|
+|Windows SE|No|Yes|
+|Business|Yes|Yes|
+|Enterprise|Yes|Yes|
+|Education|Yes|Yes|
+
+<!--/SupportedSKUs-->
+<hr/>
+
+<!--Scope-->
+[Scope](./policy-configuration-service-provider.md#policy-scope):
+
+> [!div class = "checklist"]
+> * Device
+
+<hr/>
+
+<!--/Scope-->
+<!--Description-->
+
+This policy setting controls the configuration of the SHA512 algorithm used by the Kerberos client when performing certificate authentication. This policy is only enforced if Kerberos/PKInitHashAlgorithmConfiguration is enabled. You can configure one of four states for this algorithm:
+
+* 0 - **Not Supported**: This state disables usage of the algorithm. This state is intended for algorithms that are deemed to be insecure.
+* 1 - **Default**: This state sets the algorithm to the recommended state.
+* 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
+* 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
+
+If you don't configure this policy, each SHA512 will assume the **Default** state.
+
+<!--/Description-->
+
+<!--ADMXBacked-->
+ADMX Info:  
+-   GP Friendly name: *Configure Hash algorithms for certificate logon*
+-   GP name: *PKInitHashAlgorithmConfiguration*
+-   GP path: *System/Kerberos*
+-   GP ADMX file name: *Kerberos.admx*
+
+<!--/ADMXBacked-->
+<!--/Policy-->
+<hr/>
+
 <!--Policy-->
 <a href="" id="kerberos-requirekerberosarmoring"></a>**Kerberos/RequireKerberosArmoring**  
 

From 566f04cab5b671c9095cc8105b38882711e89743 Mon Sep 17 00:00:00 2001
From: mapalko <20977663+mapalko@users.noreply.github.com>
Date: Mon, 19 Sep 2022 08:58:56 -0700
Subject: [PATCH 2/5] Update policy-csp-kerberos.md

Fixing grammatical issue
---
 windows/client-management/mdm/policy-csp-kerberos.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/windows/client-management/mdm/policy-csp-kerberos.md b/windows/client-management/mdm/policy-csp-kerberos.md
index c1c91b3fc2..3c77cc2e2c 100644
--- a/windows/client-management/mdm/policy-csp-kerberos.md
+++ b/windows/client-management/mdm/policy-csp-kerberos.md
@@ -301,7 +301,7 @@ This policy setting controls the configuration of the SHA1 algorithm used by the
 * 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
 * 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
 
-If you don't configure this policy, each SHA1 will assume the **Default** state.
+If you don't configure this policy, the SHA1 algorithm will assume the **Default** state.
 
 <!--/Description-->
 
@@ -352,7 +352,7 @@ This policy setting controls the configuration of the SHA256 algorithm used by t
 * 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
 * 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
 
-If you don't configure this policy, each SHA256 will assume the **Default** state.
+If you don't configure this policy, the SHA256 algorithm will assume the **Default** state.
 
 <!--/Description-->
 
@@ -403,7 +403,7 @@ This policy setting controls the configuration of the SHA384 algorithm used by t
 * 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
 * 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
 
-If you don't configure this policy, each SHA384 will assume the **Default** state.
+If you don't configure this policy, the SHA384 algorithm will assume the **Default** state.
 
 <!--/Description-->
 
@@ -454,7 +454,7 @@ This policy setting controls the configuration of the SHA512 algorithm used by t
 * 2 - **Audited**: This state enables usage of the algorithm and reports an event (ID 206) every time it's used. This state is intended to verify that the algorithm isn't being used and can be safely disabled.
 * 3 - **Supported**: This state enables usage of the algorithm. Enabling algorithms that have been disabled by default may reduce your security.
 
-If you don't configure this policy, each SHA512 will assume the **Default** state.
+If you don't configure this policy, the SHA512 algorithm will assume the **Default** state.
 
 <!--/Description-->
 
@@ -669,4 +669,4 @@ Devices joined to Azure Active Directory in a hybrid environment need to interac
 
 ## Related topics
 
-[Policy configuration service provider](policy-configuration-service-provider.md)
\ No newline at end of file
+[Policy configuration service provider](policy-configuration-service-provider.md)

From 8cf930d7312fe296d6372ff90d35bdb095a6fa91 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Mon, 19 Sep 2022 17:41:58 -0400
Subject: [PATCH 3/5] WHFB cloud trust updates

---
 .openpublishing.redirection.json              |   5 +
 .../hello-deployment-guide.md                 |  10 +-
 .../hello-for-business/hello-faq.yml          |   4 +-
 .../hello-feature-pin-reset.md                |   4 +-
 .../hello-how-it-works-authentication.md      |  10 +-
 .../hello-how-it-works-provisioning.md        |   8 +-
 ...d => hello-hybrid-cloud-kerberos-trust.md} | 110 +++++++++---------
 .../hello-identity-verification.md            |   4 +-
 .../hello-for-business/hello-overview.md      |   4 +-
 .../hello-planning-guide.md                   |   2 +-
 .../hello-for-business/index.yml              |   4 +-
 .../hello-for-business/toc.yml                |   4 +-
 12 files changed, 88 insertions(+), 81 deletions(-)
 rename windows/security/identity-protection/hello-for-business/{hello-hybrid-cloud-trust.md => hello-hybrid-cloud-kerberos-trust.md} (66%)

diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json
index 2c59b009f8..2c16c8c303 100644
--- a/.openpublishing.redirection.json
+++ b/.openpublishing.redirection.json
@@ -19644,6 +19644,11 @@
      "source_path": "windows/security/identity-protection/access-control/dynamic-access-control.md",
      "redirect_url": "/windows-server/identity/solution-guides/dynamic-access-control-overview",
      "redirect_document_id": false
+     },
+     {
+     "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md",
+     "redirect_url": "windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md",
+     "redirect_document_id": false
      }
   ]
 }
diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
index 0f2c45e2f0..00e6171863 100644
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md
@@ -35,7 +35,7 @@ This guide assumes that baseline infrastructure exists which meets the requireme
 - Multi-factor Authentication is required during Windows Hello for Business provisioning
 - Proper name resolution, both internal and external names
 - Active Directory and an adequate number of domain controllers per site to support authentication
-- Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud trust deployments)
+- Active Directory Certificate Services 2012 or later (Note: certificate services are not needed for cloud Kerberos trust deployments)
 - One or more workstation computers running Windows 10, version 1703 or later
 
 If you are installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.  
@@ -44,23 +44,23 @@ Do not begin your deployment until the hosting servers and infrastructure (not r
 
 ## Deployment and trust models
 
-Windows Hello for Business has three deployment models: Azure AD cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key trust*, *certificate trust*, and *cloud trust*. On-premises deployment models only support *Key trust* and *certificate trust*.
+Windows Hello for Business has three deployment models: Azure AD cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key Trust*, *Certificate Trust*, and *cloud Kerberos trust*. On-premises deployment models only support *Key Trust* and *Certificate Trust*.
 
 Hybrid deployments are for enterprises that use Azure Active Directory. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Azure Active Directory must use the hybrid deployment model for all domains in that forest.
 
 The trust model determines how you want users to authenticate to the on-premises Active Directory:
 
 - The key-trust model is for enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
-- The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using cloud trust instead of key trust if the clients in your enterprise support it.
+- The cloud-trust model is also for hybrid enterprises who do not want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and does not require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
 - The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today.
 - The certificate trust model also supports enterprises which are not ready to deploy Windows Server 2016 Domain Controllers.
 
 > [!Note]
-> RDP does not support authentication with Windows Hello for Business key trust or cloud trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust and cloud trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
+> RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
 
 Following are the various deployment guides and models included in this topic:
 
-- [Hybrid Azure AD Joined Cloud Trust Deployment](hello-hybrid-cloud-trust.md)
+- [Hybrid Azure AD Joined cloud Kerberos trust Deployment](hello-hybrid-cloud-kerberos-trust.md)
 - [Hybrid Azure AD Joined Key Trust Deployment](hello-hybrid-key-trust.md)
 - [Hybrid Azure AD Joined Certificate Trust Deployment](hello-hybrid-cert-trust.md)
 - [Azure AD Join Single Sign-on Deployment Guides](hello-hybrid-aadj-sso.md)
diff --git a/windows/security/identity-protection/hello-for-business/hello-faq.yml b/windows/security/identity-protection/hello-for-business/hello-faq.yml
index bc542d1967..88115dc1cb 100644
--- a/windows/security/identity-protection/hello-for-business/hello-faq.yml
+++ b/windows/security/identity-protection/hello-for-business/hello-faq.yml
@@ -29,9 +29,9 @@ sections:
   - name: Ignored
     questions:
     
-      - question: What is Windows Hello for Business cloud trust?
+      - question: What is Windows Hello for Business cloud Kerberos trust?
         answer: |
-          Windows Hello for Business cloud trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid Cloud Trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust).
+          Windows Hello for Business cloud Kerberos trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid cloud Kerberos trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust).
 
 
       - question: What about virtual smart cards?
diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
index 435fe6109b..9b9e87b305 100644
--- a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
+++ b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
@@ -96,8 +96,8 @@ Using Group Policy, Microsoft Intune or a compatible MDM solution, you can confi
 |--- |--- |--- |
 |**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.|
 |**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.|
-|**Azure Active Directory Joined**|Cert Trust, Key Trust, and Cloud Trust|Cert Trust, Key Trust, and Cloud Trust|
-|**Hybrid Azure Active Directory Joined**|Cert Trust and Cloud Trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and Cloud Trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
+|**Azure Active Directory Joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust|
+|**Hybrid Azure Active Directory Joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
 |**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it is only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.|
 |**Additional Configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature On-board the Microsoft PIN reset service to respective Azure Active Directory tenant Configure Windows devices to use PIN reset using Group *Policy\MDM*.|
 |**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
index 909df0b77b..e1c3b1c5d2 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
@@ -21,10 +21,10 @@ Windows Hello for Business authentication is passwordless, two-factor authentica
 Azure Active Directory-joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
 
 - [Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory)
-- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud trust preview)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-trust-preview)
+- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud Kerberos trust)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-trust-preview)
 - [Azure AD join authentication to Active Directory using a key](#azure-ad-join-authentication-to-active-directory-using-a-key)
 - [Azure AD join authentication to Active Directory using a certificate](#azure-ad-join-authentication-to-active-directory-using-a-certificate)
-- [Hybrid Azure AD join authentication using Azure AD Kerberos (cloud trust preview)](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview)
+- [Hybrid Azure AD join authentication using Azure AD Kerberos (cloud Kerberos trust)](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview)
 - [Hybrid Azure AD join authentication using a key](#hybrid-azure-ad-join-authentication-using-a-key)
 - [Hybrid Azure AD join authentication using a certificate](#hybrid-azure-ad-join-authentication-using-a-certificate)
 
@@ -43,7 +43,7 @@ Azure Active Directory-joined devices authenticate to Azure during sign-in and c
 |D | The Cloud AP provider receives the encrypted PRT with session key.  Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
 |E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs winlogon of the success authentication.  Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
 
-## Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud trust preview)
+## Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud Kerberos trust)
 
 ![Azure Active Directory join authentication to Azure AD.](images/howitworks/auth-aadj-cloudtrust-kerb.png)
 
@@ -78,13 +78,13 @@ Azure Active Directory-joined devices authenticate to Azure during sign-in and c
 > [!NOTE]
 > You may have an on-premises domain federated with Azure AD. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Azure AD to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.  
 
-## Hybrid Azure AD join authentication using Azure AD Kerberos (cloud trust preview)
+## Hybrid Azure AD join authentication using Azure AD Kerberos (cloud Kerberos trust)
 
 ![Hybrid Azure AD join authentication using Azure AD Kerberos](images/howitworks/auth-haadj-cloudtrust.png)
 
 | Phase  | Description  |
 | :----: | :----------- |
-|A | Authentication begins when the user dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud trust is enabled. If cloud trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Azure Active Directory. Azure AD returns a nonce.
+|A | Authentication begins when the user dismisses the lock screen, which triggers winlogon to show the Windows Hello for Business credential provider.  The user provides their Windows Hello gesture (PIN or biometrics).  The credential provider packages these credentials and returns them to winlogon.  Winlogon passes the collected credentials to lsass. Lsass queries Windows Hello for Business policy to check if cloud Kerberos trust is enabled. If cloud Kerberos trust is enabled, Lsass passes the collected credentials to the Cloud Authentication security support provider, or Cloud AP. Cloud AP requests a nonce from Azure Active Directory. Azure AD returns a nonce.
 |B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Azure AD.
 |C | Azure AD validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Azure AD then validates the returned signed nonce. After validating the nonce, Azure AD creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Azure AD Kerberos and returns them to Cloud AP.
 |D | Cloud AP  receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT.
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
index 7d93ef16b8..16fa311f93 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
@@ -26,7 +26,7 @@ List of provisioning flows:
 
 - [Azure AD joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
 - [Azure AD joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
-- [Hybrid Azure AD joined provisioning in a cloud trust (preview) deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-trust-preview-deployment-in-a-managed-environment)
+- [Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-trust-deployment-in-a-managed-environment)
 - [Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
 - [Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
 - [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
@@ -62,9 +62,9 @@ List of provisioning flows:
 
 [Return to top](#windows-hello-for-business-provisioning)
 
-## Hybrid Azure AD joined provisioning in a cloud trust (preview) deployment in a managed environment
+## Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment
 
-![Hybrid Azure AD joined provisioning in a cloud trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png)
+![Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png)
 [Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png)
 
 | Phase | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
@@ -74,7 +74,7 @@ List of provisioning flows:
 |   C   | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration.  Azure DRS validates the MFA claim remains current.  On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits.  |
 
 > [!NOTE]
-> Windows Hello for Business Cloud Trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential.
+> Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential.
 
 [Return to top](#windows-hello-for-business-provisioning)
 
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
similarity index 66%
rename from windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md
rename to windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index 95583c6427..f9240f0ff7 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -1,6 +1,6 @@
 ---
-title: Hybrid Cloud Trust Deployment (Windows Hello for Business)
-description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario.
+title: Hybrid cloud Kerberos trust Deployment (Windows Hello for Business)
+description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario.
 ms.prod: m365-security
 author: paolomatarazzo
 ms.author: paoloma
@@ -11,37 +11,39 @@ ms.topic: article
 localizationpriority: medium
 ms.date: 2/15/2022
 appliesto:
-- ✅ <b>Windows 10 21H2 and later</b>
+- ✅ <b>Windows 10, version 21H2 and later</b>
 - ✅ <b>Windows 11</b>
+- ✅ <b>Hybrid deployment</b>
+- ✅ <b>Cloud Kerberos trust</b>
 ---
-# Hybrid Cloud Trust Deployment (Preview)
+# Hybrid Cloud Kerberos Trust Deployment (Preview)
 
-Windows Hello for Business replaces username and password Windows sign-in with strong authentication using an asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario.
+Windows Hello for Business replaces username and password Windows sign-in with strong authentication using an asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario.
 
-## Introduction to Cloud Trust
+## Introduction to Cloud Kerberos Trust
 
-The goal of the Windows Hello for Business cloud trust is to bring the simplified deployment experience of [on-premises SSO with passwordless security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises) to Windows Hello for Business. This deployment model can be used for new Windows Hello for Business deployments or existing deployments can move to this model using policy controls.
+The goal of the Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [on-premises SSO with passwordless security keys](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises) to Windows Hello for Business. This deployment model can be used for new Windows Hello for Business deployments or existing deployments can move to this model using policy controls.
 
-Windows Hello for Business cloud trust uses Azure Active Directory (AD) Kerberos to address pain points of the key trust deployment model:
+Windows Hello for Business cloud Kerberos trust uses Azure Active Directory (AD) Kerberos to address pain points of the key trust deployment model:
 
-- Windows Hello for Business cloud trust provides a simpler deployment experience because it doesn't require the deployment of public key infrastructure (PKI) or changes to existing PKI.
-- Cloud trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate.
-- Deploying Windows Hello for Business cloud trust enables you to also deploy passwordless security keys with minimal extra setup.
+- Windows Hello for Business cloud Kerberos trust provides a simpler deployment experience because it doesn't require the deployment of public key infrastructure (PKI) or changes to existing PKI.
+- cloud Kerberos trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate.
+- Deploying Windows Hello for Business cloud Kerberos trust enables you to also deploy passwordless security keys with minimal extra setup.
 
 > [!NOTE]
-> Windows Hello for Business cloud trust is recommended instead of key trust if you meet the prerequisites to deploy cloud trust. Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios.
+> Windows Hello for Business cloud Kerberos trust is recommended instead of key trust if you meet the prerequisites to deploy cloud Kerberos trust. cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios.
 
-## Azure Active Directory Kerberos and Cloud Trust Authentication
+## Azure Active Directory Kerberos and Cloud Kerberos Trust Authentication
 
-Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD-joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT.
+Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD-joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. cloud Kerberos trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT.
 
 With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and use the returned TGT for logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled by your on-premises AD DCs.
 
 When you enable Azure AD Kerberos in a domain, an Azure AD Kerberos Server object is created in your on-premises AD. This object will appear as a Read Only Domain Controller (RODC) object but isn't associated with any physical servers. This resource is only used by Azure Active Directory to generate TGTs for your Active Directory Domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object.
 
-More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview).
+More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview).
 
-If you're using the hybrid cloud trust deployment model, you _must_ ensure that you have adequate (one or more, depending on your authentication load) Windows Server 2016 or later read-write domain controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.
+If you're using the hybrid cloud Kerberos trust deployment model, you _must_ ensure that you have adequate (one or more, depending on your authentication load) Windows Server 2016 or later read-write domain controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.
 
 ## Prerequisites
 
@@ -51,26 +53,26 @@ If you're using the hybrid cloud trust deployment model, you _must_ ensure that
 | Patched Windows 10 version 21H2 or patched Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices. |
 | Fully patched Windows Server 2016 or later Domain Controllers | Domain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you're using Windows Server 2016, [KB3534307](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e) must be installed. If you're using Server 2019, [KB4534321](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f) must be installed. |
 | Azure AD Kerberos PowerShell module | This module is used for enabling and managing Azure AD Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).|
-| Device management | Windows Hello for Business cloud trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. |
+| Device management | Windows Hello for Business cloud Kerberos trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. |
 
 ### Unsupported Scenarios
 
-The following scenarios aren't supported using Windows Hello for Business cloud trust:
+The following scenarios aren't supported using Windows Hello for Business cloud Kerberos trust:
 
 - On-premises only deployments
 - RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)
 - Scenarios that require a certificate for authentication
-- Using cloud trust for "Run as"
-- Signing in with cloud trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity
+- Using cloud Kerberos trust for "Run as"
+- Signing in with cloud Kerberos trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity
 
 > [!NOTE]
-> The default security policy for AD does not grant permission to sign high privilege accounts on to on-premises resources with Cloud Trust or FIDO2 security keys.
+> The default security policy for AD does not grant permission to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys.
 > 
 > To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,\<domain-DN\>).
 
 ## Deployment Instructions
 
-Deploying Windows Hello for Business cloud trust consists of two steps:
+Deploying Windows Hello for Business cloud Kerberos trust consists of two steps:
 
 1. Set up Azure AD Kerberos in your hybrid environment.
 1. Configure Windows Hello for Business policy and deploy it to devices.
@@ -79,11 +81,11 @@ Deploying Windows Hello for Business cloud trust consists of two steps:
 
 If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Azure AD Kerberos in your hybrid environment. You don't need to redeploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business and you can skip this section.
 
-If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Azure AD](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module) documentation. This page includes information on how to install and use the Azure AD Kerberos Powershell module. Use the module to create an Azure AD Kerberos Server object for the domains where you want to use Windows Hello for Business cloud trust.
+If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Azure AD](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module) documentation. This page includes information on how to install and use the Azure AD Kerberos Powershell module. Use the module to create an Azure AD Kerberos Server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust.
 
 ### Configure Windows Hello for Business Policy
 
-After setting up the Azure AD Kerberos Object, Windows Hello for business cloud trust must be enabled using policy. By default, cloud trust won't be used by Hybrid Azure AD joined or Azure AD-joined devices.
+After setting up the Azure AD Kerberos Object, Windows Hello for business cloud Kerberos trust must be enabled using policy. By default, cloud Kerberos trust won't be used by Hybrid Azure AD joined or Azure AD-joined devices.
 
 #### Configure Using Group Policy
 
@@ -93,14 +95,14 @@ The Enable Windows Hello for Business Group Policy setting is used by Windows to
 
 You can configure the Enable Windows Hello for Business Group Policy setting for computers or users. Deploying this policy setting to computers results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence.
 
-Cloud trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration.
+cloud Kerberos trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration.
 
 > [!NOTE]
 > If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune](/mem/intune/protect/identity-protection-windows-settings) and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources)
 
 ##### Update Group Policy Objects
 
-You may need to update your Group Policy definitions to be able to configure the cloud trust policy. You can copy the ADMX and ADML files from a Windows 10 21H2 or Windows 11 device that supports cloud trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the Passport.admx and Passport.adml files.
+You may need to update your Group Policy definitions to be able to configure the cloud Kerberos trust policy. You can copy the ADMX and ADML files from a Windows 10 21H2 or Windows 11 device that supports cloud Kerberos trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the Passport.admx and Passport.adml files.
 
 You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store).
 
@@ -116,23 +118,23 @@ Sign-in a domain controller or management workstations with *Domain Admin* equiv
 1. In the navigation pane, expand **Policies** under **Device Configuration**.
 1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
 1. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**.
-1. In the content pane, double-click **Use cloud trust for on-premises authentication**. Click **Enable** and click **OK**.
+1. In the content pane, double-click **Use cloud Kerberos trust for on-premises authentication**. Click **Enable** and click **OK**.
 1. *Optional but recommended*: In the content pane, double-click **Use a hardware security device**. Click **Enable** and click **OK**.
 
 This group policy should be targeted at the computer group that you've created for that you want to use Windows Hello for Business.
 
 > [!Important]
-> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud trust have this policy not configured or disabled.
+> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud Kerberos trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud Kerberos trust have this policy not configured or disabled.
 
 #### Configure Using Intune
 
 Windows Hello for Business can be enabled using device enrollment or device configuration policy. Device enrollment policy is only applied at device enrollment time. Any modifications to the configuration in Intune won't apply to already enrolled devices. Device configuration policy is applied after device enrollment. Changes to this policy type in Intune are applied to already enrolled devices.
 
-The cloud trust policy needs to be configured using a custom template and is configured separately from enabling Windows Hello from Business.
+The cloud Kerberos trust policy needs to be configured using a custom template and is configured separately from enabling Windows Hello from Business.
 
 ##### Create a user Group that will be targeted for Windows Hello for Business
 
-If you have an existing group you want to target with Windows Hello for Business cloud trust policy, you can skip this step.
+If you have an existing group you want to target with Windows Hello for Business cloud Kerberos trust policy, you can skip this step.
 
 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
 1. Browse to **Groups** and select **New group**.
@@ -140,13 +142,13 @@ If you have an existing group you want to target with Windows Hello for Business
     1. Group type: "Security"
     1. Group name: "WHFBCloudTrustUsers" or a group name of your choosing
     1. Membership type: Assigned
-1. Select **Members** and add users that you want to target with Windows Hello for Business cloud trust.
+1. Select **Members** and add users that you want to target with Windows Hello for Business cloud Kerberos trust.
 
 You can also create a group through the Azure portal instead of using the Microsoft Endpoint Manager admin center.
 
 ##### Enable Windows Hello for Business
 
-If you already enabled Windows Hello for Business for a target set of users or devices, you can skip below to configuring the cloud trust policy. Otherwise, follow the instructions at [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello) to create a Windows Hello for Business device enrollment policy.
+If you already enabled Windows Hello for Business for a target set of users or devices, you can skip below to configuring the cloud Kerberos trust policy. Otherwise, follow the instructions at [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello) to create a Windows Hello for Business device enrollment policy.
 
 You can also follow these steps to create a device configuration policy instead of a device enrollment policy:
 
@@ -162,25 +164,25 @@ You can also follow these steps to create a device configuration policy instead
 
 1. Select Next to move to **Assignments**.
 1. Under Included groups, select **Add groups**.
-1. Select the user group you would like to use Windows Hello for Business cloud trust. This group may be WHFBCloudTrustUsers or a group of your choosing.
+1. Select the user group you would like to use Windows Hello for Business cloud Kerberos trust. This group may be WHFBCloudTrustUsers or a group of your choosing.
 1. Select Next to move to the Applicability Rules.
 1. Select Next again to move to the **Review + create** tab and select the option to create the policy.
 
 Windows Hello for Business settings are also available in the settings catalog. For more information, see [Use the settings catalog to configure settings on Windows and macOS devices - preview](/mem/intune/configuration/settings-catalog).
 
-##### Configure Cloud Trust policy
+##### Configure Cloud Kerberos Trust policy
 
-To configure the cloud trust policy, follow the steps below:
+To configure the cloud Kerberos trust policy, follow the steps below:
 
 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
 1. Browse to Devices > Windows > Configuration Profiles > Create profile.
 1. For Platform, select Windows 10 and later.
 1. For Profile Type, select **Templates** and select the **Custom** Template.
-1. Name the profile with a familiar name. For example, "Windows Hello for Business cloud trust".
+1. Name the profile with a familiar name. For example, "Windows Hello for Business cloud Kerberos trust".
 1. In Configuration Settings, add a new configuration with the following settings:
 
-    - Name: "Windows Hello for Business cloud trust" or another familiar name
-    - Description: Enable Windows Hello for Business cloud trust for sign-in and on-premises SSO.
+    - Name: "Windows Hello for Business cloud Kerberos trust" or another familiar name
+    - Description: Enable Windows Hello for Business cloud Kerberos trust for sign-in and on-premises SSO.
     - OMA-URI: ./Device/Vendor/MSFT/PassportForWork/*tenant ID*/Policies/UseCloudTrustForOnPremAuth
 
         >[!IMPORTANT]
@@ -193,22 +195,22 @@ To configure the cloud trust policy, follow the steps below:
 
 1. Select Next to navigate to **Assignments**.
 1. Under Included groups, select **Add groups**.
-1. Select the user group you would like to use Windows Hello for Business cloud trust. This group may be WHFBCloudTrustUsers or a group of your choosing.
+1. Select the user group you would like to use Windows Hello for Business cloud Kerberos trust. This group may be WHFBCloudTrustUsers or a group of your choosing.
 1. Select Next to move to the Applicability Rules.
 1. Select Next again to move to the **Review + create** tab and select the option to create the policy.
 
 > [!Important]
-> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud trust have this policy not configured or disabled.
+> If the Use certificate for on-premises authentication policy is enabled, we will enforce certificate trust instead of cloud Kerberos trust on the client. Please make sure that any machines that you want to use Windows Hello for Business cloud Kerberos trust have this policy not configured or disabled.
 
 ## Provisioning
 
-The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud trust adds a prerequisite check for Hybrid Azure AD-joined devices when cloud trust is enabled by policy.
+The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud Kerberos trust adds a prerequisite check for Hybrid Azure AD-joined devices when cloud Kerberos trust is enabled by policy.
 
 You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs\Microsoft\Windows**. This information is also available using the [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) command from a console.  
 
-  ![Cloud trust prerequisite check in the user device registration log](./images/cloud-trust-prereq-check.png)
+  ![cloud Kerberos trust prerequisite check in the user device registration log](./images/cloud-trust-prereq-check.png)
 
-The cloud trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud trust is not being enforced by policy or if the device is Azure AD joined.
+The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust is not being enforced by policy or if the device is Azure AD joined.
 
 This prerequisite check isn't done for provisioning on Azure AD-joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in.
 
@@ -228,11 +230,11 @@ After a successful MFA, the provisioning flow asks the user to create and valida
 
 ### Sign-in
 
-Once a user has set up a PIN with cloud trust, it can be used immediately for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached logon can be used for subsequent unlocks without line of sight or network connectivity.
+Once a user has set up a PIN with cloud Kerberos trust, it can be used immediately for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached logon can be used for subsequent unlocks without line of sight or network connectivity.
 
 ## Troubleshooting
 
-If you encounter issues or want to share feedback about Windows Hello for Business cloud trust, share via the Windows Feedback Hub app by following these steps:
+If you encounter issues or want to share feedback about Windows Hello for Business cloud Kerberos trust, share via the Windows Feedback Hub app by following these steps:
 
 1. Open **Feedback Hub**, and make sure that you're signed in.
 1. Submit feedback by selecting the following categories:
@@ -241,24 +243,24 @@ If you encounter issues or want to share feedback about Windows Hello for Busine
 
 ## Frequently Asked Questions
 
-### Does Windows Hello for Business cloud trust work in my on-premises environment?
+### Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment?
 
 This feature doesn't work in a pure on-premises AD domain services environment.
 
-### Does Windows Hello for Business cloud trust work in a Windows login with RODC present in the hybrid environment?
+### Does Windows Hello for Business cloud Kerberos trust work in a Windows login with RODC present in the hybrid environment?
 
-Windows Hello for Business cloud trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud trust will work.
+Windows Hello for Business cloud Kerberos trust looks for a writeable DC to exchange the partial TGT. As long as you have at least one writeable DC per site, login with cloud Kerberos trust will work.
 
-### Do I need line of sight to a domain controller to use Windows Hello for Business cloud trust?
+### Do I need line of sight to a domain controller to use Windows Hello for Business cloud Kerberos trust?
 
-Windows Hello for Business cloud trust requires line of sight to a domain controller for some scenarios:
+Windows Hello for Business cloud Kerberos trust requires line of sight to a domain controller for some scenarios:
 - The first sign-in or unlock with Windows Hello for Business after provisioning on a Hybrid Azure AD joined device
 - When attempting to access an on-premises resource from an Azure AD joined device
 
-### Can I use RDP/VDI with Windows Hello for Business cloud trust?
+### Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust?
 
-Windows Hello for Business cloud trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud trust can be used for RDP with [remote credential guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
+Windows Hello for Business cloud Kerberos trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [remote credential guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
 
-### Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud trust?
+### Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust?
 
-No, only the number necessary to handle the load from all cloud trust devices.
+No, only the number necessary to handle the load from all cloud Kerberos trust devices.
diff --git a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
index f62e08bd4d..0ae2e88df1 100644
--- a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
+++ b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
@@ -31,7 +31,7 @@ This article lists the infrastructure requirements for the different deployment
 
 The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for business components or is involved in the Kerberos referral process.
 
-| Requirement | Cloud trust (Preview)<br/>Group Policy or Modern managed | Key trust<br/>Group Policy or Modern managed | Certificate trust<br/>Mixed managed | Certificate trust<br/>Modern managed | 
+| Requirement | cloud Kerberos trust<br/>Group Policy or Modern managed | Key trust<br/>Group Policy or Modern managed | Certificate Trust<br/>Mixed managed | Certificate Trust<br/>Modern managed | 
 | --- | --- | --- | --- | --- |
 | **Windows Version** | Windows 10, version 21H2 with KB5010415; Windows 11 with KB5010414; or later | Windows 10, version 1511 or later| **Hybrid Azure AD Joined:**<br>  *Minimum:* Windows 10, version 1703<br>  *Best experience:* Windows 10, version 1709 or later (supports synchronous certificate enrollment).<br/>**Azure AD Joined:**<br>  Windows 10, version 1511 or later| Windows 10, version 1511 or later |
 | **Schema Version** | No specific Schema requirement | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema |
@@ -44,7 +44,7 @@ The table shows the minimum requirements for each deployment. For key trust in a
 | **Azure AD License** | Azure AD Premium, optional | Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional. Intune license required |
 
 > [!Important]
-> - Hybrid deployments support non-destructive PIN reset that works with certificate trust, key trust and cloud trust models.
+> - Hybrid deployments support non-destructive PIN reset that works with Certificate Trust, Key Trust and cloud Kerberos trust models.
 >
 >   **Requirements:**
 >   - Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement for this service since version 1903
diff --git a/windows/security/identity-protection/hello-for-business/hello-overview.md b/windows/security/identity-protection/hello-for-business/hello-overview.md
index 6a355853aa..1981ba37e3 100644
--- a/windows/security/identity-protection/hello-for-business/hello-overview.md
+++ b/windows/security/identity-protection/hello-for-business/hello-overview.md
@@ -94,9 +94,9 @@ For details, see [How Windows Hello for Business works](hello-how-it-works.md).
 
 ## Comparing key-based and certificate-based authentication
 
-Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud trust for hybrid deployments, which uses Azure AD as the root of trust. Cloud trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
+Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Azure AD as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
 
-Windows Hello for Business with a key, including cloud trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
+Windows Hello for Business with a key, including cloud Kerberos trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
 
 ## Learn more
 
diff --git a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
index c1dc768999..32137c8e75 100644
--- a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
+++ b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md
@@ -93,7 +93,7 @@ It's fundamentally important to understand which deployment model to use for a s
 A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory.  There are two trust types: key trust and certificate trust.
 
 > [!NOTE]
-> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). More information will be available on Windows Hello for Business cloud trust once it is generally available.
+> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). For more information, see ./hello-hybrid-cloud-kerberos-trust.md.
 
 The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
 
diff --git a/windows/security/identity-protection/hello-for-business/index.yml b/windows/security/identity-protection/hello-for-business/index.yml
index a0fa9d6144..3907b4b422 100644
--- a/windows/security/identity-protection/hello-for-business/index.yml
+++ b/windows/security/identity-protection/hello-for-business/index.yml
@@ -65,8 +65,8 @@ landingContent:
             url: hello-identity-verification.md
       - linkListType: how-to-guide
         links:
-          - text: Hybrid Cloud Trust Deployment
-            url: hello-hybrid-cloud-trust.md
+          - text: Hybrid Cloud Kerberos Trust Deployment
+            url: hello-hybrid-cloud-kerberos-trust.md
           - text: Hybrid Azure AD Joined Key Trust Deployment
             url: hello-hybrid-key-trust.md
           - text: Hybrid Azure AD Joined Certificate Trust Deployment
diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml
index 6e71a47657..2c22050ab0 100644
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@@ -35,8 +35,8 @@
     href: hello-prepare-people-to-use.md
   - name: Deployment Guides
     items:
-    - name: Hybrid Cloud Trust Deployment
-      href: hello-hybrid-cloud-trust.md
+    - name: Hybrid Cloud Kerberos Trust Deployment
+      href: hello-hybrid-cloud-kerberos-trust.md
     - name: Hybrid Azure AD Joined Key Trust
       items: 
       - name: Hybrid Azure AD Joined Key Trust Deployment

From d85dbde1313d15a9192411718a0f7e5dda3231a1 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Mon, 19 Sep 2022 17:57:44 -0400
Subject: [PATCH 4/5] updates

---
 .../hello-for-business/hello-how-it-works-authentication.md   | 4 ++--
 .../hello-for-business/hello-how-it-works-provisioning.md     | 2 +-
 .../hello-for-business/hello-hybrid-cloud-kerberos-trust.md   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
index e1c3b1c5d2..ffaec80712 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
@@ -21,10 +21,10 @@ Windows Hello for Business authentication is passwordless, two-factor authentica
 Azure Active Directory-joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
 
 - [Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory)
-- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud Kerberos trust)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-trust-preview)
+- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud Kerberos trust)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-kerberos-trust)
 - [Azure AD join authentication to Active Directory using a key](#azure-ad-join-authentication-to-active-directory-using-a-key)
 - [Azure AD join authentication to Active Directory using a certificate](#azure-ad-join-authentication-to-active-directory-using-a-certificate)
-- [Hybrid Azure AD join authentication using Azure AD Kerberos (cloud Kerberos trust)](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview)
+- [Hybrid Azure AD join authentication using Azure AD Kerberos (cloud Kerberos trust)](#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-kerberos-trust)
 - [Hybrid Azure AD join authentication using a key](#hybrid-azure-ad-join-authentication-using-a-key)
 - [Hybrid Azure AD join authentication using a certificate](#hybrid-azure-ad-join-authentication-using-a-certificate)
 
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
index 16fa311f93..6ebf241107 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
@@ -26,7 +26,7 @@ List of provisioning flows:
 
 - [Azure AD joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment)
 - [Azure AD joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment)
-- [Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-trust-deployment-in-a-managed-environment)
+- [Hybrid Azure AD joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment)
 - [Hybrid Azure AD joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
 - [Hybrid Azure AD joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
 - [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index f9240f0ff7..6f30c162c6 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -41,7 +41,7 @@ With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domai
 
 When you enable Azure AD Kerberos in a domain, an Azure AD Kerberos Server object is created in your on-premises AD. This object will appear as a Read Only Domain Controller (RODC) object but isn't associated with any physical servers. This resource is only used by Azure Active Directory to generate TGTs for your Active Directory Domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object.
 
-More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-trust-preview).
+More details on how Azure AD Kerberos enables access to on-premises resources are available in our documentation on [enabling passwordless security key sign-in to on-premises resources](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). There's more information on how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust in the [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-kerberos-trust).
 
 If you're using the hybrid cloud Kerberos trust deployment model, you _must_ ensure that you have adequate (one or more, depending on your authentication load) Windows Server 2016 or later read-write domain controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.
 

From 189363cb382f7e3c87e862879d546e0984167616 Mon Sep 17 00:00:00 2001
From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com>
Date: Mon, 19 Sep 2022 18:10:13 -0400
Subject: [PATCH 5/5] Update hello-hybrid-cloud-kerberos-trust.md

---
 .../hello-for-business/hello-hybrid-cloud-kerberos-trust.md     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
index 6f30c162c6..4af8090b66 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@@ -27,7 +27,7 @@ The goal of the Windows Hello for Business cloud Kerberos trust is to bring the
 Windows Hello for Business cloud Kerberos trust uses Azure Active Directory (AD) Kerberos to address pain points of the key trust deployment model:
 
 - Windows Hello for Business cloud Kerberos trust provides a simpler deployment experience because it doesn't require the deployment of public key infrastructure (PKI) or changes to existing PKI.
-- cloud Kerberos trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate.
+- Cloud Kerberos trust doesn't require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This change means there isn't a delay between the user provisioning and being able to authenticate.
 - Deploying Windows Hello for Business cloud Kerberos trust enables you to also deploy passwordless security keys with minimal extra setup.
 
 > [!NOTE]