Better Together: Integrating Microsoft with LimaCharlie

The cheapest way to fail at integrating Microsoft into a security practice is to treat it as one more log feed. That is the framing the speaker, who goes by Matt in the session, spends most of his time dismantling. The instinct he keeps pushing back on is the kitchen sink: pipe Azure in because the platform can hold it, add it to the pile, move on. His argument is that Microsoft cloud data is not a feed at all. It is a footprint, and the difference between those two words decides whether bringing it into LimaCharlie helps a managed provider or just inflates a bill.

That distinction is worth taking seriously because of what a Microsoft cloud presence actually looks like. Integrating something like 1Password, Matt notes, means consuming a single product or a small suite, basically a simple log feed that is easy to bring in. A Microsoft Azure footprint is a database tied to virtual machines tied to DNS tied to a web front end tied to an application tied to an API gateway, and the relevant variable is not the size of any one store (a 10 gigabyte database versus a terabyte SQL database is beside the point) but the sheer number of distinct log-generating products. Layer on tens of thousands of Defender deployments and hundreds of thousands of users represented in Entra ID, and the thing you are integrating stops behaving like a feed entirely. Scale, spread across products, is the design constraint, and Matt's whole case is that you should let it shape both why and how you ingest before you touch a single connector.

Start from the service, not the data

For an MSSP or MDR, the why comes first. Matt is blunt that there are only a few defensible reasons to pull Microsoft data into LimaCharlie: you are designing a new service, you are offering something additional for a new or current customer who has asked you to watch their Microsoft environment, or your existing mechanism is too costly and does not scale. Everything else is the kitchen sink.

Consolidation is where almost everyone lands first, and he is honest about the pull of it. He cites a survey done over the summer of 2024 finding some organizations running 77 separate security products, 77 things to log into, a condition he calls over-dashboarded or over-platformed. The obvious fix is a single pane, and when someone asked him why not just reach for another SIEM or cloud SIEM, he conceded that one will consolidate just fine. The catch he wants providers to sit with is lock-in. Tether yourself to a vendor-specific platform tightly coupled to one set of data and the day a customer brings non-vendor data, or a new security stack shows up, you are back in integration work that becomes a hard road without the right support. Consolidation that quietly narrows your future options is a worse deal than it looks on the first monthly bill.

The second reason runs deeper than headcount. Matt separates two failure modes for a managed team: not enough people, and not enough leverage on the people you have. A provider can ingest a flood of telemetry into some other tool and still only be able to view it. Being able to action off the data, not just hold it, is what he frames as empowering the team's expertise rather than enlarging it, and it is the reason the consolidation point is never really about storage.

The how decides the what

Where teams get tripped up, in his experience, is not analysis but ingestion. Once data is in, security people know what to do with logs. Getting it in is the friction. So the workflow reduces to two questions, what you are ingesting and how, and his sharper observation is that the how usually dictates the what. There are three paths for Microsoft data. The Graph API is the direct connection into Microsoft's products, with LimaCharlie's parsers and adapters built primarily for Entra ID and Microsoft 365. Azure storage blobs behave like an S3 bucket: configure Azure to push logs from various products into a blob, then point LimaCharlie at it. Raw file ingestion handles structured exports like JSON, XML, or CSV, which Matt flags as real but rare outside of forensic dumps of historical archives.

The reason the how matters so much is a distinction most vendors gloss over: an API connection often does not hand you the raw audit log. It hands you what Matt calls meta events. The current Entra connector taps Entra's risky detections API, which is the output of its identity protection capability, so you are pulling in alerts, not the underlying telemetry. The tradeoff cuts both ways. Meta-event volume tracks how many alerts a tenant generates, so a quiet environment produces little data, but what you do get is high fidelity, close enough to direct detections that you may not need to write detection and response rules against it at all. Where a raw-telemetry endpoint exists, and for Entra it does, an adapter can be built to bring that in instead. With a storage blob, he frames it cleanly: the blob is the vehicle and the data types (SQL Server logs, Key Vault logs, Defender logs, Entra ID logs) are the passengers, and LimaCharlie handles parsing and normalization on the back end. Knowing which mode a connector uses tells you in advance how much data you will see and how much detection engineering you are signing up for.

Where ownership turns into margin

The cleverest part of the session is also the one that ties scale back to economics. When Defender telemetry arrives through a storage blob, LimaCharlie does not just store it. It recognizes that Defender logs tie back to endpoints and assigns each endpoint its own sensor allocation, a parsed interpretation rather than a deployed agent. In the dashboard you get a Defender feed tied to Azure plus a per-machine view, with normal EDR-style telemetry, system events, processes, network connections, co-mingled with the Defender alerts. There is no LimaCharlie agent on those machines. The pricing is the punchline: Azure log data is billed per gigabyte of ingestion, not per endpoint, so a provider gets system-by-system visibility across a Defender fleet without paying separate per-endpoint EDR fees. It is not a full interactive sensor, but for managing a customer's entire Defender deployment it is a genuinely different cost structure.

That capability is what makes Matt's three applications more than slides. The first is running an entire customer Defender fleet from inside LimaCharlie on the virtual-sensor model, optionally reaching back into the Azure tenant with the Cloud CLI connector to issue commands. The second, common among LimaCharlie's own managed providers, is monitoring customer Azure environments broadly: the customer pushes Azure data into a storage blob, LimaCharlie taps in, and the provider stops wrangling each product's configuration one by one. The third pairs Defender with LimaCharlie's EDR, using Defender as low-cost AV and baseline detection and LimaCharlie for live containment and hands-on response, collapsing what is normally two platforms, two dashboards, and two logging mechanisms into one.

Underneath all three, the things that make managing 10 or 20 or 30 of these tangled environments feasible are the platform's service-provider primitives: multi-tenancy, an API-first design, granular ACLs, white labeling, and CI/CD management across any number of tenants. That is the quiet thread of the whole session. The bottleneck for a managed provider is rarely the data. It is whether you can govern many complex Microsoft footprints without solving every scale problem by hiring another analyst. Integrating Microsoft well is less about the feed and more about owning the place it lands.