Last reviewed:
How SOC teams can turn Microsoft Entra ID sign-in and audit telemetry into identity detections for valid-account abuse, risky access and authentication-policy change.
Microsoft Entra ID sign-in logs record authentication activity for users, service principals, managed identities and applications. Azure AD is the old name, and it still appears in older connectors and analyst notes, but public detection copy should use Microsoft Entra ID unless a source name still uses the older term.
The useful evidence is not only success or failure. Keep userPrincipalName, appDisplayName, resourceDisplayName, clientAppUsed, ipAddress, location, deviceDetail, conditionalAccessStatus, riskDetail, riskLevelAggregated, riskState, authenticationRequirement and status visible in review notes. Those fields let an analyst separate an expected token refresh from a sign-in that changed country, device trust or application target.
Sign-in evidence has limits. A successful sign-in proves that Entra accepted an authentication flow. It does not prove that the user was malicious, that the device was compromised or that a later Azure Resource Manager change occurred. Those claims need audit logs, Activity Log records, endpoint evidence or case context.
A good Entra detection plan keeps sign-in logs and audit logs in separate lanes before joining them. Sign-in logs answer access questions: who signed in, to which application, from where, with which client and under which Conditional Access result. Audit logs answer directory-change questions: who changed a policy, consented an application, modified a service principal or altered authentication methods.
This split stops coverage reports from becoming vague. A rule for impossible travel or unfamiliar sign-in properties is identity-access coverage. A rule for suspicious application consent or authentication-method registration is directory-change coverage. A sequence that joins the two can support a higher-priority valid-account investigation, but the join should be named as correlation evidence rather than hidden inside a broad 'identity anomaly' label.
Microsoft Sentinel workspaces usually expose these events through tables such as SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs and AuditLogs. If the tenant collects only interactive user sign-ins, say that plainly. Service-principal and managed-identity gaps matter in cloud investigations because attackers often move through app credentials after the first account foothold.
Entra sign-in logs are a strong source for T1078 Valid Accounts and T1078.004 Valid Accounts: Cloud Accounts, but only when the detection records the behaviour that made the sign-in suspicious. A successful login from a new country is not enough by itself. A new country plus unfamiliar device, failed MFA attempts, risky sign-in state or immediate privileged application access gives the analyst something concrete to review.
Start with detection families rather than one giant rule. Useful families include password-spray aftermath, MFA fatigue indicators, risky sign-in followed by sensitive application access, sign-in from unmanaged device to admin portals, service-principal access from a new network and break-glass account use outside an approved test window. Each family should name the source tables, the fields required and the tenant exceptions agreed with identity administrators.
Map the evidence class beside the ATT&CK technique. Direct detection evidence is a sign-in pattern the SOC can review on its own, such as break-glass account success from an unexpected network. Correlation context is a sign-in that needs another source before it becomes a useful alert, such as a medium-risk sign-in followed by Azure role assignment. Posture context is a configuration gap, not an attacker behaviour alert.
def entra_sign_in_evidence_kind(event):
if event.user_is_break_glass and event.success and not event.in_test_window:
return 'direct-detection:T1078.004'
if event.risk_level in {'medium', 'high'} and event.accessed_sensitive_app:
return 'direct-detection:T1078'
if event.new_country and event.followed_by_role_assignment:
return 'correlation-context:identity-to-control-plane'
if event.conditional_access_status == 'notApplied':
return 'posture-context:policy-gap'
return 'needs-review'
Most Entra sign-in detections fail in boring ways: the table is not collected, the parser drops nested status fields, Conditional Access details differ between tenants or a service-principal sign-in lands in a table the rule never queries. Treat field mapping as part of the detection, not as a note for later.
For each rule, record the Microsoft source log, SIEM table, required fields, retention period, tenant scope and any excluded automation. If a rule depends on risk fields from Entra ID Protection, say that dependency in the rule notes. Not every tenant has the same licence, retention or connector coverage, and that changes whether the detection can run as written.
CloudSigma belongs in the CVE and advisory-to-Sigma workflow. Entra sign-in guide work should point operators towards their own Microsoft Sentinel, Splunk, Elastic, OpenSearch or Google SecOps queries and test data. The coverage claim comes from reproducible field evidence, not from a product label.
Review Entra sign-in detections when Conditional Access policies change, when a tenant adds a major SaaS application, when service-principal credential policy changes or after an incident shows that a suspicious sign-in was visible but unmapped. Identity telemetry changes faster than many infrastructure logs because application owners, access packages and exception groups change often. Treat every policy exception as detection input, not only as access administration.
A quarterly review should ask which privileged accounts lack sign-in alerts, which detections ignore service-principal access, which audit-log events are needed to explain sign-in alerts and which ATT&CK mappings are still marked as correlation context. Those answers should feed a small backlog with owner, source table, parser dependency and test evidence.
DCV records the technique mapping and evidence class beside the Entra source so reviewers can see the difference between direct sign-in detection, audit-log context and posture gaps. That makes identity coverage easier to defend during a board review and harder to inflate by accident when audit evidence is thin.