Entra ID Audit Log Detection Guide: Detections for Role, App, Credential and Policy Changes

An attacker who reaches an Entra ID tenant rarely stops at signing in: the moves that turn one stolen session into lasting control, such as a new role assignment, a secret added to an app, a tenant-wide consent grant or a quiet edit to a Conditional Access exclusion, are directory changes, and they land in the audit log rather than the sign-in logs. Many teams collect the audit log but alert on almost none of it, because the volume is high and the useful detail sits in nested fields. This guide is for detection engineers and SOC analysts who want rules that fire on those changes with tolerable noise. It covers the record structure, the activity names that matter, how to read old and new values, and how to tune and test each detection. Sign-in detections are covered in the Entra ID Sign-In and Audit Log Detection Guide; this page goes deeper on the audit side only.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Entra ID audit documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Persistence lives in the audit log. Role assignments, app credentials, consent grants, federation settings and Conditional Access edits are all directory writes, recorded with the actor, the target and, where applicable, the old and new values.
• Match activity names exactly. Microsoft writes "Update application - Certificates and secrets management" with a plain hyphen and logs app and service principal updates as two separate entries; a rule that guesses the string silently matches nothing.
• The value is in modified properties. "Update Conditional Access policy" fires on every edit; the detection worth having compares old and new values for new exclusions, a policy switched to report-only or disabled, or a grant control removed.
• Who did it matters more than what was done. Most high-value detections are an allow list of approved actors, automation identities and change windows, so build and maintain that list first.
• Retention is short unless you export. Entra keeps audit logs for 7 days on Free and 30 days on P1 or P2; persistence planted months ago is only findable if the log was streamed to a workspace or archive.

What the audit log records, and what it does not

Microsoft describes the audit log as a report on every logged event in Entra ID, covering changes to applications, groups, users and licences, and states that entries are system generated and cannot be changed or deleted. Each entry carries the service that logged it, a category, an activity name, a result, a correlation ID, the initiator, the target resources and, where applicable, old and new values for the changed properties. The IP address in an audit entry is the OAuth client's address as seen by the service endpoint.

Three boundaries shape every detection plan:

• Not sign-ins: authentication events are in the sign-in logs. A detection that needs "who signed in, then changed X" joins the two.
• Not Microsoft 365 workloads: mailbox rules, mail access and SharePoint activity sit in the Microsoft 365 audit log (Microsoft Purview Audit), not Entra. Entra only shows Exchange Online directory write-backs under the actor "Microsoft Substrate Management", which Microsoft describes as informational.
• Not Azure resources: Azure role assignments and the "elevate access" action for Global Administrators appear in the Azure Activity Log (Directory Activity), not the Entra audit log.

The record structure your rules depend on

In Log Analytics and Microsoft Sentinel the data lands in the AuditLogs table when the AuditLogs category is enabled in Entra diagnostic settings. The same records are available from the Microsoft Graph directoryAudits API. The columns that carry detection logic:

Two practical points. First, oldValue and newValue are JSON strings inside a dynamic column, so rules parse them (in KQL, parse_json after mv-expand of TargetResources and modifiedProperties) before comparing. Second, the table has both Result (lowercase values) and ResultType (Success or Failure); pick one and use it consistently. For query technique, see the KQL for Threat Hunting Guide.

Detections by change type

The table lists the activity names as Microsoft's audit activity reference writes them, the category they appear under, and the condition that turns a routine event into an alert. Risk levels follow Microsoft's security operations guides where those guides set one.

Two caveats on this table. App and service principal credential changes are logged as two entries, so join them on CorrelationId or a short time window rather than alerting twice. And the federated identity credential that lets an external workload sign in as an app is a separate object from secrets and certificates; review those changes with the How to Audit Entra Workload Identity Federated Credentials guide.

Reading old and new values: Conditional Access as the worked example

Microsoft's infrastructure monitoring guidance says to review modified properties and compare old and new values on "Update Conditional Access policy". Alerting on every update produces a rule that teams mute within a week. The useful rule parses the policy JSON in oldValue and newValue and alerts on specific weakening patterns:

• State change: state moved from enabled to enabledForReportingButNotEnforced or disabled.
• New exclusions: users, groups, roles, applications or locations added under excludeUsers, excludeGroups, excludeRoles or excludeLocations.
• Narrowed scope: includeUsers or includeApplications no longer contains All.
• Removed controls: mfa, compliantDevice or an authentication strength removed from grantControls, or the operator changed from AND to OR.
• Session controls dropped: sign-in frequency or persistent browser settings removed from a policy for privileged roles.

Exclusions often arrive indirectly. Microsoft's guidance adds two group events: "Remove member from group" for a group that scopes a critical policy (medium) and "Add member to group" for a group used as an exclusion (low on its own, high when the target is a privileged user). Keep a watch list of the group IDs referenced by your Conditional Access policies and join group membership events against it. The same approach works for named locations: diff the IP ranges and the isTrusted flag rather than alerting on every edit. See the Conditional Access Guide for the policies worth protecting, and the How to Find Accounts Excluded From MFA and Conditional Access guide for the baseline of exclusions that already exist.

Correlations that raise confidence

Single events tell you what changed; sequences tell you whether it was an attack. These pairings are worth building as separate, higher-severity rules:

1. Consent then credential: admin consent or an app role assignment on an app, followed within hours by a new secret or certificate on the same app. This is the pattern where an attacker grants an app broad rights and then gives themselves a way to use them.
2. Method reset then privilege: "Admin registered security info" or a password reset on an account, followed by that account adding a role member, an app credential or a policy change.
3. Role activation then sensitive change: "Add member to role completed (PIM activation)" followed by federation, cross-tenant or Conditional Access changes from the same actor, outside a ticketed change.
4. Risky sign-in then directory write: a sign-in flagged by ID Protection, or from a new country or ASN, followed by any activity in the table above from the same user within the session. See the Microsoft Entra ID Protection guide.
5. App-initiated writes: InitiatedBy.app making role, credential or policy changes when that service principal has no history of doing so. Automation identities with directory write permissions are a common persistence path.

Where identity fits: workload identities as both target and actor

Service principals appear twice in audit detections. As targets, they receive the credentials, permissions and owners in the table above, and an app with Microsoft Graph application permissions plus a fresh secret is a durable, MFA-free foothold. As actors, provisioning tools, Entra Connect sync accounts and infrastructure pipelines write to the directory constantly and create most of the noise. Separate the two: maintain an inventory of automation service principals with the activities each is expected to perform, alert when one performs anything outside that set, and alert on any credential change to an app holding high privilege permissions regardless of actor. See the Entra ID Applications and Consent Guide, the How to Audit the Entra Connect Sync Account guide and the How to Find Expiring App Secrets and Certificates in Entra ID guide.

Collection, retention and latency

Microsoft notes that retention changes are not retroactive: upgrading a licence does not recover data that has already aged out. Enable the AuditLogs category on day one, and keep at least 12 months in a queryable or restorable form, because app credential and federation persistence is often found long after it was planted. Microsoft's retention page does not commit to an ingestion latency for audit logs, so test your own pipeline: make a known change and measure the time until it is queryable, then set rule look-back windows with that margin.

Rolling out the detections

1. Turn on collection and check completeness: enable the AuditLogs category, confirm events arrive from Core Directory, PIM and the authentication methods service, and record the measured latency.
2. Build the allow lists: approved actors for roles, Conditional Access, federation and cross-tenant settings; automation service principals and their expected activities; the group IDs used by Conditional Access policies; your owned domains.
3. Back-test on 30 to 90 days of history: run each rule as a hunting query, count hits, and review every hit. Tune by actor and target, never by blanket activity exclusions.
4. Deploy at low severity first: send to a review queue for two weeks before paging anyone. Record false positive causes.
5. Raise severity for the critical set: federation changes, permanent privileged role assignments, PIM guardrail changes, Conditional Access weakening and high privilege app grants page the on-call analyst.
6. Test with controlled changes: in a test tenant or a change window, add a test secret to a non-production app, add an exclusion to a report-only policy, and confirm each rule fires with the right fields.
7. Roll back safely: keep rules in version control; if a rule floods the queue, revert it to the previous version rather than disabling it, and record why.

