The Problem
If you've built out comprehensive detection coverage in Microsoft Sentinel, you might have hit an unexpected roadblock: the 512 enabled analytics rule limit.
This isn't just a problem for large enterprises. Any organisation that's taken detection engineering seriously can run into this ceiling:
- MITRE ATT&CK framework coverage alone is 576+ techniques and sub-techniques
- Multiple data sources each requiring custom detection logic
- Compliance requirements mandating specific detections
- Rules accumulated over time as new threats emerge
The official limit according to Microsoft's documentation:
| Workspace Type | Enabled Rules | Total (incl. disabled) |
|---|---|---|
| Standard workspace | 512 | 1024 |
| Dedicated cluster | 1024 | 2048 |
The dedicated cluster option requires a support ticket and comes with additional cost - not ideal if you just need a few more rules.
The Workaround: Defender XDR Custom Detections
If your organisation is already using the unified Microsoft Defender portal, there's another option: Defender XDR custom detections.
The key difference? No documented hard limit on the number of rules.
Custom detections use the same KQL you're already writing for Sentinel, but they run against XDR tables in Advanced Hunting. If you're hitting the Sentinel ceiling, you can offload detections for endpoint, email, and identity data to custom detections instead.
What Custom Detections Can Cover
Custom detections work with XDR telemetry:
- Endpoint: DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents
- Email: EmailEvents, EmailAttachmentInfo, EmailUrlInfo, EmailPostDeliveryEvents
- Identity: IdentityLogonEvents, IdentityQueryEvents, IdentityDirectoryEvents
- Cloud Apps: CloudAppEvents
If you've onboarded Sentinel to the unified portal, custom detections can also query Sentinel tables. Note that for XDR data, frequency options are fixed (hourly, 3hr, 12hr, 24hr, or NRT). A custom frequency (5 minutes to 14 days) is only available when the rule is based only on Sentinel data.
What to Keep in Sentinel
Custom detections won't help with everything. Keep your Sentinel analytics rules for:
- Third-party data sources (firewalls, proxies, SaaS apps)
- Syslog and custom log tables
- Cross-source correlation that spans beyond XDR data
- Detections that need to trigger Sentinel-specific playbooks
Quick Comparison
| Aspect | Sentinel Analytics | XDR Custom Detections |
|---|---|---|
| Rule limit | 512 enabled / 1024 total | No documented limit |
| NRT rules | 50 enabled / 100 total | Continuous (NRT) available |
| Data sources | Any Log Analytics table | XDR tables + Sentinel (if onboarded) |
| Response actions | Playbooks via automation | Native device/file/user/email actions |
| Alerts per run | 150 | 150 |
The Practical Approach
This isn't about migrating away from Sentinel or replacing your analytics rules. It's about using the right tool for the right data when you've hit the ceiling.
- Audit your current rules - identify which ones are based purely on XDR data (endpoint, email, identity)
- Prioritise candidates - rules that don't need cross-source correlation or Sentinel playbooks are good candidates
- Recreate in custom detections - the KQL is largely the same, just ensure you're returning the required columns (Timestamp, ReportId, DeviceId, etc.)
- Disable the Sentinel version - free up your rule count for detections that actually need Sentinel
What About the Limit Increase?
There's been talk of Microsoft increasing the default analytics rule limit from 512 to 1024. I've heard conflicting information - some say it's coming, others say there are no current plans and custom detections are the recommended path forward.
Until there's official confirmation on the roadmap, custom detections remain the practical workaround for organisations already in the unified portal.
Contributions welcome. If you've got additional insights or corrections, feel free to reach out on LinkedIn or GitHub.