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 8f124ea552..eb1d1585c6 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
@@ -51,7 +51,8 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
 |B | The Kerberos provider sends the signed pre-authentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.<br>The 2016 domain controller determines the certificate is a self-signed certificate.  It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory.  It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed pre-authentication data using the public key from Active Directory.  On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.|
 |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device.  Next, it ensures the certificate is within its validity period and that it has not be revoked.  The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it is cached and used for subsequent service ticket requests.|
 
-!Note: You may have on-prem domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on the AADJ device. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT as well as it trigger authenticate against your DC (if LOS to DC available) to get kerberos.it no longer use ADFS to authenticate for WHFB signins.
+> [!NOTE]
+> You may have on-premises domain Federated with Azure AD. Once user successfully provisioned WHFB PIN/Bio on the AADJ device. Any future login of WHFB (PIN/Bio) sign-in will directly authenticate against AAD to get PRT, as well as it trigger authenticate against your DC (if LOS to DC available) to get Kerberos. It no longer uses ADFS to authenticate for WHFB sign-ins.
 
 
 ## Azure AD join authentication to Active Directory using a Certificate