diff --git a/docs/identity/monitoring-health/concept-sign-in-log-activity-details.md b/docs/identity/monitoring-health/concept-sign-in-log-activity-details.md
index 15070f33040..f867902cb3c 100644
--- a/docs/identity/monitoring-health/concept-sign-in-log-activity-details.md
+++ b/docs/identity/monitoring-health/concept-sign-in-log-activity-details.md
@@ -159,7 +159,7 @@ The following scenarios are important to consider when you're reviewing sign-in
 
 - **Multifactor authentication:** When a user signs in with MFA, several separate MFA events are actually taking place. For example, if a user enters the wrong validation code or doesn't respond in time, more MFA events are sent to reflect the latest status of the sign-in attempt. These sign-in events appear as one line item in the Microsoft Entra sign-in logs. That same sign-in event in Azure Monitor, however, appears as multiple line items. These events all have the same `correlationId`.
 
-- **Authentication requirement:** Shows the authentication requirement requested by the resource provider for the sign-in to succeed. This value commonly reflects the authentication stage reached during the sign-in.
+- **Authentication requirement:** Shows the authentication methods which were performed at sign-in. This value commonly reflects the authentication stage reached during the sign-in.
   - A subsequent sign-in attempt after the failure where primary authentication is successful and MFA is required, the value is `multiFactorAuthentication`.
   - There are some edge cases where this field doesn't reflect the authentication reached during the sign-in. For example, if the requirement is already fulfilled from a previous MFA claim the resource provider doesn't ask to enforce it. 
   - For sign-in attempts where MFA is required but primary authentication failed, value is `singleFactorAuthentication` because the attempt wasn't evaluated by Conditional Access to require MFA.