> 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/readme/why-cloud-logs-matter.md).

# Why Microsoft Cloud Logs Matter

If your Microsoft cloud environment isn't sending the right logs to your SIEM, your SOC can't see any of it.

### Microsoft doesn't send these logs by default

Microsoft records a lot of activity, but it stays inside Microsoft's portals unless you send it somewhere:

* **It isn't sent to your SIEM.** Each source has to be connected separately.
* **It doesn't last long.** Entra ID keeps sign-in and audit logs for only **7–30 days**, depending on your license. Attacks are often discovered weeks later.
* **It's spread across many portals.** Entra, Defender, Purview and Azure each hold a different part of the picture.

### What one attack looks like across Microsoft

| What the attacker does                                            | Where it's recorded                   |
| ----------------------------------------------------------------- | ------------------------------------- |
| Signs in with a stolen password from an unusual location          | Entra ID                              |
| Creates an inbox rule to hide replies and forward mail            | Microsoft 365                         |
| Downloads sensitive files from SharePoint                         | Microsoft 365 / Purview               |
| Gives themselves admin rights in Azure                            | Azure Activity Log                    |
| Deploys malware to a device                                       | Defender XDR                          |
| A trusted vendor app is breached and signs in with its own secret | Entra ID (ServicePrincipalSignInLogs) |

Missing any one of these sources leaves a gap in the story. Connecting all of them lets your SOC **detect** the attack early and **investigate** exactly what happened.

### The right logs, not all logs

More data means higher SIEM costs and more noise, so this guide focuses on the Microsoft sources with the most security value, and deliberately leaves some out:

| Not collected                                                        | Why                                                                        |
| -------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| Everyday Copilot use                                                 | Tracks productivity, not threats                                           |
| Raw Azure resource logs (every Key Vault read, every storage access) | Very high volume. Defender for Cloud alerts on suspicious activity instead |
| Intune compliance and inventory reports                              | IT operations data, not security signals                                   |
| Email and file contents                                              | The SOC sees that activity happened, not what was written                  |

Once your logs are flowing, **RedLegg's 24x7 SOC** monitors them around the clock. See **RedLegg Managed SOC** for how.

### Ready to start?

Head to the [**Quick Start**](/quick-start/getting-started.md) to connect your Microsoft cloud environment in about 2–3 hours.

### Related

* [Why This Matters](/readme/why-cloud-logs-matter.md) — How attackers use Microsoft accounts, and what your SOC needs to see
* [Quick Start](/quick-start/getting-started.md) — Connect your Microsoft environment in about 2–3 hours


---

# 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/readme/why-cloud-logs-matter.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.