> For the complete documentation index, see [llms.txt](https://msdocs.aohwv.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://msdocs.aohwv.com/quick-start/step-2-entra-id.md).

# Step 2 — Entra ID

Entra ID logs show who signed in, from where, whether MFA was used, and every change made to users, groups, roles and apps. For most attacks, this is where the first signs show up.

{% hint style="info" %}
**Time:** about 10 minutes
{% endhint %}

### Before you start

* **Step 1 — Event Hub Setup** is complete
* **Security Administrator** or **Global Administrator** in Entra ID
* **Contributor** (or Owner) on the Event Hub namespace, so Entra ID can send logs to it
* **Entra ID P1 or P2** license, required to send sign-in logs (audit logs work without it)

### 1. Check for existing settings

Your organization may already send Entra ID logs somewhere else, such as another tool or a storage account.

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).
2. Go to **Entra ID** → **Monitoring & health** → **Diagnostic settings**.
3. Review any existing settings.

{% hint style="warning" %}
**Don't delete or change existing settings** unless you know they're no longer needed. Another team or tool may rely on them. Add a new setting alongside them.
{% endhint %}

#### Already collecting sign-ins through Microsoft Graph?

Some SIEM connectors, including LogRhythm's **Microsoft Graph API Beat**, pull sign-ins from the Microsoft Graph API instead of an Event Hub. This usually only includes **interactive user** sign-ins, and misses **non-interactive**, **service principal** and **managed identity** sign-ins, the ones that show stolen tokens and compromised vendor apps.

**To collect every sign-in type, it takes a change on both sides:**

* **In your tenant:** use the diagnostic setting in part 2 of this page to stream every sign-in type to your Event Hub
* **In your SIEM:** collect them through the Event Hub connector, and turn off sign-in collection in the Graph connector to avoid duplicates. You can keep the Graph connector for other data, such as security alerts

{% hint style="info" %}
**Only seeing failed sign-ins?** Microsoft sends both successful and failed sign-ins, so the filtering is happening in your SIEM connector or its rules, not in your tenant.
{% endhint %}

### 2. Add a diagnostic setting

1. On the **Diagnostic settings** page, select **+ Add diagnostic setting**.
2. **Diagnostic setting name:** `siem-entra`
3. Under **Logs**, select the categories below.
4. Under **Destination details**, check **Stream to an event hub**, then choose:
   * **Subscription:** where your Event Hub lives
   * **Event hub namespace:** the namespace from Step 1
   * **Event hub name:** `entra-logs`
   * **Event hub policy name:** `RootManageSharedAccessKey`
5. Select **Save**.

### 3. Choose the log categories

#### Select for every organization

| Category                       | What it shows                                                                                     |
| ------------------------------ | ------------------------------------------------------------------------------------------------- |
| `AuditLogs`                    | Changes to users, groups, roles, apps and policies                                                |
| `SignInLogs`                   | Interactive user sign-ins, including MFA and location                                             |
| `NonInteractiveUserSignInLogs` | Sign-ins made by apps on a user's behalf, such as token refreshes. Key for spotting stolen tokens |
| `ServicePrincipalSignInLogs`   | Sign-ins by applications and automation accounts                                                  |
| `ManagedIdentitySignInLogs`    | Sign-ins by Azure managed identities                                                              |
| `ProvisioningLogs`             | Users created, updated or removed by automatic provisioning                                       |
| `MicrosoftGraphActivityLogs`   | API calls to Microsoft Graph. Shows attackers reading mail or data through the API                |

#### Select if they appear (depends on your licenses)

| Category                                                                                                   | What it shows                                                                                | Requires                    |
| ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------- |
| `RiskyUsers`                                                                                               | Users Microsoft has flagged as likely compromised                                            | Entra ID P2                 |
| `UserRiskEvents`                                                                                           | The specific detections behind a risky user, such as impossible travel or leaked credentials | Entra ID P2                 |
| `RiskyServicePrincipals`                                                                                   | Apps flagged as likely compromised                                                           | Workload Identities Premium |
| `ServicePrincipalRiskEvents`                                                                               | The detections behind a risky app                                                            | Workload Identities Premium |
| `ADFSSignInLogs`                                                                                           | Sign-ins through AD FS                                                                       | Only if you use AD FS       |
| `NetworkAccessTrafficLogs`, `NetworkAccessAlerts`, `RemoteNetworkHealthLogs`, `EnrichedOffice365AuditLogs` | Global Secure Access traffic and alerts                                                      | Global Secure Access        |

{% hint style="info" %}
**Watch the volume.** `NonInteractiveUserSignInLogs` and `MicrosoftGraphActivityLogs` can be large. They're worth collecting, but check your SIEM's ingestion costs before turning them on.
{% endhint %}

### Don't skip app and service principal logs

Third-party apps connected to your tenant often sign in with their own **secrets or certificates**: no user, no MFA, and usually no Conditional Access. If the vendor is breached, an attacker can use those credentials to access your data **as the app**.

For multi-tenant vendor apps, the credentials are stored in the **vendor's** tenant, so you can't see them being added or stolen. You can only see the app **signing in** and **what it does**, which is why these log categories matter.

