Last Updated: 19/08/2026
This post focuses on the new feature in Microsoft Sentinel under the data connector option called “Data Federation”. This article explores what the data federation option is in regards to Microsoft Sentinel data connectors. Traditionally, if you wanted to analyse data into Microsoft Sentinel you would need to:
- Implement the data connector
- Ingest Data into Microsoft Sentinel & Log Analytics Workspace
- Pay the Ingestion costs
- Retain the data (And depending on rention periods, pay for longer retention)
Data Federation operates differently to this model. As you can now query external data sources without having to ingest data into the Microsoft Sentinel instance. The data effectively stays where it is.
Supported data sources in Microsoft Sentinel Data Federation
Currently, only a short list of supported data sources support data federation into Microsoft Sentinel. These are:
- Azure Data Lake Storage (ADLS) Gen2 – Allows you to query files and datasets stored in ADLS
- Microsoft Fabric Lakehouse – Allows you to query Fabric datasets
- Azure Databricks – Allows you to query unity catalog tables and Databrick data.
Advantages & Use Cases
One advantage would be the cost optimisation. If we are not ingesting data into Microsoft Sentinel, then this is not incurring a cost. The supported data sources currently are already in the Microsoft Ecosystem, and in order to traditionally query this with Microsoft Sentinel you would have to ingest this data and pay the ingestion cost for just “copying” the data into Microsoft Sentinel.
One of the more interesting possibilities would be for migration scenarios. If a organisation wants to migrate to Sentinel, there is always the question of what to do with the legacy data. Ingesting legacy data can be cost prohibitive based on the volume and value of the data. However, storing historical logs in ADLS Gen2, Microsoft Fabric Lakehouse and Databricks then the data federation will allow you to query that data from a single console. This can significantly reduce costs whilst still preserving access to legacy logs for investigations. KQL Jobs are supported to pull in federated data into custom tables for in-depth investigations.
There are many other use cases. If data federated sources are currently used, then they can be used to enrich data, perform more analysis and act as a bridge between business/operational and security datasets.
Considerations & Limitations
Based on what Microsoft have published so far, there are some downsides and limitations. The main thing to note would be that this new data federation functionality is not a full replacement to the traditional method of ingesting. Key limitations and considerations are:
- Query Performance may be slower – Because the data is located in the source platform. Query performance depends on the responsiveness of that platform rather than Microsoft Sentinel.
- Additional dependencies & resource management – A federated connection to the current supported data sources require resources such as Azure Key Vault and Service Principals. Whilst configuration of these are documented, it will mean that SOC teams will need to manage additional Azure resources and permissions of the source platform.
- Private Endpoints are not supported – Microsoft documentation states that the external data source must be publically accessable and private endpoints are not supported.
- Consistency – External data sources are not controlled by Sentinel. Data retention will need to be agreed and adjusted on multiple platforms.
For a full list of limitations published by Microsoft, please visit this article.
Summary
I think that this is a interesting feature to add in. It provides some good use cases for optimisation (If you are using Fabric, Azure Data Lake and Data Bricks) and can help with migration scenarios (If you have another SIEM and want to retain the legacy data). This will not be applicable to all organisations as the majority of key log data used for detection will require the traditional data connectors of Microsoft Sentinel.
Thank you for reading. If you haven’t already, please check out my post on Microsoft Sentinel Data Connector On-boarding Considerations for a list of items to check and consider when on-boarding a traditional data source. For more information on using Data Federation, please check out the Microsoft Learn page here.