For the engineering lifecycle behind these steps, see the Detection Engineering Guide and the Microsoft Sentinel Guide.

Decision guidance

• Small tenant, few admins: alert on every success for the critical set without allow lists. Volume is low, and every change is worth a human glance.
• Large tenant with automation: allow lists and correlation rules are essential. Put the automation inventory under change control so that adding a pipeline also updates the detections.
• Scheduled versus near real time rules: use near real time for federation, cross-tenant and permanent Global Administrator assignment; scheduled rules with a look-back that covers your measured latency are fine for the rest.
• Native workspace or third-party SIEM: either works if the dynamic columns arrive intact. Check that TargetResources and modifiedProperties survive the event hub and parser, because some connectors flatten or truncate them.

Measuring whether it works

• Coverage: share of the change types in the detection table with an active, tested rule. Target 100% for the critical set.
• Time to detect: median minutes from a test change to the alert, measured monthly with controlled changes.
• Precision: share of alerts in the critical set closed as true positive or authorised-but-unticketed change. Below 20% means the allow lists are stale.
• Unticketed change rate: privileged directory changes with no matching change ticket. This is a governance metric as much as a detection one.
• Retention depth: months of audit data that can be queried or restored within one working day.

Common failure patterns

• Typed activity names: rules that use an en dash or a guessed name ("Add service principal credential") and never fire. Copy strings from the activity reference and test with a real event.
• Alerting on the event, not the change: every Conditional Access update pages someone, the rule is muted, and the one edit that excludes an attacker's account is missed.
• Ignoring failures: blocked risky consents and failed role assignments are often the first visible sign of a compromised account probing for privilege.
• Trusting the automation: a service principal with RoleManagement or Application write rights is excluded wholesale from alerting, so its compromise is invisible.
• Looking in the wrong log: inbox rules and mailbox access are hunted in the Entra audit log, where they do not appear, instead of the Microsoft 365 audit log. See the How to Audit Mailbox Forwarding and Inbox Rules guide.
• Thirty days of history: no export, so an investigation into a federation trust or an app secret added last quarter starts with nothing. See the Golden SAML and Federation Trust Abuse Defence Guide.

Framework mapping

Practitioner checklist

• Enable the AuditLogs diagnostic category and keep at least 12 months in a queryable or restorable store.
• Copy every activity name in your rules from Microsoft's audit activity reference and test each rule against a real event.
• Alert on permanent privileged role assignments made outside PIM and on any PIM role setting or alert change.
• Alert on app and service principal credential additions for apps with high privilege permissions, joined on correlation ID.
• Alert on tenant-wide delegated grants and high privilege app role assignments to Microsoft Graph and other sensitive APIs.
• Parse old and new values on Conditional Access and named location changes and alert on weakening, not on every edit.
• Treat federation, domain and cross-tenant access changes as critical and route them to near real time rules.
• Maintain allow lists of approved actors and automation service principals under change control.
• Build at least three correlation rules: consent then credential, method reset then privilege, risky sign-in then directory write.
• Measure time to detect monthly with controlled test changes.

Standards and references

• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Learn: Learn about the audit logs in Microsoft Entra ID
• Microsoft Learn: Azure Monitor Logs reference, AuditLogs table
• Microsoft Learn: Microsoft Entra security operations guide for applications
• Microsoft Learn: Security operations for privileged accounts in Microsoft Entra ID
• Microsoft Learn: Microsoft Entra security operations guide for infrastructure
• Microsoft Learn: Microsoft Entra data retention
• MITRE ATT&CK: T1098 Account Manipulation

Related NHI Mgmt Group resources: Entra ID Sign-In and Audit Log Detection Guide · Entra ID Security Guide · Consent Phishing and Illicit OAuth Grants Guide · How to Investigate a Compromised Entra ID Account · Cloud Detection Engineering Guide