<table><thead><tr><th width="250.2265625">Category</th><th>Commonly collected?</th><th>Why it matters for third-party apps</th></tr></thead><tbody><tr><td><strong>SignInLogs</strong></td><td>Usually</td><td>User sign-ins only. Doesn't show apps signing in on their own</td></tr><tr><td><strong>AuditLogs</strong></td><td>Usually</td><td>New apps, permission grants, consent, and credentials added to <strong>your own</strong> app registrations</td></tr><tr><td><strong>ServicePrincipalSignInLogs</strong></td><td><strong>Often missing</strong></td><td><strong>The key one for vendor apps.</strong> Shows every time an app signs in with its own secret or certificate, and from where</td></tr><tr><td><strong>ManagedIdentitySignInLogs</strong></td><td><strong>Often missing</strong></td><td>Sign-ins by Azure managed identities. There's no secret to steal, but they matter if the Azure resource itself is compromised. Low volume.</td></tr><tr><td><strong>MicrosoftGraphActivityLogs</strong></td><td><strong>Usually missing</strong> (volume and cost)</td><td>Shows <strong>what</strong> the app accessed: mailboxes, files, users. Without it, you know the app signed in but not what it took</td></tr></tbody></table>

#### Priority order

1. **AuditLogs:** consents, role changes and new credentials
2. **ServicePrincipalSignInLogs:** vendor and internal app sign-ins. **A must**, because this is the only place app-only sign-ins appear
3. **SignInLogs:** user sign-ins, which most organizations already collect
4. **ManagedIdentitySignInLogs:** low volume, so it costs little to add
5. **NonInteractiveUserSignInLogs:** shows stolen tokens being reused, but often the highest-volume sign-in type, so check the volume first
6. **MicrosoftGraphActivityLogs:** the most detail, and the highest cost

#### Check the volume first

Adding more sign-in types increases your SIEM volume and MPS. Before turning them on:

1. **Quick check:** in Entra ID → **Monitoring & health** → **Sign-in logs**, compare the last 24 hours across the **interactive**, **non-interactive**, **service principal** and **managed identity** tabs. Non-interactive is usually the largest.
2. **Before it reaches your SIEM:** send the logs to the Event Hub first and check **Incoming Bytes** under the namespace's **Metrics**.
3. **To estimate MPS:** divide events per day by **86,400**. Peaks will be higher.

{% hint style="info" %}
**Small tenant?** Volume is usually low enough to collect every sign-in type. Larger tenants may choose to start with **service principal** and **managed identity** sign-ins, then add **non-interactive** sign-ins once the volume is known. RedLegg can help you decide. See **Get Expert Help**.
{% endhint %}

{% hint style="warning" %}
**If you collect only one more category, make it ServicePrincipalSignInLogs.** It's low volume compared with user sign-ins, and it's the only way to see a vendor's app signing in from somewhere unexpected.
{% endhint %}

{% hint style="danger" %}
**Real example — October 2026:** Attackers stole an API secret belonging to **ConnectWise Cloud Backup**, a Microsoft 365 backup app used by managed service providers, and used it to sign in **as the app** to about 173 Microsoft 365 tenants. No passwords or MFA were involved. In at least one tenant, a related app gave itself **Global Administrator** and added new secrets to other trusted apps to keep access.

None of this appeared in normal user sign-in logs. It showed up in **ServicePrincipalSignInLogs** and **AuditLogs**. [Read the report](https://cybersecuritynews.com/connectwise-credentials-microsoft-365-accounts/)
{% endhint %}

#### What your SOC can detect from app sign-ins

* A vendor app signing in from a **new country or IP address**
* A sudden **spike** in sign-ins from an app that's normally quiet
* An app signing in **after the vendor has been offboarded**
* An app reading **mailboxes or files** it doesn't normally touch (Graph activity logs)
* A **new secret or certificate** added to one of your own app registrations (audit logs)
* **New permissions** granted to an app, especially application permissions like Mail.Read or Files.ReadWrite.All (audit logs)

#### Reduce the risk, too

* Review apps with **application permissions** and remove what isn't needed (see **Top 10 Hardening Steps**, step 4)
* With **Workload ID**, use Conditional Access to limit vendor apps to **known IP addresses**
* Ask vendors how they **store and rotate** the credentials for their app

**Concerned about MicrosoftGraphActivityLogs volume?** RedLegg can filter it to app activity only in your SIEM, and help you weigh the cost against the visibility. See **Get Expert Help**.

### What your SOC can detect with these logs

* Sign-ins from unusual countries, impossible travel or known malicious IP addresses
* Password spray and brute-force attempts
* MFA fatigue (many MFA prompts in a short time)
* Stolen session tokens being reused from a new location
* A user suddenly given an admin role
* A new app granted broad permissions (consent phishing)
* Conditional access policies changed or turned off

### Verify

1. Sign out and back in to the Azure portal to create a fresh sign-in.
2. In the Azure portal, open the Event Hub namespace → `entra-logs` → **Overview**, and confirm **Incoming Messages** shows activity. This can take up to 15 minutes.
3. In your SIEM, search for your own sign-in.

## Related

* [Step 1 — Event Hub Setup](/quick-start/step-1-event-hub-setup.md) — The Event Hub these logs are sent to
* [Step 3 — Defender XDR](/quick-start/step-3-defender-xdr.md) — Add alerts and endpoint, email and identity events
* [Get Expert Help](/get-expert-help/overview.md) — Want to go beyond logging? AOHWV can help harden Entra ID: conditional access, privileged roles and more


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://msdocs.aohwv.com/quick-start/step-2-entra-id.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.