update cloud trust background section

windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md

@@ -46,7 +46,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
+## Azure AD join authentication to Active Directory using Azure AD Kerberos (Cloud Trust)
 
 ![Azure AD join authentication to Azure Active Directory.](images/howitworks/auth-aadj-cloudtrust-kerb.png)
 
@@ -81,7 +81,7 @@ 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
+## Hybrid Azure AD join authentication using Azure AD Kerberos (Cloud Trust)
 
 ![Hybrid Azure AD join authentication using Azure AD Kerberos](images/howitworks/auth-haadj-cloudtrust.png)
 

windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md

@@ -19,20 +19,20 @@ ms.reviewer:
 # Hybrid Azure AD joined Windows Hello for Business Certificate Trust Provisioning
 
 **Applies to**
--   Windows 10, version 1703 or later
--   Windows 11
--   Hybrid deployment
--   Certificate trust
 
+- Windows 10, version 1703 or later
+- Windows 11
+- Hybrid deployment
+- Certificate trust
 
 ## Provisioning
+
 The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop.  Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
 
 ![Event358 from User Device Registration log showing Windows Hello for Business prerequisite check result.](images/Event358.png)
 
 The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears.  Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
 
-
 Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name.  The user clicks **Setup a PIN**.
 
 ![Setup a PIN Provisioning.](images/setupapin.png)
@@ -46,10 +46,11 @@ After a successful MFA, the provisioning flow asks the user to create and valida
 ![Create a PIN during provisioning.](images/createPin.png)
 
 The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
-* A successful single factor authentication (username and password at sign-in)
-* A device that has successfully completed device registration
-* A fresh, successful multi-factor authentication
-* A validated PIN that meets the PIN complexity requirements
+
+- A successful single factor authentication (username and password at sign-in)
+- A device that has successfully completed device registration
+- A fresh, successful multi-factor authentication
+- A validated PIN that meets the PIN complexity requirements
 
 The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key.  AAD Connect synchronizes the user's key to the on-premises Active Directory.
 
@@ -77,6 +78,7 @@ The certificate authority validates the certificate was signed by the registrati
 <hr>
 
 ## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+
 1. [Overview](hello-hybrid-cert-trust.md)
 2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
 3. [New Installation Baseline](hello-hybrid-cert-new-install.md)

windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md

@@ -21,7 +21,7 @@ ms.reviewer:
 Applies to
 
 - Windows 10, version 21H2
-- Windows 11
+- Windows 11 and later
 
 Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario.
 
@@ -31,39 +31,50 @@ The goal of the Windows Hello for Business cloud trust deployment model is to br
 
 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 trust provides a simpler deployment experience because it does not require the deployment or modification of public key infrastructure.
+- Windows Hello for Business cloud trust provides a simpler deployment experience because it does not require the deployment of public key infrastructure (PKI) or changes to existing PKI.
+- Cloud trust does not require syncing of public keys between Azure AD and on-premises domain controllers (DCs) for users to access on-premises resources and applications. This 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 additional setup.
-- Cloud trust does not require syncing of public keys between Azure AD and on-premises domain controllers (DCs) before users can use their Windows Hello for Business credential on-premises.
 
 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.
 
 ## Azure Active Directory Kerberos and Cloud Trust Authentication
 
-With Azure AD Kerberos, Azure AD can issue Kerberos ticket-granting-tickets (TGTs) for one or more of your AD domains. Using this functionality, Windows can request TGTs from Azure AD when authenticating using Windows Hello for Business and then use them for logon or to access traditional Active Directory-based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises Active Directory DCs.
+Key trust and certificate trust authentication use kerberos based smart card/certificate authentication for requesting kerberos ticket-granting-tickets (TGTs) from a domain controller for on-premises authentication. This type of authentication requires PKI for domain controller certificates, and requires end-user certificates for certificate trust. For single sign-on (SSO) to on-premises resources from Azure AD joined devices, additional PKI configuration is needed to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos which does not require any of the above PKI to get the user a TGT.
 
-For more details on how Authentication with Windows Hello for Business Cloud Trust works see the [Windows Hello for Business Authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos).
+With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Using this functionality, Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and then 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 is not 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 is also additional information on how this 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).
 
 ## Prerequisites
 
 | Requirement | Notes |
 | --- | --- |
-| Multi-factor Authentication | This requirement can be met using [Azure AD Multi-Factor Authentication](howto-mfa-getstarted.md), multi-factor authentication provided through AD FS, or a comparable solution |
-| Windows 10 version 21H2 or higher | There is no Windows version support difference between Azure AD joined and Hybrid Azure AD joined devices. |
-| Windows Server 2016 or later Domain Controllers | These should be fully patched to support updates needed for Azure AD Kerberos. |
-| Azure AD Connect version 1.4.32.0 or later | This version packages the tools for setting up Azure AD Kerberos |
+| Multi-factor Authentication | This requirement can be met using [Azure AD Multi-Factor Authentication](/azure/active-directory/authentication/howto-mfa-getstarted.md), multi-factor authentication provided through AD FS, or a comparable solution. |
+| Windows 10 version 21H2 or Windows 11 and later | There is no Windows version support difference between Azure AD joined and Hybrid Azure AD joined devices. |
+| Windows Server 2016 or later Domain Controllers | These should be fully patched to support updates needed for Azure AD Kerberos.|
+| Azure AD Connect version 1.4.32.0 or later | This version packages the tools for setting up Azure AD Kerberos. Alternatively the required tools can be installed from powershell gallery. |
 | Device management | Windows Hello for Business cloud trust can be managed with group policy or through Microsoft Intune. |
 
 ### Unsupported Scenarios
 
+The following scenarios are not supported using Windows Hello for Business cloud trust.
+
+-
+
 ## Deployment Instructions
 
-Deploying Windows Hello for Business cloud trust consists of two steps. First, you will need to deploy Azure AD Kerberos in your hybrid environment. Second, you will need to configure Windows Hello for Business policy and deploy that devices you wish to use Windows Hello for Business.
+Deploying Windows Hello for Business cloud trust consists of two steps:
 
-If you have already deployed [on-premises SSO for passwordless security key sign-in](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises), then you will have already deployed Azure AD Kerberos in your hybrid environment. You do not need to re-deploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business.
+1. Azure AD Kerberos in your hybrid environment. 
+1. Configure Windows Hello for Business policy and deploy it to devices you wish to use Windows Hello for Business.
 
 ### Deploy Azure AD Kerberos
 
+If you have already deployed [on-premises SSO for passwordless security key sign-in](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises), then you have already deployed Azure AD Kerberos in your hybrid environment. You do not need to re-deploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business and you can skip this section.
 
+If you have 
 
 ### Configure Windows Hello for Business