{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/", "slug": "dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal", "url": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/" }, "title": "Treat Sentinel incident grouping as initial guidance after Defender portal onboarding", "summary": "Why can incident membership differ from a Sentinel analytics rule's grouping settings?", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:25:47+00:00", "modified_at": "2026-09-10T02:01:56+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 247, "potentially_affected": "Microsoft Sentinel scheduled analytics rules when Sentinel is onboarded to the Microsoft Defender portal.", "dse_recommendation": "Validate the resulting Defender incident membership instead of treating analytics-rule grouping as a permanent boundary.", "primary_source": { "name": "Create scheduled analytics rules in Microsoft Sentinel | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/sentinel/create-analytics-rules", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

When Sentinel is onboarded to the Defender portal, Defender XDR creates incidents. Analytics-rule alert-grouping settings act at incident creation as initial guidance; Defender’s correlation engine can subsequently make different grouping decisions. The option to reopen a closed matching incident is unavailable in this configuration. Microsoft also instructs these deployments to leave the analytics rule’s incident-creation setting enabled. Microsoft Learn.

\n

Applicability

\n

Apply this boundary to the Defender-integrated Sentinel experience, not indiscriminately to every existing analytics deployment. Establish which incident engine owns the workflow before interpreting an apparent mismatch between configured grouping and the queue.

\n

DSE recommendation

\n

Validate the resulting Defender incident membership instead of treating analytics-rule grouping as a permanent boundary. Have the detection engineer and incident-response owner agree on how they will handle related alerts that appear in a different incident than expected. Avoid building a response assumption solely around a chosen grouping field or a reopen option that is unavailable in this mode. Preserve alert identity independently of the incident chosen for investigation.

\n

Verification

\n

Trace a representative, authorized detection from its rule output to the resulting alert and incident. Compare the original grouping intent with the actual membership and record the engine responsible for the outcome. Review any downstream routing or case-management assumption against that observation. Treat an unexpected grouping as something to investigate with the full alert context, not automatic proof that the analytics rule failed or that no related activity exists.

\n

Official references

\n

Microsoft Learn: Scheduled analytics rule configuration. Source reviewed September 9, 2026.

", "content_text": "Source facts\nWhen Sentinel is onboarded to the Defender portal, Defender XDR creates incidents. Analytics-rule alert-grouping settings act at incident creation as initial guidance; Defender’s correlation engine can subsequently make different grouping decisions. The option to reopen a closed matching incident is unavailable in this configuration. Microsoft also instructs these deployments to leave the analytics rule’s incident-creation setting enabled. Microsoft Learn.\nApplicability\nApply this boundary to the Defender-integrated Sentinel experience, not indiscriminately to every existing analytics deployment. Establish which incident engine owns the workflow before interpreting an apparent mismatch between configured grouping and the queue.\nDSE recommendation\nValidate the resulting Defender incident membership instead of treating analytics-rule grouping as a permanent boundary. Have the detection engineer and incident-response owner agree on how they will handle related alerts that appear in a different incident than expected. Avoid building a response assumption solely around a chosen grouping field or a reopen option that is unavailable in this mode. Preserve alert identity independently of the incident chosen for investigation.\nVerification\nTrace a representative, authorized detection from its rule output to the resulting alert and incident. Compare the original grouping intent with the actual membership and record the engine responsible for the outcome. Review any downstream routing or case-management assumption against that observation. Treat an unexpected grouping as something to investigate with the full alert context, not automatic proof that the analytics rule failed or that no related activity exists.\nOfficial references\nMicrosoft Learn: Scheduled analytics rule configuration. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nWhen Sentinel is onboarded to the Defender portal, Defender XDR creates incidents. Analytics-rule alert-grouping settings act at incident creation as initial guidance; Defender’s correlation engine can subsequently make different grouping decisions. The option to reopen a closed matching incident is unavailable in this configuration. Microsoft also instructs these deployments to leave the analytics rule’s incident-creation setting enabled. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/sentinel/create-analytics-rules).\n\n## Applicability\n\nApply this boundary to the Defender-integrated Sentinel experience, not indiscriminately to every existing analytics deployment. Establish which incident engine owns the workflow before interpreting an apparent mismatch between configured grouping and the queue.\n\n## DSE recommendation\n\nValidate the resulting Defender incident membership instead of treating analytics-rule grouping as a permanent boundary. Have the detection engineer and incident-response owner agree on how they will handle related alerts that appear in a different incident than expected. Avoid building a response assumption solely around a chosen grouping field or a reopen option that is unavailable in this mode. Preserve alert identity independently of the incident chosen for investigation.\n\n## Verification\n\nTrace a representative, authorized detection from its rule output to the resulting alert and incident. Compare the original grouping intent with the actual membership and record the engine responsible for the outcome. Review any downstream routing or case-management assumption against that observation. Treat an unexpected grouping as something to investigate with the full alert context, not automatic proof that the analytics rule failed or that no related activity exists.\n\n## Official references\n\n[Microsoft Learn: Scheduled analytics rule configuration](https://learn.microsoft.com/en-us/azure/sentinel/create-analytics-rules). Source reviewed September 9, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/", "url": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Treat Sentinel incident grouping as initial guidance after Defender portal onboarding", "item": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/", "url": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/", "headline": "Treat Sentinel incident grouping as initial guidance after Defender portal onboarding", "description": "Why can incident membership differ from a Sentinel analytics rule's grouping settings?", "abstract": "Why can incident membership differ from a Sentinel analytics rule's grouping settings?", "articleBody": "Source facts\nWhen Sentinel is onboarded to the Defender portal, Defender XDR creates incidents. Analytics-rule alert-grouping settings act at incident creation as initial guidance; Defender’s correlation engine can subsequently make different grouping decisions. The option to reopen a closed matching incident is unavailable in this configuration. Microsoft also instructs these deployments to leave the analytics rule’s incident-creation setting enabled. Microsoft Learn.\nApplicability\nApply this boundary to the Defender-integrated Sentinel experience, not indiscriminately to every existing analytics deployment. Establish which incident engine owns the workflow before interpreting an apparent mismatch between configured grouping and the queue.\nDSE recommendation\nValidate the resulting Defender incident membership instead of treating analytics-rule grouping as a permanent boundary. Have the detection engineer and incident-response owner agree on how they will handle related alerts that appear in a different incident than expected. Avoid building a response assumption solely around a chosen grouping field or a reopen option that is unavailable in this mode. Preserve alert identity independently of the incident chosen for investigation.\nVerification\nTrace a representative, authorized detection from its rule output to the resulting alert and incident. Compare the original grouping intent with the actual membership and record the engine responsible for the outcome. Review any downstream routing or case-management assumption against that observation. Treat an unexpected grouping as something to investigate with the full alert context, not automatic proof that the analytics rule failed or that no related activity exists.\nOfficial references\nMicrosoft Learn: Scheduled analytics rule configuration. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:25:47+00:00", "dateModified": "2026-09-10T02:01:56+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-369-treat-sentinel-incident-grouping-as-initial-guidance-after-defender-portal/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Treat Sentinel incident grouping as initial guidance after Defender portal onboarding" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Briefing", "Information priority" ], "genre": "Briefing", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 247, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Create scheduled analytics rules in Microsoft Sentinel | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/sentinel/create-analytics-rules" } } ] } }