Add sequence diagrams for provisioning flows

windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-enroll.md

@@ -120,6 +120,19 @@ The CA validates that the certificate is signed by the registration authority. O
 > [!NOTE]
 > Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users don't need to wait for Microsoft Entra Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers.
 
+### Sequence diagrams
+
+To better understand the provisioning flows, review the following sequence diagrams based on the device join and authentication type:
+
+- [Microsoft Entra joined provisioning in a managed environment](../how-it-works-provisioning.md#microsoft-entra-joined-provisioning-in-a-managed-environment)
+- [Microsoft Entra joined provisioning in a federated environment](../how-it-works-provisioning.md#microsoft-entra-joined-provisioning-in-a-federated-environment)
+- [Microsoft Entra hybrid joined provisioning in a certificate trust deployment in a federated environment](../how-it-works-provisioning.md#microsoft-entra-hybrid-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment)
+
+To better understand the authentication flows, review the following sequence diagram:
+
+- [Microsoft Entra join authentication to Active Directory using a certificate](../how-it-works-authentication.md#microsoft-entra-join-authentication-to-active-directory-using-a-certificate)
+- [Microsoft Entra hybrid join authentication using a certificate](../how-it-works-authentication.md#microsoft-entra-hybrid-join-authentication-using-a-certificate)
+
 <!--links-->
 
 [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd

windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-enroll.md

@@ -94,6 +94,19 @@ After enrollment, Microsoft Entra Connect synchronizes the user's key from Micro
 > **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and access on-premises resources.
 > Read [Microsoft Entra Connect Sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization.
 
+### Sequence diagrams
+
+To better understand the provisioning flows, review the following sequence diagrams based on the device join and authentication type:
+
+- [Microsoft Entra joined provisioning in a managed environment](../how-it-works-provisioning.md#microsoft-entra-joined-provisioning-in-a-managed-environment)
+- [Microsoft Entra joined provisioning in a federated environment](../how-it-works-provisioning.md#microsoft-entra-joined-provisioning-in-a-federated-environment)
+- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](../how-it-works-provisioning.md#microsoft-entra-hybrid-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment)
+
+To better understand the authentication flows, review the following sequence diagram:
+
+- [Microsoft Entra hybrid join authentication using a key](../how-it-works-authentication.md#microsoft-entra-hybrid-join-authentication-using-a-key)
+- [Microsoft Entra join authentication to Active Directory using a key](../how-it-works-authentication.md#microsoft-entra-join-authentication-to-active-directory-using-a-key)
+
 <!--links-->
 [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd
 [AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler

windows/security/identity-protection/hello-for-business/deploy/includes/user-experience.md

@@ -9,4 +9,4 @@ After a user signs in, the Windows Hello for Business enrollment process begins:
 1. The user is prompted to use Windows Hello with the organization account. The user selects **OK**
 1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry
 1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device
-1. 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 Microsoft Entra ID to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and access their desktop
+1. 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 the IdP to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and access their desktop

windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-enroll.md

@@ -69,5 +69,17 @@ This information is also available using the `dsregcmd.exe /status` command from
 
 [!INCLUDE [user-experience](includes/user-experience.md)]
 
+After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows sends the certificate request to the AD FS server for certificate enrollment.
+
+The AD FS registration authority verifies the key used in the certificate request matches the key that was previously registered. On a successful match, the AD FS registration authority signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
+
+The CA validates that the certificate is signed by the registration authority. On successful validation, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Action Center.
+
+### Sequence diagram
+
+To better understand the provisioning flows, review the following sequence diagram:
+
+- [Domain joined provisioning in an On-premises Certificate Trust deployment](../how-it-works-provisioning.md#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment)
+
 <!--links-->
 [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd

windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-enroll.md

@@ -52,5 +52,10 @@ This information is also available using the `dsregcmd.exe /status` command from
 
 [!INCLUDE [user-experience](includes/user-experience.md)]
 
-<!--links-->
+### Sequence diagram
+
+To better understand the provisioning flows, review the following sequence diagram:
+
+- [Domain joined provisioning in an On-premises Key Trust deployment](../how-it-works-provisioning.md#domain-joined-provisioning-in-an-on-premises-key-trust-deployment)
+
 [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd

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

@@ -147,8 +147,8 @@ Access to the key material stored in the container, is enabled only by the PIN o
 A container can contain several types of key material:
 
 - An *authentication key*, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key is generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key
-- One or multiple *user ID keys*. These keys can be either symmetric or asymmetric, depending on which IdP you use. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the user ID key or key pair can request access. User ID keys are used to sign or encrypt authentication requests or tokens sent from this device to the IdP. User ID keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IdP (which stores it for later verification), and securely stores the private key. For enterprises, the user ID keys can be generated in two ways:
-  - The user ID key pair can be associated with an enterprise Certificate Authority (CA). This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store other certificates in the protected container. For example, an enterprise might want to store a certificate that allows the user to authenticate via RDP
+- One or multiple *user ID keys*. These keys can be either symmetric or asymmetric, depending on which IdP you use. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the user ID key or key pair can request access. User ID keys are used to sign or encrypt authentication requests or tokens sent from this device to the IdP. User ID keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IdP (which stores it for later verification), and securely stores the private key. For organizatrons, the user ID keys can be generated in two ways:
+  - The user ID key pair can be associated with an organization's Certificate Authority (CA). This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the organization to store other certificates in the protected container. For example, certificates that allows the user to authenticate via RDP
   - The IdP can generate the user ID key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI
 
 User ID keys are used to authenticate the user to a service. For example, by signing a nonce to prove possession of the private key, which corresponds to a registered public key. Users with an Active Directory, Microsoft Entra ID or Microsoft account have a key associated with their account. The key can be used to sign into their Windows device by authenticating to a domain controller (Active Directory scenario), or to the cloud (Microsoft Entra ID and MSA scenarios).