Merge pull request #249159 from Justinha/sif-strength

Update concept-authentication-strengths.md

Author: prmerger-automator[bot]

articles/active-directory/authentication/concept-authentication-strengths.md

@@ -6,12 +6,12 @@ services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 06/02/2023
+ms.date: 08/23/2023
 
 ms.author: justinha
 author: justinha
 manager: amycolannino
-ms.reviewer: michmcla, inbarckms
+ms.reviewer: inbarckms
 
 ms.collection: M365-identity-device-management
 ---
@@ -225,22 +225,31 @@ An authentication strength Conditional Access policy works together with [MFA tr
 
 ## Limitations
 
-- **Conditional Access policies are only evaluated after the initial authentication** -  As a result, authentication strength doesn't restrict a user's initial authentication. Suppose you are using the built-in phishing-resistant MFA strength. A user can still type in their password, but they will be required to use a phishing-resistant method such as FIDO2 security key before they can continue.
+- **Conditional Access policies are only evaluated after the initial authentication** - As a result, authentication strength doesn't restrict a user's initial authentication. Suppose you are using the built-in phishing-resistant MFA strength. A user can still type in their password, but they will be required to use a phishing-resistant method such as FIDO2 security key before they can continue.
 
 - **Require multifactor authentication and Require authentication strength can't be used together in the same Conditional Access policy** - These two Conditional Access grant controls can't be used together because the built-in authentication strength **Multifactor authentication** is equivalent to the **Require multifactor authentication** grant control.
 
 - **Authentication methods that aren't currently supported by authentication strength** - The **Email one-time pass (Guest)** authentication method isn't included in the available combinations.
 
 - **Windows Hello for Business** – If the user signed in with Windows Hello for Business as their primary authentication method, it can be used to satisfy an authentication strength requirement that includes Windows Hello for Business. But if the user signed in with another method like password as their primary authenticating method, and the authentication strength requires Windows Hello for Business, they get prompted to sign in with Windows Hello for Business. 
 
+
+## Known isssues
+
+The following known issues are currently being addressed:
+
+- **Sign-in frequency** - If both sign-in frequency and authentication strength requirements apply to a sign-in, and the user has previously signed in using a method that meets the authentication strength requirements, the sign-in frequency requirement doesn't apply. [Sign-in frequency](concepts-azure-multi-factor-authentication-prompts-session-lifetime.md) allows you to set the time interval for re-authentication of users based on their credentials, but it isn't fully integrated with authentication strength yet. It works independently and doesn't currently impact the actual sign-in procedure. Therefore, you may notice that some sign-ins using expired credentials don't prompt re-authentication and the sign-in process proceeds successfully.
+
+- **FIDO2 security key Advanced options** - Advanced options aren't supported for external users with a home tenant that is located in a different Microsoft cloud than the resource tenant.
+
 ## FAQ
 
 ### Should I use authentication strength or the Authentication methods policy?
 Authentication strength is based on the Authentication methods policy. The Authentication methods policy helps to scope and configure authentication methods to be used across Azure AD by specific users and groups. Authentication strength allows another restriction of methods for specific scenarios, such as sensitive resource access, user risk, location, and more.
 
 For example, the administrator of Contoso wants to allow their users to use Microsoft Authenticator with either push notifications or passwordless authentication mode. The administrator goes to the Microsoft Authenticator settings in the Authentication method policy, scopes the policy for the relevant users and set the **Authentication mode** to **Any**. 
 
-Then for Contoso’s most sensitive resource, the administrator wants to restrict the access to only passwordless authentication methods. The administrator creates a new Conditional Access policy, using the built-in **Passwordless MFA strength**. 
+Then for Contoso's most sensitive resource, the administrator wants to restrict the access to only passwordless authentication methods. The administrator creates a new Conditional Access policy, using the built-in **Passwordless MFA strength**. 
 
 As a result, users in Contoso can access most of the resources in the tenant using password + push notification from the Microsoft Authenticator OR only using Microsoft Authenticator (phone sign-in). However, when the users in the tenant access the sensitive application, they must use Microsoft Authenticator (phone sign-in).