Audit Logs / Microsoft Entra ID AuditLogs category
Audit Logs: Authentication
| OperationName | Description | Sample | Rule |
|---|---|---|---|
| A self-service sign-up request was completed | A user completed an Azure AD B2C self-service sign-up user flow for a new consumer account. | N | N |
| Add a group to feature rollout | A group was added to a staged-rollout policy, enabling a cloud-auth feature (PHS/PTA/seamless SSO) for its members. | N | N |
| Add user to feature rollout | Adds a user to a Staged Rollout group for cloud authentication (password hash sync, pass-through auth, or seamless SSO). | N | N |
| An API was called as part of a user flow | An Azure AD B2C user flow invoked an external REST API (API connector) during the user journey. | N | N |
| Create rollout policy for feature | Creation of a staged feature rollout policy (e.g., cloud auth or seamless SSO) targeting selected user groups. | Y | N |
| Delete all available strong authentication devices | All of a user's registered strong authentication (MFA) devices were deleted (B2C). | N | N |
| Delete rollout policy of feature | Deletion of a staged-rollout policy that scopes a cloud-auth feature (PHS/PTA/seamless SSO/CBA) to groups. | Y | N |
| Evaluate Conditional Access policies | Records Azure AD B2C evaluating Conditional Access policies during a sign-in, yielding the grant decision applied. | N | N |
| Exchange token | Records a token exchange in an Azure AD B2C sign-in flow, under the Authentication category covering credential validation and token issuance. | N | N |
| Federate with an identity provider | Azure AD B2C federated with an external identity provider for sign-in. | N | N |
| Get available strong authentication devices | A read returned the available strong authentication (MFA) devices or methods in the Azure AD B2C directory. | N | N |
| Issue a SAML assertion to the application | Azure AD B2C issued a SAML assertion (token) to a relying-party application after sign-in. | N | N |
| Issue an access token to the application | Azure AD B2C issued an OAuth2/OIDC access token to an application after sign-in. | N | N |
| Issue an authorization code to the application | Azure AD B2C issued an OAuth2 authorization code to an application (authorization code flow). | N | N |
| Issue an id_ | Azure AD B2C issued an id_token to an application, concluding a successful user sign-in (token issuance). | N | N |
| Make phone call to verify phone number | Azure AD B2C placed an automated voice call to verify a user's phone number for phone-based MFA. | N | N |
| Register TOTP secret | A TOTP authenticator secret was registered for an Azure AD B2C user during MFA enrollment. | N | N |
| Remediate user | An Azure AD B2C user met a Conditional Access grant requirement, reported to Identity Protection to lower user risk. | N | N |
| Remove a group from feature rollout | A group was removed from a staged feature rollout policy, ending its inclusion in the gradual feature rollout. | N | N |
| Remove user from feature rollout | A user was removed from a Staged Rollout feature rollout policy, reverting their sign-in to the prior authentication method. | N | N |
| Send SMS to verify phone number | Azure AD B2C sent an SMS verification code to confirm a user's phone number during a B2C user flow. | N | N |
| Send verification email | Azure AD B2C sent a verification email with a one-time passcode to confirm a user's email address. | N | N |
| Test audit log | A synthetic test entry written to the directory audit log (audit-pipeline verification, not a real action). | N | N |
| Update rollout policy of feature | A staged-rollout feature policy was updated, changing which groups have a cloud-authentication feature enabled. | N | N |
| User confirmed unusual sign-in event as legitimate | User confirmed a flagged unusual sign-in as their own legitimate activity. | N | N |
| User reported unusual sign-in event as not legitimate | User reported a flagged unusual sign-in as not theirs (possible account compromise). | N | N |
| Validate Client Credentials | Validates an app's client credentials in the Azure AD B2C OAuth 2.0 client credentials flow (app-only, no user). | N | N |
| Validate local account credentials | Validation of a B2C local account's credentials (username/email + password) at sign-in; failures can signal password spray. | N | N |
| Validate user authentication | Validation of a user's authentication within a B2C user flow or policy before token issuance. | Y | N |
| Verify email address | Verification that a user controls an email address via an emailed one-time code (sign-up or recovery). | N | N |
| verify one time password | Verification of a user-submitted one-time passcode (OTP VerifyCode), enforcing code expiry and retry limits. | N | N |
| Verify phone number | Verification that a user controls a phone number via a one-time passcode sent by text message (SMS). | N | N |
A self-service sign-up request was completed
#Description
A user completed a self-service sign-up user flow in Azure AD B2C (a B2C sign-up policy), finishing the sign-up for a new consumer account. High volumes or anomalous bursts of this operation can indicate automated fake-account creation or sign-up abuse.
References #
Add a group to feature rollout
#Description
A group was added to a staged-rollout (feature rollout) policy, enabling a cloud-authentication feature such as password hash synchronization, pass-through authentication, or seamless single sign-on for that group's members on an otherwise federated domain. Moving users onto managed cloud authentication changes which authentication path and controls apply to them.
References #
Add user to feature rollout
#Description
Records adding a user, typically through a group, to a Staged Rollout feature for cloud authentication. This enables the user for managed cloud authentication (password hash sync, pass-through authentication, or seamless SSO) ahead of converting a federated domain, so it changes how that user authenticates.
References #
An API was called as part of a user flow
#Description
Records that an Azure AD B2C user flow or custom policy invoked an external REST API (an API connector or RESTful technical profile) during the user journey, for example to validate input or enrich claims before token issuance.
References #
Create rollout policy for feature
#Description
Records the creation of a feature rollout (staged rollout) policy that gradually enables a feature, such as cloud authentication (password hash sync or pass-through authentication) or seamless SSO, for selected groups of users migrating from federation. Because it changes how affected users authenticate, an unexpected rollout policy is security-relevant.
Example Audit Log Entry #
{
"AADOperationType": "Update",
"AADTenantId": "11111111-1111-1111-1111-111111111111",
"ActivityDateTime": "2026-07-24T03:21:01.1282809Z",
"ActivityDisplayName": "Create rollout policy for feature",
"AdditionalDetails": [],
"Category": "Authentication",
"CorrelationId": "1ac677e8-6151-4125-bbc9-b0f5c5cceb56",
"DurationMs": "0",
"Id": "Application Proxy_1ac677e8-6151-4125-bbc9-b0f5c5cceb56_9DSBB_2392191",
"InitiatedBy": {
"user": {
"id": "aaaaaaaa-0000-0000-0000-000000000001",
"displayName": null,
"userPrincipalName": "adminuser@example.onmicrosoft.com",
"ipAddress": null,
"roles": [],
"agentType": "notAgentic"
}
},
"LoggedByService": "Application Proxy",
"OperationName": "Create rollout policy for feature",
"OperationVersion": "1.0",
"Resource": "Microsoft.aadiam",
"ResourceGroup": "Microsoft.aadiam",
"ResourceId": "/tenants/11111111-1111-1111-1111-111111111111/providers/Microsoft.aadiam",
"Result": "success",
"ResultSignature": "None",
"TargetResources": [
{
"id": "e03b9fad-970b-442a-9825-68dde533c1c0",
"displayName": "dw-harness-fr-cf516524",
"type": "Policy",
"modifiedProperties": [
{
"displayName": "Feature",
"oldValue": "\"\"",
"newValue": "\"PasswordHashSync\""
},
{
"displayName": "Enabled",
"oldValue": "\"\"",
"newValue": "\"False\""
}
],
"administrativeUnits": [],
"agentType": "notAgentic"
}
]
}
References #
Delete all available strong authentication devices
#Description
All of a user's registered strong authentication (multifactor) devices were deleted in the Azure AD B2C tenant. Clearing a user's strong authentication registrations resets their MFA enrollment, which can be legitimate help-desk remediation or a precursor to account takeover and MFA defense evasion.
References #
Delete rollout policy of feature
#Description
Records the deletion of a staged rollout (feature rollout) policy that selectively enables a cloud-authentication feature such as password hash sync, pass-through authentication, seamless SSO, or certificate-based authentication for targeted groups during migration from federation. Changes affect which users authenticate in the cloud versus on-premises.
Example Audit Log Entry #
{
"AADOperationType": "Delete",
"AADTenantId": "11111111-1111-1111-1111-111111111111",
"ActivityDateTime": "2026-07-24T03:21:03.1599348Z",
"ActivityDisplayName": "Delete rollout policy of feature",
"AdditionalDetails": [],
"Category": "Authentication",
"CorrelationId": "ae65ecfa-769c-4b96-9b8e-2a26c4d2da19",
"DurationMs": "0",
"Id": "Application Proxy_ae65ecfa-769c-4b96-9b8e-2a26c4d2da19_6GJHP_846057",
"InitiatedBy": {
"user": {
"id": "aaaaaaaa-0000-0000-0000-000000000001",
"displayName": null,
"userPrincipalName": "adminuser@example.onmicrosoft.com",
"ipAddress": null,
"roles": [],
"agentType": "notAgentic"
}
},
"LoggedByService": "Application Proxy",
"OperationName": "Delete rollout policy of feature",
"OperationVersion": "1.0",
"Resource": "Microsoft.aadiam",
"ResourceGroup": "Microsoft.aadiam",
"ResourceId": "/tenants/11111111-1111-1111-1111-111111111111/providers/Microsoft.aadiam",
"Result": "success",
"ResultSignature": "None",
"TargetResources": [
{
"id": "11111111-1111-1111-1111-111111111111",
"displayName": null,
"type": "Directory",
"modifiedProperties": [
{
"displayName": "Feature",
"oldValue": "\"\"",
"newValue": "\"PasswordHashSync\""
}
],
"administrativeUnits": [],
"agentType": "notAgentic"
}
]
}
References #
Evaluate Conditional Access policies
#Description
Records that Azure AD B2C performed a Conditional Access policy evaluation during a user authentication, producing the grant decision (such as block or require multifactor authentication) applied to the sign-in. The entry's details capture the conditional access result and the policies whose conditions were met, including report-only policies.
References #
Exchange token
#Description
Records a token exchange during an Azure AD B2C authentication flow, where the B2C token endpoint issues tokens to the application (for example, exchanging an authorization code for access or ID tokens). It falls under the B2C Authentication category, which the audit-logs documentation defines as validation of user credentials and token issuance.
References #
Federate with an identity provider
#Description
Records Azure AD B2C federating authentication to an external identity provider, the action behind configuring or using an external social or enterprise IdP for a B2C tenant. If this reflects configuration of a new federated identity provider, such changes can establish an alternate authentication path and are worth monitoring.
References #
Get available strong authentication devices
#Description
Records a read of the available strong authentication (multifactor authentication) devices or methods in the Azure AD B2C directory. This is a read-only Authentication activity; enumeration of registered authentication methods can precede MFA-targeting or account-takeover activity.
References #
Issue a SAML assertion to the application
#Description
Records that Azure AD B2C issued a SAML assertion (security token) to a relying-party application at the successful conclusion of a SAML-based sign-in, with B2C acting as the SAML identity provider. It belongs to the B2C Authentication audit category, which covers validation of user credentials and token issuance.
References #
Issue an access token to the application
#Description
Records that Azure AD B2C issued an OAuth2/OpenID Connect access token to an application at the conclusion of a sign-in via a user flow or custom policy. It belongs to the B2C Authentication audit category covering validation of user credentials and token issuance.
References #
Issue an id_token to the application
#Description
Records that Azure AD B2C issued an id_token to a relying-party application, concluding a user sign-in through a B2C user flow or custom policy. It is logged under the B2C Authentication category, which covers validation of user credentials and token issuance, so it serves as the baseline sign-in-success signal for a B2C application.
References #
Make phone call to verify phone number
#Description
Records that Azure AD B2C placed an automated voice call to verify a user's registered phone number as part of phone-based multifactor authentication. It is logged under the B2C Authentication category; Microsoft documents that this telephony path can be abused for fraudulent sign-ups, so unusual volumes of phone-verification activity are worth monitoring.
References #
Register TOTP secret
#Description
A time-based one-time password (TOTP) authenticator secret was registered for an Azure AD B2C user during multifactor-authentication enrollment, with the secret stored in the user's profile and shared with the authenticator app. New MFA-method registration is relevant to account-takeover and persistence monitoring.
References #
Remediate user
#Description
An Azure AD B2C end user met the grant requirements of a Conditional Access policy (for example by completing multifactor authentication or a password change), and the outcome was reported to Identity Protection to reduce the user's risk. It records risk remediation during a B2C user flow.
References #
Remove a group from feature rollout
#Description
A group was removed from a staged feature rollout policy, ending that group's inclusion in the gradual rollout of the targeted authentication feature (such as a cloud authentication method). Changing rollout scope can alter which users follow cloud versus federated sign-in.
References #
Remove user from feature rollout
#Description
A user was removed from a Microsoft Entra feature rollout (Staged Rollout) policy, such as the cloud-authentication staged rollout for password hash sync, pass-through authentication, or seamless single sign-on. Removing a user reverts their sign-in to the prior method (for example, back to federation), which is relevant when watching for authentication-method tampering.
References #
Send SMS to verify phone number
#Description
Records that Azure AD B2C sent an SMS text message containing a verification code to confirm a user's phone number during a B2C user flow (for example phone sign-up/sign-in or multifactor authentication). The user must return the code to prove control of the number.
References #
Send verification email
#Description
Records that Azure AD B2C sent a verification email containing a one-time passcode to confirm a user's email address during a B2C local-account user flow. The user returns the passcode to prove control of the mailbox.
References #
Test audit log
#Description
Records a synthetic test entry written to the Microsoft Entra directory audit log. Such entries are used to confirm that audit logging and downstream export/streaming are functioning rather than to record a real administrative action; the exact emitter is not documented in public Microsoft Learn material.
References #
Update rollout policy of feature
#Description
A feature staged-rollout policy was updated, changing which groups have a cloud-authentication feature enabled (such as password hash sync, pass-through authentication, seamless SSO, or certificate-based authentication). Staged rollout transitions selected users from federated to managed/cloud authentication, so changes can alter how those users authenticate.
References #
User confirmed unusual sign-in event as legitimate
#Description
Records that a user responded to a notification about an unusual or suspicious sign-in and confirmed the sign-in as their own legitimate activity. A confirmation reduces the likelihood that the flagged sign-in indicates account compromise.
References #
User reported unusual sign-in event as not legitimate
#Description
Records that a user responded to a notification about an unusual or suspicious sign-in and reported the sign-in as not their own. This self-reported signal of possible account compromise is worth correlating with risk detections and sign-in logs.
References #
Validate Client Credentials
#Description
Records validation of an application's client credentials (client ID and a client secret) during the OAuth 2.0 client credentials grant flow in Azure AD B2C, where a confidential-client application authenticates as itself with no user involved. Used for server-to-server and daemon calls; anomalous or failed app authentications can indicate credential misuse.
References #
Validate local account credentials
#Description
Records validation of a B2C local-account user's credentials (the username or email plus password held in the B2C directory) during sign-in or a user flow. This falls under the B2C Authentication audit category, defined as validation of user credentials and token issuance; repeated failed validations across one or many accounts can indicate password spraying or credential stuffing against the tenant.
References #
Validate user authentication
#Description
Records validation of a user's authentication during a B2C user flow or custom policy, confirming the user has satisfied the policy's authentication requirements. It belongs to the B2C Authentication audit category, which covers validation of user credentials and token issuance.
Example Audit Log Entry #
{
"AADOperationType": "Read",
"AADTenantId": "11111111-1111-1111-1111-111111111111",
"ActivityDateTime": "2026-07-24T03:21:35.662885Z",
"ActivityDisplayName": "Validate user authentication",
"AdditionalDetails": [
{
"key": "targetTenant",
"value": "00000000-0000-0000-0000-000000000000"
},
{
"key": "targetEntityType",
"value": "None"
},
{
"key": "actorIdentityType",
"value": "UPN"
},
{
"key": "RequestId",
"value": "8c4cea1b-d146-4bde-a3b8-6b55a95bead2"
}
],
"Category": "Authentication",
"CorrelationId": "8c4cea1b-d146-4bde-a3b8-6b55a95bead2",
"DurationMs": "0",
"Id": "B2C_8c4cea1b-d146-4bde-a3b8-6b55a95bead2_11111111-1111-1111-1111-111111111111_134293368956628850",
"Identity": "adminuser@example.onmicrosoft.com",
"InitiatedBy": {
"user": {
"id": "aaaaaaaa-0000-0000-0000-000000000001",
"displayName": "adminuser@example.onmicrosoft.com",
"userPrincipalName": "adminuser@example.onmicrosoft.com",
"ipAddress": "203.0.113.10",
"roles": [],
"agentType": "notAgentic"
}
},
"LoggedByService": "B2C",
"OperationName": "Validate user authentication",
"OperationVersion": "1.0",
"Resource": "Microsoft.aadiam",
"ResourceGroup": "Microsoft.aadiam",
"ResourceId": "/tenants/11111111-1111-1111-1111-111111111111/providers/Microsoft.aadiam",
"Result": "success",
"ResultDescription": "Token is valid",
"ResultReason": "Token is valid",
"ResultSignature": "None",
"TargetResources": [
{
"id": null,
"displayName": "00000000-0000-0000-0000-000000000000",
"type": "Other",
"modifiedProperties": [],
"administrativeUnits": [],
"agentType": "notAgentic"
}
]
}
References #
Verify email address
#Description
Records verification that a user controls an email address, typically by confirming a one-time verification code that B2C emailed to that address during sign-up, sign-in, or account recovery. It is part of the B2C Authentication audit category covering credential validation.
References #
verify one time password
#Description
Records verification of a one-time password (OTP) that B2C previously generated and delivered to a destination such as an email address or phone number. The one-time password technical profile's VerifyCode operation checks the user-submitted code against the session and enforces code expiry and a maximum number of retry attempts; repeated failures or max-retry lockouts can indicate OTP brute-forcing.
References #
Rules often query computed field names, not native AuditLogs columns #
Many Entra detection rules pivot on field names that are not columns in this table but KQL projections the rule author computes from two dynamic columns. Searching the field list for those names finds nothing; use the canonical paths instead.
InitiatingUserPrincipalName(and siblingInitiating*names) is not a column. Rules project it fromInitiatedBy, for exampleextend InitiatingUserPrincipalName = tostring(InitiatedBy.user.userPrincipalName). The native paths areInitiatedBy.user.userPrincipalName,InitiatedBy.user.displayName, andInitiatedBy.user.idfor user actors, andInitiatedBy.app.displayName/InitiatedBy.app.appIdfor application or service-principal actors.- What changed lives in
TargetResources, adynamicarray. Expand it before filtering on the change:AuditLogs | mv-expand TargetResources | extend props = TargetResources.modifiedProperties, then readprops[].displayName,props[].oldValue, andprops[].newValue.
Column shapes per the AuditLogs table reference and the Graph directoryAudit resource.