Exchange Online’s RejectDirectSend setting, off by default, rejects anonymous messages whose envelope sender uses one of the tenant’s accepted domains unless a mail flow connector attributes them. Devices and services that send as your domain need a partner connector first, and Microsoft plans to enable it by default for new tenants.
\nMicrosoft’s Exchange Team post Introducing more control over Direct Send in Exchange Online, updated May 20, 2026, describes Direct Send as a way for on-premises devices, applications or third-party services to send mail to a tenant’s mailboxes using the customer’s own accepted domain without any authentication. Turning on the opt-in RejectDirectSend setting, which is False by default, blocks mail sent anonymously to the tenant with an envelope sender (P1 Mail From) matching an accepted domain; the P2 From header is not checked, and anonymous means not attributed to a mail flow connector.
\nSenders that legitimately use Direct Send must be authenticated with a partner mail flow connector that matches their certificate, which Microsoft recommends, or their IP addresses, and the SPF record is a good starting point for finding them. Admins enable the setting with Set-OrganizationConfig -RejectDirectSend $true, which propagates within 30 minutes, and rejected messages receive 550 5.7.68 TenantInboundAttribution.
\nMicrosoft released the setting as a public preview, added a Change Optics Report in the Exchange admin center that shows Direct Send traffic, and plans to enable it by default for new tenants, which will not be able to turn it off. It warns that messages forwarded back through a provider without Sender Rewriting Scheme may be rejected without a connector, that the setting is not enabled for GCC-High, DoD and USNat/USSec environments, and that changing it requires the Organization Configuration role.
\nUse this for Exchange Online tenants, including those whose MX record points to a third-party filtering service. Tenants in GCC-High, DoD and USNat/USSec cannot use the setting yet.
\nDSE recommends finding every device and service that sends as your domain, giving each a partner connector, and then turning on Reject Direct Send. Start from the SPF record and the Change Optics Report, prefer certificate-based connectors, move devices that can authenticate to authenticated submission, and watch for 550 5.7.68 rejections after the change.
\nSend a test message from each approved device or service and confirm message trace shows it attributed to the expected connector, then confirm an anonymous test from your domain is rejected.
\nMicrosoft Exchange Team Blog — Introducing more control over Direct Send in Exchange Online. Reviewed October 19, 2026.
", "content_text": "Exchange Online’s RejectDirectSend setting, off by default, rejects anonymous messages whose envelope sender uses one of the tenant’s accepted domains unless a mail flow connector attributes them. Devices and services that send as your domain need a partner connector first, and Microsoft plans to enable it by default for new tenants.\nSource facts\nMicrosoft’s Exchange Team post Introducing more control over Direct Send in Exchange Online, updated May 20, 2026, describes Direct Send as a way for on-premises devices, applications or third-party services to send mail to a tenant’s mailboxes using the customer’s own accepted domain without any authentication. Turning on the opt-in RejectDirectSend setting, which is False by default, blocks mail sent anonymously to the tenant with an envelope sender (P1 Mail From) matching an accepted domain; the P2 From header is not checked, and anonymous means not attributed to a mail flow connector.\nSenders that legitimately use Direct Send must be authenticated with a partner mail flow connector that matches their certificate, which Microsoft recommends, or their IP addresses, and the SPF record is a good starting point for finding them. Admins enable the setting with Set-OrganizationConfig -RejectDirectSend $true, which propagates within 30 minutes, and rejected messages receive 550 5.7.68 TenantInboundAttribution.\nMicrosoft released the setting as a public preview, added a Change Optics Report in the Exchange admin center that shows Direct Send traffic, and plans to enable it by default for new tenants, which will not be able to turn it off. It warns that messages forwarded back through a provider without Sender Rewriting Scheme may be rejected without a connector, that the setting is not enabled for GCC-High, DoD and USNat/USSec environments, and that changing it requires the Organization Configuration role.\nApplicability\nUse this for Exchange Online tenants, including those whose MX record points to a third-party filtering service. Tenants in GCC-High, DoD and USNat/USSec cannot use the setting yet.\nDSE recommendation\nDSE recommends finding every device and service that sends as your domain, giving each a partner connector, and then turning on Reject Direct Send. Start from the SPF record and the Change Optics Report, prefer certificate-based connectors, move devices that can authenticate to authenticated submission, and watch for 550 5.7.68 rejections after the change.\nVerification\nSend a test message from each approved device or service and confirm message trace shows it attributed to the expected connector, then confirm an anonymous test from your domain is rejected.\nOfficial reference\nMicrosoft Exchange Team Blog — Introducing more control over Direct Send in Exchange Online. Reviewed October 19, 2026.", "content_markdown": "Exchange Online’s RejectDirectSend setting, off by default, rejects anonymous messages whose envelope sender uses one of the tenant’s accepted domains unless a mail flow connector attributes them. Devices and services that send as your domain need a partner connector first, and Microsoft plans to enable it by default for new tenants.\n\n## Source facts\n\nMicrosoft’s Exchange Team post [Introducing more control over Direct Send in Exchange Online](https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790), updated May 20, 2026, describes Direct Send as a way for on-premises devices, applications or third-party services to send mail to a tenant’s mailboxes using the customer’s own accepted domain without any authentication. Turning on the opt-in RejectDirectSend setting, which is False by default, blocks mail sent anonymously to the tenant with an envelope sender (P1 Mail From) matching an accepted domain; the P2 From header is not checked, and anonymous means not attributed to a mail flow connector.\n\nSenders that legitimately use Direct Send must be authenticated with a partner mail flow connector that matches their certificate, which Microsoft recommends, or their IP addresses, and the SPF record is a good starting point for finding them. Admins enable the setting with Set-OrganizationConfig -RejectDirectSend $true, which propagates within 30 minutes, and rejected messages receive 550 5.7.68 TenantInboundAttribution.\n\nMicrosoft released the setting as a public preview, added a Change Optics Report in the Exchange admin center that shows Direct Send traffic, and plans to enable it by default for new tenants, which will not be able to turn it off. It warns that messages forwarded back through a provider without Sender Rewriting Scheme may be rejected without a connector, that the setting is not enabled for GCC-High, DoD and USNat/USSec environments, and that changing it requires the Organization Configuration role.\n\n## Applicability\n\nUse this for Exchange Online tenants, including those whose MX record points to a third-party filtering service. Tenants in GCC-High, DoD and USNat/USSec cannot use the setting yet.\n\n## DSE recommendation\n\nDSE recommends finding every device and service that sends as your domain, giving each a partner connector, and then turning on Reject Direct Send. Start from the SPF record and the Change Optics Report, prefer certificate-based connectors, move devices that can authenticate to authenticated submission, and watch for 550 5.7.68 rejections after the change.\n\n## Verification\n\nSend a test message from each approved device or service and confirm message trace shows it attributed to the expected connector, then confirm an anonymous test from your domain is rejected.\n\n## Official reference\n\n[Microsoft Exchange Team Blog — Introducing more control over Direct Send in Exchange Online](https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790). Reviewed October 19, 2026." }, { "id": "https://update.dsesecurity.com/updates/skype-for-business-server-2015-2019-end-of-support-subscription-edition-teams/", "slug": "skype-for-business-server-2015-2019-end-of-support-subscription-edition-teams", "url": "https://update.dsesecurity.com/updates/skype-for-business-server-2015-2019-end-of-support-subscription-edition-teams/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/skype-for-business-server-2015-2019-end-of-support-subscription-edition-teams.md", "json": "https://update.dsesecurity.com/api/v1/posts/skype-for-business-server-2015-2019-end-of-support-subscription-edition-teams/" }, "title": "Skype for Business Server 2015 and 2019 have been out of support since October 2025: plan Teams or Subscription Edition", "summary": "Microsoft’s lifecycle pages list Skype for Business Server 2015 and 2019 extended support ending 10/15/2025 (6:59:59 AM Pacific). Skype for Business Server Subscription Edition, under the Modern Lifecycle Policy since July 1, 2025, can only be installed as an in-place upgrade from Skype for Business Server 2019.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-19T00:27:37+00:00", "modified_at": "2026-10-19T01:55:05+00:00", "reviewed_on": "2026-10-19", "reading_minutes": 2, "word_count": 292, "potentially_affected": "Organizations still running on-premises Skype for Business Server 2015 or 2019 for chat, meetings or enterprise voice, and the providers who support them.", "dse_recommendation": "DSE recommends retiring Skype for Business Server 2015 and 2019 deployments by moving users to Microsoft Teams or upgrading 2019 servers in place to Subscription Edition.", "primary_source": { "name": "Microsoft Lifecycle — Skype for Business Server 2019", "url": "https://learn.microsoft.com/en-us/lifecycle/products/skype-for-business-server-2019", "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": "Microsoft’s lifecycle pages list Skype for Business Server 2015 and 2019 extended support ending 10/15/2025 (6:59:59 AM Pacific). Skype for Business Server Subscription Edition, under the Modern Lifecycle Policy since July 1, 2025, can only be installed as an in-place upgrade from Skype for Business Server 2019.
\nMicrosoft’s lifecycle pages for Skype for Business Server 2019 and Skype for Business Server 2015 show both under the Fixed Lifecycle Policy with extended support ending 10/15/2025 at 6:59:59 AM Pacific Time; mainstream support ended in January 2024 for 2019 and October 2020 for 2015.
\nThe Subscription Edition lifecycle page shows Skype for Business Server Subscription Edition under the Modern Lifecycle Policy with a start date of 7/1/2025 and lists it as in support. It notes that Subscription Edition can only be installed as an in-place upgrade of Skype for Business Server 2019, so a new server must first be installed with the 2019 RTM code and patched to the Subscription Edition build, build 7.0.2046.810 or higher, in one cumulative update step.
\nUse this for any on-premises Skype for Business Server deployment, including hybrid configurations. Licensing and migration options for Teams and Subscription Edition vary; confirm them with Microsoft or a licensing partner.
\nDSE recommends retiring Skype for Business Server 2015 and 2019 deployments by moving users to Microsoft Teams or upgrading 2019 servers in place to Subscription Edition. Inventory users, enterprise voice routes, gateways, devices and integrations first, move 2015 pools through 2019 or to Teams, and remove external access edges from servers awaiting retirement.
\nTrack every pool and edge server by version until each is upgraded or decommissioned, confirm DNS records for retired pools are removed, and test calling and meetings after each migration wave.
\nMicrosoft Lifecycle — Skype for Business Server 2019. Microsoft Lifecycle — Skype for Business Server 2015. Microsoft Lifecycle — Skype for Business Server Subscription Edition. Reviewed October 19, 2026.
", "content_text": "Microsoft’s lifecycle pages list Skype for Business Server 2015 and 2019 extended support ending 10/15/2025 (6:59:59 AM Pacific). Skype for Business Server Subscription Edition, under the Modern Lifecycle Policy since July 1, 2025, can only be installed as an in-place upgrade from Skype for Business Server 2019.\nSource facts\nMicrosoft’s lifecycle pages for Skype for Business Server 2019 and Skype for Business Server 2015 show both under the Fixed Lifecycle Policy with extended support ending 10/15/2025 at 6:59:59 AM Pacific Time; mainstream support ended in January 2024 for 2019 and October 2020 for 2015.\nThe Subscription Edition lifecycle page shows Skype for Business Server Subscription Edition under the Modern Lifecycle Policy with a start date of 7/1/2025 and lists it as in support. It notes that Subscription Edition can only be installed as an in-place upgrade of Skype for Business Server 2019, so a new server must first be installed with the 2019 RTM code and patched to the Subscription Edition build, build 7.0.2046.810 or higher, in one cumulative update step.\nApplicability\nUse this for any on-premises Skype for Business Server deployment, including hybrid configurations. Licensing and migration options for Teams and Subscription Edition vary; confirm them with Microsoft or a licensing partner.\nDSE recommendation\nDSE recommends retiring Skype for Business Server 2015 and 2019 deployments by moving users to Microsoft Teams or upgrading 2019 servers in place to Subscription Edition. Inventory users, enterprise voice routes, gateways, devices and integrations first, move 2015 pools through 2019 or to Teams, and remove external access edges from servers awaiting retirement.\nVerification\nTrack every pool and edge server by version until each is upgraded or decommissioned, confirm DNS records for retired pools are removed, and test calling and meetings after each migration wave.\nOfficial references\nMicrosoft Lifecycle — Skype for Business Server 2019. Microsoft Lifecycle — Skype for Business Server 2015. Microsoft Lifecycle — Skype for Business Server Subscription Edition. Reviewed October 19, 2026.", "content_markdown": "Microsoft’s lifecycle pages list Skype for Business Server 2015 and 2019 extended support ending 10/15/2025 (6:59:59 AM Pacific). Skype for Business Server Subscription Edition, under the Modern Lifecycle Policy since July 1, 2025, can only be installed as an in-place upgrade from Skype for Business Server 2019.\n\n## Source facts\n\nMicrosoft’s lifecycle pages for [Skype for Business Server 2019](https://learn.microsoft.com/en-us/lifecycle/products/skype-for-business-server-2019) and [Skype for Business Server 2015](https://learn.microsoft.com/en-us/lifecycle/products/skype-for-business-server-2015) show both under the Fixed Lifecycle Policy with extended support ending 10/15/2025 at 6:59:59 AM Pacific Time; mainstream support ended in January 2024 for 2019 and October 2020 for 2015.\n\nThe [Subscription Edition lifecycle page](https://learn.microsoft.com/en-us/lifecycle/products/skype-for-business-server-subscription-edition) shows Skype for Business Server Subscription Edition under the Modern Lifecycle Policy with a start date of 7/1/2025 and lists it as in support. It notes that Subscription Edition can only be installed as an in-place upgrade of Skype for Business Server 2019, so a new server must first be installed with the 2019 RTM code and patched to the Subscription Edition build, build 7.0.2046.810 or higher, in one cumulative update step.\n\n## Applicability\n\nUse this for any on-premises Skype for Business Server deployment, including hybrid configurations. Licensing and migration options for Teams and Subscription Edition vary; confirm them with Microsoft or a licensing partner.\n\n## DSE recommendation\n\nDSE recommends retiring Skype for Business Server 2015 and 2019 deployments by moving users to Microsoft Teams or upgrading 2019 servers in place to Subscription Edition. Inventory users, enterprise voice routes, gateways, devices and integrations first, move 2015 pools through 2019 or to Teams, and remove external access edges from servers awaiting retirement.\n\n## Verification\n\nTrack every pool and edge server by version until each is upgraded or decommissioned, confirm DNS records for retired pools are removed, and test calling and meetings after each migration wave.\n\n## Official references\n\n[Microsoft Lifecycle — Skype for Business Server 2019](https://learn.microsoft.com/en-us/lifecycle/products/skype-for-business-server-2019). [Microsoft Lifecycle — Skype for Business Server 2015](https://learn.microsoft.com/en-us/lifecycle/products/skype-for-business-server-2015). [Microsoft Lifecycle — Skype for Business Server Subscription Edition](https://learn.microsoft.com/en-us/lifecycle/products/skype-for-business-server-subscription-edition). Reviewed October 19, 2026." }, { "id": "https://update.dsesecurity.com/updates/sharepoint-server-2016-2019-end-of-support-july-2026-subscription-edition/", "slug": "sharepoint-server-2016-2019-end-of-support-july-2026-subscription-edition", "url": "https://update.dsesecurity.com/updates/sharepoint-server-2016-2019-end-of-support-july-2026-subscription-edition/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/sharepoint-server-2016-2019-end-of-support-july-2026-subscription-edition.md", "json": "https://update.dsesecurity.com/api/v1/posts/sharepoint-server-2016-2019-end-of-support-july-2026-subscription-edition/" }, "title": "SharePoint Server 2016 and 2019 left extended support in July 2026: move to Subscription Edition or SharePoint Online", "summary": "Microsoft’s lifecycle pages list SharePoint Server 2016 and 2019 extended support ending 7/15/2026 (6:59:59 AM Pacific), and its 2026 end-of-support list adds Project Server 2016 and 2019, SharePoint Designer 2013 and InfoPath 2013 on July 14, 2026. SharePoint Server Subscription Edition follows the Modern Lifecycle Policy and is in support.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-19T00:27:36+00:00", "modified_at": "2026-10-19T01:55:05+00:00", "reviewed_on": "2026-10-19", "reading_minutes": 2, "word_count": 282, "potentially_affected": "Organizations running on-premises SharePoint Server 2016 or 2019 farms, including intranets, document libraries and InfoPath or SharePoint Designer workflows, and the providers who maintain them.", "dse_recommendation": "DSE recommends planning every SharePoint Server 2016 and 2019 farm’s move to SharePoint Server Subscription Edition or SharePoint Online now, and restricting access to farms that remain.", "primary_source": { "name": "Microsoft Lifecycle — SharePoint Server 2019", "url": "https://learn.microsoft.com/en-us/lifecycle/products/sharepoint-server-2019", "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": "Microsoft’s lifecycle pages list SharePoint Server 2016 and 2019 extended support ending 7/15/2026 (6:59:59 AM Pacific), and its 2026 end-of-support list adds Project Server 2016 and 2019, SharePoint Designer 2013 and InfoPath 2013 on July 14, 2026. SharePoint Server Subscription Edition follows the Modern Lifecycle Policy and is in support.
\nMicrosoft’s lifecycle pages for SharePoint Server 2019 and SharePoint Server 2016 show both under the Fixed Lifecycle Policy with extended support ending 7/15/2026 at 6:59:59 AM Pacific Time; mainstream support ended in January 2024 for 2019 and July 2021 for 2016.
\nMicrosoft’s list of products ending support in 2026 includes Project Server 2016 and 2019, SharePoint Designer 2013, InfoPath 2013, SharePoint Server 2016 and SharePoint Server 2019 on July 14, 2026, and says that upon end of support there are no new security updates, non-security updates, assisted support options or online technical content updates.
\nThe SharePoint Server Subscription Edition lifecycle page shows it follows the Modern Lifecycle Policy, with a start date of 11/2/2021, and lists it as in support.
\nUse this for any on-premises SharePoint Server 2016 or 2019 farm. Migration paths, licensing and feature differences between Subscription Edition and SharePoint Online vary; confirm them before choosing a target.
\nDSE recommends planning every SharePoint Server 2016 and 2019 farm’s move to SharePoint Server Subscription Edition or SharePoint Online now, and restricting access to farms that remain. Inventory sites, custom solutions, InfoPath forms and SharePoint Designer workflows that will not move as they are, assign an owner for each, and remove external publishing from old farms until they are retired.
\nList each farm’s version and build, track its migration status, and confirm that no DNS records, reverse proxies or firewall rules still expose a retired farm.
\nMicrosoft Lifecycle — SharePoint Server 2019. Microsoft Lifecycle — SharePoint Server 2016. Microsoft Lifecycle — SharePoint Server Subscription Edition. Reviewed October 19, 2026.
", "content_text": "Microsoft’s lifecycle pages list SharePoint Server 2016 and 2019 extended support ending 7/15/2026 (6:59:59 AM Pacific), and its 2026 end-of-support list adds Project Server 2016 and 2019, SharePoint Designer 2013 and InfoPath 2013 on July 14, 2026. SharePoint Server Subscription Edition follows the Modern Lifecycle Policy and is in support.\nSource facts\nMicrosoft’s lifecycle pages for SharePoint Server 2019 and SharePoint Server 2016 show both under the Fixed Lifecycle Policy with extended support ending 7/15/2026 at 6:59:59 AM Pacific Time; mainstream support ended in January 2024 for 2019 and July 2021 for 2016.\nMicrosoft’s list of products ending support in 2026 includes Project Server 2016 and 2019, SharePoint Designer 2013, InfoPath 2013, SharePoint Server 2016 and SharePoint Server 2019 on July 14, 2026, and says that upon end of support there are no new security updates, non-security updates, assisted support options or online technical content updates.\nThe SharePoint Server Subscription Edition lifecycle page shows it follows the Modern Lifecycle Policy, with a start date of 11/2/2021, and lists it as in support.\nApplicability\nUse this for any on-premises SharePoint Server 2016 or 2019 farm. Migration paths, licensing and feature differences between Subscription Edition and SharePoint Online vary; confirm them before choosing a target.\nDSE recommendation\nDSE recommends planning every SharePoint Server 2016 and 2019 farm’s move to SharePoint Server Subscription Edition or SharePoint Online now, and restricting access to farms that remain. Inventory sites, custom solutions, InfoPath forms and SharePoint Designer workflows that will not move as they are, assign an owner for each, and remove external publishing from old farms until they are retired.\nVerification\nList each farm’s version and build, track its migration status, and confirm that no DNS records, reverse proxies or firewall rules still expose a retired farm.\nOfficial references\nMicrosoft Lifecycle — SharePoint Server 2019. Microsoft Lifecycle — SharePoint Server 2016. Microsoft Lifecycle — SharePoint Server Subscription Edition. Reviewed October 19, 2026.", "content_markdown": "Microsoft’s lifecycle pages list SharePoint Server 2016 and 2019 extended support ending 7/15/2026 (6:59:59 AM Pacific), and its 2026 end-of-support list adds Project Server 2016 and 2019, SharePoint Designer 2013 and InfoPath 2013 on July 14, 2026. SharePoint Server Subscription Edition follows the Modern Lifecycle Policy and is in support.\n\n## Source facts\n\nMicrosoft’s lifecycle pages for [SharePoint Server 2019](https://learn.microsoft.com/en-us/lifecycle/products/sharepoint-server-2019) and [SharePoint Server 2016](https://learn.microsoft.com/en-us/lifecycle/products/sharepoint-server-2016) show both under the Fixed Lifecycle Policy with extended support ending 7/15/2026 at 6:59:59 AM Pacific Time; mainstream support ended in January 2024 for 2019 and July 2021 for 2016.\n\nMicrosoft’s list of products ending support in 2026 includes Project Server 2016 and 2019, SharePoint Designer 2013, InfoPath 2013, SharePoint Server 2016 and SharePoint Server 2019 on July 14, 2026, and says that upon end of support there are no new security updates, non-security updates, assisted support options or online technical content updates.\n\nThe [SharePoint Server Subscription Edition lifecycle page](https://learn.microsoft.com/en-us/lifecycle/products/sharepoint-server-subscription-edition) shows it follows the Modern Lifecycle Policy, with a start date of 11/2/2021, and lists it as in support.\n\n## Applicability\n\nUse this for any on-premises SharePoint Server 2016 or 2019 farm. Migration paths, licensing and feature differences between Subscription Edition and SharePoint Online vary; confirm them before choosing a target.\n\n## DSE recommendation\n\nDSE recommends planning every SharePoint Server 2016 and 2019 farm’s move to SharePoint Server Subscription Edition or SharePoint Online now, and restricting access to farms that remain. Inventory sites, custom solutions, InfoPath forms and SharePoint Designer workflows that will not move as they are, assign an owner for each, and remove external publishing from old farms until they are retired.\n\n## Verification\n\nList each farm’s version and build, track its migration status, and confirm that no DNS records, reverse proxies or firewall rules still expose a retired farm.\n\n## Official references\n\n[Microsoft Lifecycle — SharePoint Server 2019](https://learn.microsoft.com/en-us/lifecycle/products/sharepoint-server-2019). [Microsoft Lifecycle — SharePoint Server 2016](https://learn.microsoft.com/en-us/lifecycle/products/sharepoint-server-2016). [Microsoft Lifecycle — SharePoint Server Subscription Edition](https://learn.microsoft.com/en-us/lifecycle/products/sharepoint-server-subscription-edition). Reviewed October 19, 2026." }, { "id": "https://update.dsesecurity.com/updates/microsoft-publisher-end-of-life-october-2026-convert-pub-files/", "slug": "microsoft-publisher-end-of-life-october-2026-convert-pub-files", "url": "https://update.dsesecurity.com/updates/microsoft-publisher-end-of-life-october-2026-convert-pub-files/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-publisher-end-of-life-october-2026-convert-pub-files.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-publisher-end-of-life-october-2026-convert-pub-files/" }, "title": "Microsoft Publisher reached end of life in October 2026: find and convert .pub files to PDF or Word", "summary": "Microsoft says Publisher reaches end of life in October 2026: Microsoft 365 subscribers lose access on or shortly after October 1, 2026 and can no longer open or edit Publisher files in Publisher, and perpetual-version support ends October 13, 2026. Microsoft recommends converting .pub files to PDF or Word.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-18T21:01:33+00:00", "modified_at": "2026-10-18T22:22:09+00:00", "reviewed_on": "2026-10-18", "reading_minutes": 2, "word_count": 371, "potentially_affected": "Organizations and users with Publisher files, such as flyers, newsletters, signage, forms and certificates, whether they used Publisher for Microsoft 365 or a perpetual Office version.", "dse_recommendation": "DSE recommends finding every .pub file in user folders, OneDrive and SharePoint and converting the ones still needed to PDF or Word, using a remaining perpetual Publisher install if Microsoft 365 access is gone.", "primary_source": { "name": "Microsoft Support — Microsoft Publisher will no longer be supported after October 2026", "url": "https://support.microsoft.com/en-us/publisher/microsoft-publisher-will-no-longer-be-supported-after-october-2026", "published_on": null, "authority": "Microsoft Support" }, "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": "Microsoft says Publisher reaches end of life in October 2026: Microsoft 365 subscribers lose access on or shortly after October 1, 2026 and can no longer open or edit Publisher files in Publisher, and perpetual-version support ends October 13, 2026. Microsoft recommends converting .pub files to PDF or Word.
\nMicrosoft’s Publisher end-of-life notice, which applies to Publisher for Microsoft 365 and Publisher 2007 through 2021, says Publisher reaches end of life in October 2026, after which it is no longer included in Microsoft 365 and existing on-premises suites are no longer supported. Microsoft 365 subscribers lose access to Publisher on or shortly after October 1, 2026 as the removal update rolls out, and support for the perpetual version ends on October 13, 2026, when Office LTSC 2021 and Consumer Office 2021 reach end of support.
\nMicrosoft recommended converting existing files to another format before 10/1/2026, saying Microsoft 365 subscribers would no longer be able to open or edit them in Publisher, while perpetual-version users can still install and use the app and access their files. It describes saving to PDF from Publisher, opening the PDF in Word for editing, and a sample PowerShell script for bulk export that requires a working, licensed Publisher installation.
\nMicrosoft says many common Publisher scenarios, such as branded templates, envelopes and labels, calendars, business cards and programs, are available in Word and PowerPoint, and notes that a Word document converted from PDF may lay out differently from the original, especially with many graphics. A file search for .pub on PCs, OneDrive or SharePoint can locate Publisher files.
\nUse this for any organization with Publisher files. Microsoft does not support third-party conversion tools, so test any you use on copies first.
\nDSE recommends finding every .pub file in user folders, OneDrive and SharePoint and converting the ones still needed to PDF or Word, using a remaining perpetual Publisher install if Microsoft 365 access is gone. Keep the original .pub files alongside the converted copies, rebuild frequently used templates such as signage and forms in Word or PowerPoint, and remove Publisher from deployment images.
\nRe-run the .pub search after conversion, spot-check converted documents for layout and missing images, and confirm users know which app replaces each template.
\nMicrosoft Support — Microsoft Publisher will no longer be supported after October 2026. Reviewed October 18, 2026.
", "content_text": "Microsoft says Publisher reaches end of life in October 2026: Microsoft 365 subscribers lose access on or shortly after October 1, 2026 and can no longer open or edit Publisher files in Publisher, and perpetual-version support ends October 13, 2026. Microsoft recommends converting .pub files to PDF or Word.\nSource facts\nMicrosoft’s Publisher end-of-life notice, which applies to Publisher for Microsoft 365 and Publisher 2007 through 2021, says Publisher reaches end of life in October 2026, after which it is no longer included in Microsoft 365 and existing on-premises suites are no longer supported. Microsoft 365 subscribers lose access to Publisher on or shortly after October 1, 2026 as the removal update rolls out, and support for the perpetual version ends on October 13, 2026, when Office LTSC 2021 and Consumer Office 2021 reach end of support.\nMicrosoft recommended converting existing files to another format before 10/1/2026, saying Microsoft 365 subscribers would no longer be able to open or edit them in Publisher, while perpetual-version users can still install and use the app and access their files. It describes saving to PDF from Publisher, opening the PDF in Word for editing, and a sample PowerShell script for bulk export that requires a working, licensed Publisher installation.\nMicrosoft says many common Publisher scenarios, such as branded templates, envelopes and labels, calendars, business cards and programs, are available in Word and PowerPoint, and notes that a Word document converted from PDF may lay out differently from the original, especially with many graphics. A file search for .pub on PCs, OneDrive or SharePoint can locate Publisher files.\nApplicability\nUse this for any organization with Publisher files. Microsoft does not support third-party conversion tools, so test any you use on copies first.\nDSE recommendation\nDSE recommends finding every .pub file in user folders, OneDrive and SharePoint and converting the ones still needed to PDF or Word, using a remaining perpetual Publisher install if Microsoft 365 access is gone. Keep the original .pub files alongside the converted copies, rebuild frequently used templates such as signage and forms in Word or PowerPoint, and remove Publisher from deployment images.\nVerification\nRe-run the .pub search after conversion, spot-check converted documents for layout and missing images, and confirm users know which app replaces each template.\nOfficial reference\nMicrosoft Support — Microsoft Publisher will no longer be supported after October 2026. Reviewed October 18, 2026.", "content_markdown": "Microsoft says Publisher reaches end of life in October 2026: Microsoft 365 subscribers lose access on or shortly after October 1, 2026 and can no longer open or edit Publisher files in Publisher, and perpetual-version support ends October 13, 2026. Microsoft recommends converting .pub files to PDF or Word.\n\n## Source facts\n\nMicrosoft’s [Publisher end-of-life notice](https://support.microsoft.com/en-us/publisher/microsoft-publisher-will-no-longer-be-supported-after-october-2026), which applies to Publisher for Microsoft 365 and Publisher 2007 through 2021, says Publisher reaches end of life in October 2026, after which it is no longer included in Microsoft 365 and existing on-premises suites are no longer supported. Microsoft 365 subscribers lose access to Publisher on or shortly after October 1, 2026 as the removal update rolls out, and support for the perpetual version ends on October 13, 2026, when Office LTSC 2021 and Consumer Office 2021 reach end of support.\n\nMicrosoft recommended converting existing files to another format before 10/1/2026, saying Microsoft 365 subscribers would no longer be able to open or edit them in Publisher, while perpetual-version users can still install and use the app and access their files. It describes saving to PDF from Publisher, opening the PDF in Word for editing, and a sample PowerShell script for bulk export that requires a working, licensed Publisher installation.\n\nMicrosoft says many common Publisher scenarios, such as branded templates, envelopes and labels, calendars, business cards and programs, are available in Word and PowerPoint, and notes that a Word document converted from PDF may lay out differently from the original, especially with many graphics. A file search for .pub on PCs, OneDrive or SharePoint can locate Publisher files.\n\n## Applicability\n\nUse this for any organization with Publisher files. Microsoft does not support third-party conversion tools, so test any you use on copies first.\n\n## DSE recommendation\n\nDSE recommends finding every .pub file in user folders, OneDrive and SharePoint and converting the ones still needed to PDF or Word, using a remaining perpetual Publisher install if Microsoft 365 access is gone. Keep the original .pub files alongside the converted copies, rebuild frequently used templates such as signage and forms in Word or PowerPoint, and remove Publisher from deployment images.\n\n## Verification\n\nRe-run the .pub search after conversion, spot-check converted documents for layout and missing images, and confirm users know which app replaces each template.\n\n## Official reference\n\n[Microsoft Support — Microsoft Publisher will no longer be supported after October 2026](https://support.microsoft.com/en-us/publisher/microsoft-publisher-will-no-longer-be-supported-after-october-2026). Reviewed October 18, 2026." }, { "id": "https://update.dsesecurity.com/updates/exchange-online-ews-retirement-october-2026-april-2027-appid-allow-list/", "slug": "exchange-online-ews-retirement-october-2026-april-2027-appid-allow-list", "url": "https://update.dsesecurity.com/updates/exchange-online-ews-retirement-october-2026-april-2027-appid-allow-list/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/exchange-online-ews-retirement-october-2026-april-2027-appid-allow-list.md", "json": "https://update.dsesecurity.com/api/v1/posts/exchange-online-ews-retirement-october-2026-april-2027-appid-allow-list/" }, "title": "Exchange Online is disabling EWS from October 2026 to April 2027: inventory apps and set an AppID allow list", "summary": "Microsoft’s EWS deprecation page says Exchange Web Services starts to be disabled globally in Exchange Online in October 2026 and is fully disabled in April 2027. Under enforcement, setting EWSEnabled to True without an EWSAllowedAppIDs list blocks all EWS traffic, and tenants left unset will have EWS disabled.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-18T21:01:32+00:00", "modified_at": "2026-10-18T22:22:09+00:00", "reviewed_on": "2026-10-18", "reading_minutes": 2, "word_count": 388, "potentially_affected": "Microsoft 365 organizations with applications that read or write Exchange Online mailboxes through EWS, such as backup, archiving, CRM, scheduling and line-of-business tools, and the vendors that build them.", "dse_recommendation": "DSE recommends running the EWS usage reports now, listing every application that still needs EWS, and setting EWSAllowedAppIDs to only those App IDs as phased disablement begins.", "primary_source": { "name": "Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online", "url": "https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online", "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": "Microsoft’s EWS deprecation page says Exchange Web Services starts to be disabled globally in Exchange Online in October 2026 and is fully disabled in April 2027. Under enforcement, setting EWSEnabled to True without an EWSAllowedAppIDs list blocks all EWS traffic, and tenants left unset will have EWS disabled.
\nMicrosoft’s EWS deprecation page for Exchange Online, last updated September 4, 2026, says EWS starts to be disabled globally for all organizations in October 2026 and is fully disabled in April 2027. It says the January 2024 Midnight Blizzard incident involved EWS and widened the effort to include Microsoft’s own applications, and that capabilities not on its roadmap should not be expected in Microsoft Graph or the Exchange Admin API before EWS is fully disabled.
\nThe Exchange Team’s June 19, 2026 post introduced EWSAllowedAppIDs, a tenant-level allow list of App IDs permitted to use EWS when EWSEnabled is True. Starting October 2026, EWSEnabled set to True with no allow list blocks all EWS traffic, and tenants left unset will have EWSEnabled set to False as part of the phased rollout.
\nThe post says Microsoft first-party apps such as Office and Power Query for Excel must be on the list if they appear in usage reports and are still needed, that list changes can take up to 24 hours to take effect, and that setting the property replaces the full list. Microsoft recommends inventorying EWS use with its usage reports and working with vendors that still rely on EWS.
\nUse this for Exchange Online tenants. Microsoft’s pages carry the current timeline and rollout details, which can change; check them and the Message Center before each step.
\nDSE recommends running the EWS usage reports now, listing every application that still needs EWS, and setting EWSAllowedAppIDs to only those App IDs as phased disablement begins. Ask each vendor for its Microsoft Graph migration date, retire unused integrations, read the current list before every change so no entry is lost, and set EWSEnabled to True only once the list is complete.
\nAfter each change, wait 24 hours, confirm the list with Get-OrganizationConfig, test each allowed application, and review usage reports for blocked apps that were missed.
\nMicrosoft Learn — Deprecation of Exchange Web Services in Exchange Online. Microsoft Exchange Team Blog — Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement (June 19, 2026). Reviewed October 18, 2026.
", "content_text": "Microsoft’s EWS deprecation page says Exchange Web Services starts to be disabled globally in Exchange Online in October 2026 and is fully disabled in April 2027. Under enforcement, setting EWSEnabled to True without an EWSAllowedAppIDs list blocks all EWS traffic, and tenants left unset will have EWS disabled.\nSource facts\nMicrosoft’s EWS deprecation page for Exchange Online, last updated September 4, 2026, says EWS starts to be disabled globally for all organizations in October 2026 and is fully disabled in April 2027. It says the January 2024 Midnight Blizzard incident involved EWS and widened the effort to include Microsoft’s own applications, and that capabilities not on its roadmap should not be expected in Microsoft Graph or the Exchange Admin API before EWS is fully disabled.\nThe Exchange Team’s June 19, 2026 post introduced EWSAllowedAppIDs, a tenant-level allow list of App IDs permitted to use EWS when EWSEnabled is True. Starting October 2026, EWSEnabled set to True with no allow list blocks all EWS traffic, and tenants left unset will have EWSEnabled set to False as part of the phased rollout.\nThe post says Microsoft first-party apps such as Office and Power Query for Excel must be on the list if they appear in usage reports and are still needed, that list changes can take up to 24 hours to take effect, and that setting the property replaces the full list. Microsoft recommends inventorying EWS use with its usage reports and working with vendors that still rely on EWS.\nApplicability\nUse this for Exchange Online tenants. Microsoft’s pages carry the current timeline and rollout details, which can change; check them and the Message Center before each step.\nDSE recommendation\nDSE recommends running the EWS usage reports now, listing every application that still needs EWS, and setting EWSAllowedAppIDs to only those App IDs as phased disablement begins. Ask each vendor for its Microsoft Graph migration date, retire unused integrations, read the current list before every change so no entry is lost, and set EWSEnabled to True only once the list is complete.\nVerification\nAfter each change, wait 24 hours, confirm the list with Get-OrganizationConfig, test each allowed application, and review usage reports for blocked apps that were missed.\nOfficial references\nMicrosoft Learn — Deprecation of Exchange Web Services in Exchange Online. Microsoft Exchange Team Blog — Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement (June 19, 2026). Reviewed October 18, 2026.", "content_markdown": "Microsoft’s EWS deprecation page says Exchange Web Services starts to be disabled globally in Exchange Online in October 2026 and is fully disabled in April 2027. Under enforcement, setting EWSEnabled to True without an EWSAllowedAppIDs list blocks all EWS traffic, and tenants left unset will have EWS disabled.\n\n## Source facts\n\nMicrosoft’s [EWS deprecation page for Exchange Online](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online), last updated September 4, 2026, says EWS starts to be disabled globally for all organizations in October 2026 and is fully disabled in April 2027. It says the January 2024 Midnight Blizzard incident involved EWS and widened the effort to include Microsoft’s own applications, and that capabilities not on its roadmap should not be expected in Microsoft Graph or the Exchange Admin API before EWS is fully disabled.\n\nThe Exchange Team’s [June 19, 2026 post](https://techcommunity.microsoft.com/blog/exchange/introducing-ewsallowedappids-preparing-for-the-final-phase-of-ews-retirement/4529471) introduced EWSAllowedAppIDs, a tenant-level allow list of App IDs permitted to use EWS when EWSEnabled is True. Starting October 2026, EWSEnabled set to True with no allow list blocks all EWS traffic, and tenants left unset will have EWSEnabled set to False as part of the phased rollout.\n\nThe post says Microsoft first-party apps such as Office and Power Query for Excel must be on the list if they appear in usage reports and are still needed, that list changes can take up to 24 hours to take effect, and that setting the property replaces the full list. Microsoft recommends inventorying EWS use with its usage reports and working with vendors that still rely on EWS.\n\n## Applicability\n\nUse this for Exchange Online tenants. Microsoft’s pages carry the current timeline and rollout details, which can change; check them and the Message Center before each step.\n\n## DSE recommendation\n\nDSE recommends running the EWS usage reports now, listing every application that still needs EWS, and setting EWSAllowedAppIDs to only those App IDs as phased disablement begins. Ask each vendor for its Microsoft Graph migration date, retire unused integrations, read the current list before every change so no entry is lost, and set EWSEnabled to True only once the list is complete.\n\n## Verification\n\nAfter each change, wait 24 hours, confirm the list with Get-OrganizationConfig, test each allowed application, and review usage reports for blocked apps that were missed.\n\n## Official references\n\n[Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online). [Microsoft Exchange Team Blog — Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement (June 19, 2026)](https://techcommunity.microsoft.com/blog/exchange/introducing-ewsallowedappids-preparing-for-the-final-phase-of-ews-retirement/4529471). Reviewed October 18, 2026." }, { "id": "https://update.dsesecurity.com/updates/office-2016-2019-2021-ltsc-2021-end-of-support-perpetual-office-replacement/", "slug": "office-2016-2019-2021-ltsc-2021-end-of-support-perpetual-office-replacement", "url": "https://update.dsesecurity.com/updates/office-2016-2019-2021-ltsc-2021-end-of-support-perpetual-office-replacement/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/office-2016-2019-2021-ltsc-2021-end-of-support-perpetual-office-replacement.md", "json": "https://update.dsesecurity.com/api/v1/posts/office-2016-2019-2021-ltsc-2021-end-of-support-perpetual-office-replacement/" }, "title": "Office 2016 and 2019 lost support in October 2025, and Office 2021 and Office LTSC 2021 followed in October 2026", "summary": "Microsoft’s lifecycle pages list Office 2016 and Office 2019 extended support ending 10/15/2025, and Office 2021 and Office LTSC 2021 ending 10/14/2026 (6:59:59 AM Pacific). Microsoft’s 2025 list shows the 2016 and 2019 apps, including Outlook, Publisher and Skype for Business, ending support on October 14, 2025.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-18T21:01:21+00:00", "modified_at": "2026-10-18T22:22:08+00:00", "reviewed_on": "2026-10-18", "reading_minutes": 2, "word_count": 318, "potentially_affected": "Organizations and users running perpetual-license Office 2016, 2019, 2021 or Office LTSC 2021, including Outlook installs that connect to business mailboxes.", "dse_recommendation": "DSE recommends replacing Office 2016, 2019, 2021 and LTSC 2021 installs with a supported Office version and removing the old suites.", "primary_source": { "name": "Microsoft Lifecycle — Microsoft Office 2016", "url": "https://learn.microsoft.com/en-us/lifecycle/products/microsoft-office-2016", "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": "Microsoft’s lifecycle pages list Office 2016 and Office 2019 extended support ending 10/15/2025, and Office 2021 and Office LTSC 2021 ending 10/14/2026 (6:59:59 AM Pacific). Microsoft’s 2025 list shows the 2016 and 2019 apps, including Outlook, Publisher and Skype for Business, ending support on October 14, 2025.
\nMicrosoft’s lifecycle pages for Office 2016 and Office 2019 show both under the Fixed Lifecycle Policy with extended support ending 10/15/2025 at 6:59:59 AM Pacific Time, for editions including Home and Business, Home and Student, Professional and Professional Plus. Microsoft’s list of products ending support in 2025 includes Access, Excel, Outlook, PowerPoint, Project, Publisher, Skype for Business, Visio and Word 2016 and 2019, plus OneNote 2016, all on October 14, 2025.
\nThe list says that upon retirement or end of support there are no new security updates, non-security updates, free or paid assisted support options or online technical content updates.
\nThe Office 2021 lifecycle page lists the Home and Business, Home and Student and Professional editions, including Mac versions of the first two, under the Modern Lifecycle Policy with a retirement date of 10/14/2026. The Office LTSC 2021 page lists the Standard and Standard for Mac editions under the Fixed Lifecycle Policy with a mainstream end date of 10/14/2026 and no extended support date.
\nUse this for any device with a perpetual Office license. Microsoft 365 subscription apps and newer perpetual releases follow their own lifecycle pages; check them before choosing a replacement.
\nDSE recommends replacing Office 2016, 2019, 2021 and LTSC 2021 installs with a supported Office version and removing the old suites. Inventory installed Office versions from management tools, include Visio and Project licenses in the plan, and test templates, macros and add-ins against the replacement before rollout.
\nRun a software inventory report after the rollout, confirm no 2016, 2019 or 2021 Office builds remain, and check that Outlook clients connecting to company mail are on a supported version.
\nMicrosoft Lifecycle — Microsoft Office 2016. Microsoft Lifecycle — Microsoft Office 2019. Microsoft Lifecycle — Ending Support in 2025. Microsoft Lifecycle — Office 2021. Microsoft Lifecycle — Office LTSC 2021. Reviewed October 18, 2026.
", "content_text": "Microsoft’s lifecycle pages list Office 2016 and Office 2019 extended support ending 10/15/2025, and Office 2021 and Office LTSC 2021 ending 10/14/2026 (6:59:59 AM Pacific). Microsoft’s 2025 list shows the 2016 and 2019 apps, including Outlook, Publisher and Skype for Business, ending support on October 14, 2025.\nSource facts\nMicrosoft’s lifecycle pages for Office 2016 and Office 2019 show both under the Fixed Lifecycle Policy with extended support ending 10/15/2025 at 6:59:59 AM Pacific Time, for editions including Home and Business, Home and Student, Professional and Professional Plus. Microsoft’s list of products ending support in 2025 includes Access, Excel, Outlook, PowerPoint, Project, Publisher, Skype for Business, Visio and Word 2016 and 2019, plus OneNote 2016, all on October 14, 2025.\nThe list says that upon retirement or end of support there are no new security updates, non-security updates, free or paid assisted support options or online technical content updates.\nThe Office 2021 lifecycle page lists the Home and Business, Home and Student and Professional editions, including Mac versions of the first two, under the Modern Lifecycle Policy with a retirement date of 10/14/2026. The Office LTSC 2021 page lists the Standard and Standard for Mac editions under the Fixed Lifecycle Policy with a mainstream end date of 10/14/2026 and no extended support date.\nApplicability\nUse this for any device with a perpetual Office license. Microsoft 365 subscription apps and newer perpetual releases follow their own lifecycle pages; check them before choosing a replacement.\nDSE recommendation\nDSE recommends replacing Office 2016, 2019, 2021 and LTSC 2021 installs with a supported Office version and removing the old suites. Inventory installed Office versions from management tools, include Visio and Project licenses in the plan, and test templates, macros and add-ins against the replacement before rollout.\nVerification\nRun a software inventory report after the rollout, confirm no 2016, 2019 or 2021 Office builds remain, and check that Outlook clients connecting to company mail are on a supported version.\nOfficial references\nMicrosoft Lifecycle — Microsoft Office 2016. Microsoft Lifecycle — Microsoft Office 2019. Microsoft Lifecycle — Ending Support in 2025. Microsoft Lifecycle — Office 2021. Microsoft Lifecycle — Office LTSC 2021. Reviewed October 18, 2026.", "content_markdown": "Microsoft’s lifecycle pages list Office 2016 and Office 2019 extended support ending 10/15/2025, and Office 2021 and Office LTSC 2021 ending 10/14/2026 (6:59:59 AM Pacific). Microsoft’s 2025 list shows the 2016 and 2019 apps, including Outlook, Publisher and Skype for Business, ending support on October 14, 2025.\n\n## Source facts\n\nMicrosoft’s lifecycle pages for [Office 2016](https://learn.microsoft.com/en-us/lifecycle/products/microsoft-office-2016) and [Office 2019](https://learn.microsoft.com/en-us/lifecycle/products/microsoft-office-2019) show both under the Fixed Lifecycle Policy with extended support ending 10/15/2025 at 6:59:59 AM Pacific Time, for editions including Home and Business, Home and Student, Professional and Professional Plus. Microsoft’s [list of products ending support in 2025](https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2025) includes Access, Excel, Outlook, PowerPoint, Project, Publisher, Skype for Business, Visio and Word 2016 and 2019, plus OneNote 2016, all on October 14, 2025.\n\nThe list says that upon retirement or end of support there are no new security updates, non-security updates, free or paid assisted support options or online technical content updates.\n\nThe [Office 2021 lifecycle page](https://learn.microsoft.com/en-us/lifecycle/products/office-2021) lists the Home and Business, Home and Student and Professional editions, including Mac versions of the first two, under the Modern Lifecycle Policy with a retirement date of 10/14/2026. The [Office LTSC 2021 page](https://learn.microsoft.com/en-us/lifecycle/products/office-ltsc-2021) lists the Standard and Standard for Mac editions under the Fixed Lifecycle Policy with a mainstream end date of 10/14/2026 and no extended support date.\n\n## Applicability\n\nUse this for any device with a perpetual Office license. Microsoft 365 subscription apps and newer perpetual releases follow their own lifecycle pages; check them before choosing a replacement.\n\n## DSE recommendation\n\nDSE recommends replacing Office 2016, 2019, 2021 and LTSC 2021 installs with a supported Office version and removing the old suites. Inventory installed Office versions from management tools, include Visio and Project licenses in the plan, and test templates, macros and add-ins against the replacement before rollout.\n\n## Verification\n\nRun a software inventory report after the rollout, confirm no 2016, 2019 or 2021 Office builds remain, and check that Outlook clients connecting to company mail are on a supported version.\n\n## Official references\n\n[Microsoft Lifecycle — Microsoft Office 2016](https://learn.microsoft.com/en-us/lifecycle/products/microsoft-office-2016). [Microsoft Lifecycle — Microsoft Office 2019](https://learn.microsoft.com/en-us/lifecycle/products/microsoft-office-2019). [Microsoft Lifecycle — Ending Support in 2025](https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2025). [Microsoft Lifecycle — Office 2021](https://learn.microsoft.com/en-us/lifecycle/products/office-2021). [Microsoft Lifecycle — Office LTSC 2021](https://learn.microsoft.com/en-us/lifecycle/products/office-ltsc-2021). Reviewed October 18, 2026." }, { "id": "https://update.dsesecurity.com/updates/exchange-server-2016-2019-end-of-support-subscription-edition-upgrade/", "slug": "exchange-server-2016-2019-end-of-support-subscription-edition-upgrade", "url": "https://update.dsesecurity.com/updates/exchange-server-2016-2019-end-of-support-subscription-edition-upgrade/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/exchange-server-2016-2019-end-of-support-subscription-edition-upgrade.md", "json": "https://update.dsesecurity.com/api/v1/posts/exchange-server-2016-2019-end-of-support-subscription-edition-upgrade/" }, "title": "Exchange Server 2016 and 2019 have been out of support since October 14, 2025: move to Exchange SE or online", "summary": "Microsoft’s lifecycle pages show Exchange Server 2016 and 2019 reached end of support on October 14, 2025, after which there are no new security updates or assisted support. Exchange Server Subscription Edition, which started July 1, 2025 under the Modern Lifecycle Policy, is listed as in support.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "managed-it", "label": "Managed IT operations", "alt": "A controlled technology lifecycle progressing from assessment to approved production.", "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-18T21:01:17+00:00", "modified_at": "2026-10-18T22:22:08+00:00", "reviewed_on": "2026-10-18", "reading_minutes": 2, "word_count": 327, "potentially_affected": "Organizations still running on-premises Exchange Server 2016 or 2019, including servers kept for hybrid management or SMTP relay, and the providers who maintain them.", "dse_recommendation": "DSE recommends retiring or upgrading every Exchange Server 2016 and 2019 installation, and treating any that remain as unpatched servers until they are gone.", "primary_source": { "name": "Microsoft Lifecycle — Exchange Server 2019", "url": "https://learn.microsoft.com/en-us/lifecycle/products/exchange-server-2019", "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": "Microsoft’s lifecycle pages show Exchange Server 2016 and 2019 reached end of support on October 14, 2025, after which there are no new security updates or assisted support. Exchange Server Subscription Edition, which started July 1, 2025 under the Modern Lifecycle Policy, is listed as in support.
\nMicrosoft’s lifecycle pages for Exchange Server 2019 and Exchange Server 2016 show both follow the Fixed Lifecycle Policy, with mainstream support ending in January 2024 for 2019 and in October 2020 for 2016. Microsoft’s list of products ending support in 2025 shows both reaching end of support on October 14, 2025.
\nThat list says that upon retirement or end of support there are no new security updates, non-security updates, free or paid assisted support options or online technical content updates. The Exchange Server 2016 page tells customers to move to the most recent cumulative update for Exchange Server 2019 to be prepared for an in-place upgrade to Exchange Server SE.
\nMicrosoft’s Exchange Server Subscription Edition lifecycle page shows it follows the Modern Lifecycle Policy, with a start date of July 1, 2025, and lists it as in support.
\nUse this for any organization with on-premises Exchange servers, including servers kept only for hybrid management or relay. Licensing for Exchange Server SE and migration paths to Exchange Online vary; confirm them with Microsoft or a licensing partner.
\nDSE recommends retiring or upgrading every Exchange Server 2016 and 2019 installation, and treating any that remain as unpatched servers until they are gone. Move mailboxes to Exchange Online or Exchange Server SE, bring Exchange 2019 to its latest cumulative update before an in-place upgrade, repoint scanners, alarm panels and applications that relay through Exchange, and restrict any remaining server to internal access.
\nInventory Exchange servers and their versions, confirm each is retired or on Exchange Server SE, and check that no DNS records, firewall rules or connectors still point to retired servers.
\nMicrosoft Lifecycle — Exchange Server 2019. Microsoft Lifecycle — Exchange Server 2016. Microsoft Lifecycle — Ending Support in 2025. Microsoft Lifecycle — Exchange Server Subscription Edition. Reviewed October 18, 2026.
", "content_text": "Microsoft’s lifecycle pages show Exchange Server 2016 and 2019 reached end of support on October 14, 2025, after which there are no new security updates or assisted support. Exchange Server Subscription Edition, which started July 1, 2025 under the Modern Lifecycle Policy, is listed as in support.\nSource facts\nMicrosoft’s lifecycle pages for Exchange Server 2019 and Exchange Server 2016 show both follow the Fixed Lifecycle Policy, with mainstream support ending in January 2024 for 2019 and in October 2020 for 2016. Microsoft’s list of products ending support in 2025 shows both reaching end of support on October 14, 2025.\nThat list says that upon retirement or end of support there are no new security updates, non-security updates, free or paid assisted support options or online technical content updates. The Exchange Server 2016 page tells customers to move to the most recent cumulative update for Exchange Server 2019 to be prepared for an in-place upgrade to Exchange Server SE.\nMicrosoft’s Exchange Server Subscription Edition lifecycle page shows it follows the Modern Lifecycle Policy, with a start date of July 1, 2025, and lists it as in support.\nApplicability\nUse this for any organization with on-premises Exchange servers, including servers kept only for hybrid management or relay. Licensing for Exchange Server SE and migration paths to Exchange Online vary; confirm them with Microsoft or a licensing partner.\nDSE recommendation\nDSE recommends retiring or upgrading every Exchange Server 2016 and 2019 installation, and treating any that remain as unpatched servers until they are gone. Move mailboxes to Exchange Online or Exchange Server SE, bring Exchange 2019 to its latest cumulative update before an in-place upgrade, repoint scanners, alarm panels and applications that relay through Exchange, and restrict any remaining server to internal access.\nVerification\nInventory Exchange servers and their versions, confirm each is retired or on Exchange Server SE, and check that no DNS records, firewall rules or connectors still point to retired servers.\nOfficial references\nMicrosoft Lifecycle — Exchange Server 2019. Microsoft Lifecycle — Exchange Server 2016. Microsoft Lifecycle — Ending Support in 2025. Microsoft Lifecycle — Exchange Server Subscription Edition. Reviewed October 18, 2026.", "content_markdown": "Microsoft’s lifecycle pages show Exchange Server 2016 and 2019 reached end of support on October 14, 2025, after which there are no new security updates or assisted support. Exchange Server Subscription Edition, which started July 1, 2025 under the Modern Lifecycle Policy, is listed as in support.\n\n## Source facts\n\nMicrosoft’s lifecycle pages for [Exchange Server 2019](https://learn.microsoft.com/en-us/lifecycle/products/exchange-server-2019) and [Exchange Server 2016](https://learn.microsoft.com/en-us/lifecycle/products/exchange-server-2016) show both follow the Fixed Lifecycle Policy, with mainstream support ending in January 2024 for 2019 and in October 2020 for 2016. Microsoft’s [list of products ending support in 2025](https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2025) shows both reaching end of support on October 14, 2025.\n\nThat list says that upon retirement or end of support there are no new security updates, non-security updates, free or paid assisted support options or online technical content updates. The Exchange Server 2016 page tells customers to move to the most recent cumulative update for Exchange Server 2019 to be prepared for an in-place upgrade to Exchange Server SE.\n\nMicrosoft’s [Exchange Server Subscription Edition lifecycle page](https://learn.microsoft.com/en-us/lifecycle/products/exchange-server-subscription-edition) shows it follows the Modern Lifecycle Policy, with a start date of July 1, 2025, and lists it as in support.\n\n## Applicability\n\nUse this for any organization with on-premises Exchange servers, including servers kept only for hybrid management or relay. Licensing for Exchange Server SE and migration paths to Exchange Online vary; confirm them with Microsoft or a licensing partner.\n\n## DSE recommendation\n\nDSE recommends retiring or upgrading every Exchange Server 2016 and 2019 installation, and treating any that remain as unpatched servers until they are gone. Move mailboxes to Exchange Online or Exchange Server SE, bring Exchange 2019 to its latest cumulative update before an in-place upgrade, repoint scanners, alarm panels and applications that relay through Exchange, and restrict any remaining server to internal access.\n\n## Verification\n\nInventory Exchange servers and their versions, confirm each is retired or on Exchange Server SE, and check that no DNS records, firewall rules or connectors still point to retired servers.\n\n## Official references\n\n[Microsoft Lifecycle — Exchange Server 2019](https://learn.microsoft.com/en-us/lifecycle/products/exchange-server-2019). [Microsoft Lifecycle — Exchange Server 2016](https://learn.microsoft.com/en-us/lifecycle/products/exchange-server-2016). [Microsoft Lifecycle — Ending Support in 2025](https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2025). [Microsoft Lifecycle — Exchange Server Subscription Edition](https://learn.microsoft.com/en-us/lifecycle/products/exchange-server-subscription-edition). Reviewed October 18, 2026." }, { "id": "https://update.dsesecurity.com/updates/fcc-sim-swap-port-out-fraud-rules-account-lock-notifications/", "slug": "fcc-sim-swap-port-out-fraud-rules-account-lock-notifications", "url": "https://update.dsesecurity.com/updates/fcc-sim-swap-port-out-fraud-rules-account-lock-notifications/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/fcc-sim-swap-port-out-fraud-rules-account-lock-notifications.md", "json": "https://update.dsesecurity.com/api/v1/posts/fcc-sim-swap-port-out-fraud-rules-account-lock-notifications/" }, "title": "Use carrier account locks and change alerts against SIM swaps, and check when the FCC’s new rules take effect", "summary": "The FCC’s November 2023 SIM swap and port-out fraud order requires wireless carriers to authenticate customers before moving a number, notify them of SIM changes and port requests, and offer account locks. A 2024 bureau order tied compliance to a later Federal Register notice.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-18T21:01:04+00:00", "modified_at": "2026-10-18T22:22:08+00:00", "reviewed_on": "2026-10-18", "reading_minutes": 2, "word_count": 417, "potentially_affected": "Organizations with company mobile phones, executives and administrators whose phone numbers receive SMS or voice verification codes, and anyone managing carrier business accounts.", "dse_recommendation": "DSE recommends turning on every available carrier account lock and port-out protection for company phone lines, and removing SMS codes from privileged accounts.", "primary_source": { "name": "Federal Communications Commission — FCC Adopts Rules to Protect Consumers’ Cell Phone Accounts (November 15, 2023)", "url": "https://docs.fcc.gov/public/attachments/DOC-398483A1.txt", "published_on": null, "authority": "docs.fcc.gov" }, "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": "The FCC’s November 2023 SIM swap and port-out fraud order requires wireless carriers to authenticate customers before moving a number, notify them of SIM changes and port requests, and offer account locks. A 2024 bureau order tied compliance to a later Federal Register notice.
\nThe FCC’s November 15, 2023 announcement says new rules require wireless providers to adopt secure methods of authenticating a customer before redirecting a customer’s phone number to a new device or provider, and to immediately notify customers whenever a SIM change or port-out request is made on their accounts. It describes SIM swapping as a bad actor convincing the carrier to move the victim’s service to a phone the bad actor holds, and port-out fraud as opening an account at another carrier and transferring the victim’s number to it.
\nA later Wireline Competition Bureau order, DA 24-649, summarizes the rules as also requiring processes for failed authentication attempts, employee training, and safeguards that keep customer-facing employees from accessing account data until customers are authenticated. Carriers must offer customers the option to lock their accounts to block SIM changes and number ports and give advance notice of available account protection mechanisms.
\nThat order denied an industry request to waive all of the rules until March 10, 2025, but waived compliance so that all of them become required together only after OMB completes its Paperwork Reduction Act review and the Commission publishes a compliance date in the Federal Register.
\nUse this for any organization that relies on mobile numbers for staff contact or account verification. Whether and when each carrier must comply depends on the compliance-date notice described in the bureau order; check the FCC’s current docket before relying on a specific rule.
\nDSE recommends turning on every available carrier account lock and port-out protection for company phone lines, and removing SMS codes from privileged accounts. Set a strong carrier account PIN, route SIM-change and port-out alerts to the IT team as well as the user, and move administrators and finance staff to phishing-resistant sign-in so a hijacked number cannot reset their access.
\nConfirm lock and PIN settings on the carrier business account quarterly, test that a SIM-change alert reaches IT, and review identity provider settings to verify privileged accounts no longer accept SMS or voice codes.
\nFederal Communications Commission — FCC Adopts Rules to Protect Consumers’ Cell Phone Accounts (November 15, 2023). FCC Wireline Competition Bureau — Order DA 24-649 on the SIM Swap and Port-Out Fraud Order. Reviewed October 18, 2026.
", "content_text": "The FCC’s November 2023 SIM swap and port-out fraud order requires wireless carriers to authenticate customers before moving a number, notify them of SIM changes and port requests, and offer account locks. A 2024 bureau order tied compliance to a later Federal Register notice.\nSource facts\nThe FCC’s November 15, 2023 announcement says new rules require wireless providers to adopt secure methods of authenticating a customer before redirecting a customer’s phone number to a new device or provider, and to immediately notify customers whenever a SIM change or port-out request is made on their accounts. It describes SIM swapping as a bad actor convincing the carrier to move the victim’s service to a phone the bad actor holds, and port-out fraud as opening an account at another carrier and transferring the victim’s number to it.\nA later Wireline Competition Bureau order, DA 24-649, summarizes the rules as also requiring processes for failed authentication attempts, employee training, and safeguards that keep customer-facing employees from accessing account data until customers are authenticated. Carriers must offer customers the option to lock their accounts to block SIM changes and number ports and give advance notice of available account protection mechanisms.\nThat order denied an industry request to waive all of the rules until March 10, 2025, but waived compliance so that all of them become required together only after OMB completes its Paperwork Reduction Act review and the Commission publishes a compliance date in the Federal Register.\nApplicability\nUse this for any organization that relies on mobile numbers for staff contact or account verification. Whether and when each carrier must comply depends on the compliance-date notice described in the bureau order; check the FCC’s current docket before relying on a specific rule.\nDSE recommendation\nDSE recommends turning on every available carrier account lock and port-out protection for company phone lines, and removing SMS codes from privileged accounts. Set a strong carrier account PIN, route SIM-change and port-out alerts to the IT team as well as the user, and move administrators and finance staff to phishing-resistant sign-in so a hijacked number cannot reset their access.\nVerification\nConfirm lock and PIN settings on the carrier business account quarterly, test that a SIM-change alert reaches IT, and review identity provider settings to verify privileged accounts no longer accept SMS or voice codes.\nOfficial references\nFederal Communications Commission — FCC Adopts Rules to Protect Consumers’ Cell Phone Accounts (November 15, 2023). FCC Wireline Competition Bureau — Order DA 24-649 on the SIM Swap and Port-Out Fraud Order. Reviewed October 18, 2026.", "content_markdown": "The FCC’s November 2023 SIM swap and port-out fraud order requires wireless carriers to authenticate customers before moving a number, notify them of SIM changes and port requests, and offer account locks. A 2024 bureau order tied compliance to a later Federal Register notice.\n\n## Source facts\n\nThe FCC’s [November 15, 2023 announcement](https://docs.fcc.gov/public/attachments/DOC-398483A1.txt) says new rules require wireless providers to adopt secure methods of authenticating a customer before redirecting a customer’s phone number to a new device or provider, and to immediately notify customers whenever a SIM change or port-out request is made on their accounts. It describes SIM swapping as a bad actor convincing the carrier to move the victim’s service to a phone the bad actor holds, and port-out fraud as opening an account at another carrier and transferring the victim’s number to it.\n\nA later Wireline Competition Bureau [order, DA 24-649](https://docs.fcc.gov/public/attachments/DA-24-649A1.pdf), summarizes the rules as also requiring processes for failed authentication attempts, employee training, and safeguards that keep customer-facing employees from accessing account data until customers are authenticated. Carriers must offer customers the option to lock their accounts to block SIM changes and number ports and give advance notice of available account protection mechanisms.\n\nThat order denied an industry request to waive all of the rules until March 10, 2025, but waived compliance so that all of them become required together only after OMB completes its Paperwork Reduction Act review and the Commission publishes a compliance date in the Federal Register.\n\n## Applicability\n\nUse this for any organization that relies on mobile numbers for staff contact or account verification. Whether and when each carrier must comply depends on the compliance-date notice described in the bureau order; check the FCC’s current docket before relying on a specific rule.\n\n## DSE recommendation\n\nDSE recommends turning on every available carrier account lock and port-out protection for company phone lines, and removing SMS codes from privileged accounts. Set a strong carrier account PIN, route SIM-change and port-out alerts to the IT team as well as the user, and move administrators and finance staff to phishing-resistant sign-in so a hijacked number cannot reset their access.\n\n## Verification\n\nConfirm lock and PIN settings on the carrier business account quarterly, test that a SIM-change alert reaches IT, and review identity provider settings to verify privileged accounts no longer accept SMS or voice codes.\n\n## Official references\n\n[Federal Communications Commission — FCC Adopts Rules to Protect Consumers’ Cell Phone Accounts (November 15, 2023)](https://docs.fcc.gov/public/attachments/DOC-398483A1.txt). [FCC Wireline Competition Bureau — Order DA 24-649 on the SIM Swap and Port-Out Fraud Order](https://docs.fcc.gov/public/attachments/DA-24-649A1.pdf). Reviewed October 18, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-quarantine-reviewer-notification-retention/", "slug": "google-workspace-quarantine-reviewer-notification-retention", "url": "https://update.dsesecurity.com/updates/google-workspace-quarantine-reviewer-notification-retention/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-quarantine-reviewer-notification-retention.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-quarantine-reviewer-notification-retention/" }, "title": "Assign a real review process for Google email quarantine instead of relying on notifications", "summary": "Quarantine reviewers and notification recipients are not necessarily the same people.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:34:00+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 274, "potentially_affected": "This concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.", "dse_recommendation": "DSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly.", "primary_source": { "name": "Google — Email quarantine", "url": "https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-email-quarantine?hl=en", "published_on": null, "authority": "knowledge.workspace.google.com" }, "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": "Quarantine reviewers and notification recipients are not necessarily the same people.
\nGoogle Workspace quarantine holds matched messages for review before delivery. Administrators can create restricted quarantines and assign reviewer groups, but the documented periodic notification feature sends its notices only to super administrators, not to reviewer groups or users with quarantine privileges. Recipients are not notified that a message is quarantined. Unacted-on messages are permanently deleted from quarantine after 30 days. If a custom quarantine is deleted while holding messages, its messages move to the default quarantine; references from rules must be addressed before deleting the quarantine.
\nSource: Google — Email quarantine.
\nThis concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.
\nDSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly. Establish a review cadence and approved evidence handling so missed notification emails do not allow messages to age out unnoticed. Explain to staff how to report a missing message without assuming the recipient will receive a quarantine notice. Before changing or retiring a quarantine, review its referencing rules and outstanding messages. Keep release and rejection decisions attributable, and ensure the review process respects the sensitivity of the held message content.
\nUse a harmless test rule and message to confirm the intended quarantine and reviewer access. Check which identities receive periodic notices and whether the recipient receives none. Review the pending-message age and rule references before retiring the test quarantine, then remove the test settings through the approved process.
\nGoogle — Email quarantine. Reviewed October 15, 2026.
", "content_text": "Quarantine reviewers and notification recipients are not necessarily the same people.\nSource facts\nGoogle Workspace quarantine holds matched messages for review before delivery. Administrators can create restricted quarantines and assign reviewer groups, but the documented periodic notification feature sends its notices only to super administrators, not to reviewer groups or users with quarantine privileges. Recipients are not notified that a message is quarantined. Unacted-on messages are permanently deleted from quarantine after 30 days. If a custom quarantine is deleted while holding messages, its messages move to the default quarantine; references from rules must be addressed before deleting the quarantine.\nSource: Google — Email quarantine.\nApplicability\nThis concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.\nDSE recommendation\nDSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly. Establish a review cadence and approved evidence handling so missed notification emails do not allow messages to age out unnoticed. Explain to staff how to report a missing message without assuming the recipient will receive a quarantine notice. Before changing or retiring a quarantine, review its referencing rules and outstanding messages. Keep release and rejection decisions attributable, and ensure the review process respects the sensitivity of the held message content.\nVerification\nUse a harmless test rule and message to confirm the intended quarantine and reviewer access. Check which identities receive periodic notices and whether the recipient receives none. Review the pending-message age and rule references before retiring the test quarantine, then remove the test settings through the approved process.\nOfficial reference\nGoogle — Email quarantine. Reviewed October 15, 2026.", "content_markdown": "Quarantine reviewers and notification recipients are not necessarily the same people.\n\n## Source facts\n\nGoogle Workspace quarantine holds matched messages for review before delivery. Administrators can create restricted quarantines and assign reviewer groups, but the documented periodic notification feature sends its notices only to super administrators, not to reviewer groups or users with quarantine privileges. Recipients are not notified that a message is quarantined. Unacted-on messages are permanently deleted from quarantine after 30 days. If a custom quarantine is deleted while holding messages, its messages move to the default quarantine; references from rules must be addressed before deleting the quarantine.\n\nSource: [Google — Email quarantine](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-email-quarantine?hl=en).\n\n## Applicability\n\nThis concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.\n\n## DSE recommendation\n\nDSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly. Establish a review cadence and approved evidence handling so missed notification emails do not allow messages to age out unnoticed. Explain to staff how to report a missing message without assuming the recipient will receive a quarantine notice. Before changing or retiring a quarantine, review its referencing rules and outstanding messages. Keep release and rejection decisions attributable, and ensure the review process respects the sensitivity of the held message content.\n\n## Verification\n\nUse a harmless test rule and message to confirm the intended quarantine and reviewer access. Check which identities receive periodic notices and whether the recipient receives none. Review the pending-message age and rule references before retiring the test quarantine, then remove the test settings through the approved process.\n\n## Official reference\n\n[Google — Email quarantine](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-email-quarantine?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-recipient-map-original-delivery-header/", "slug": "google-workspace-recipient-map-original-delivery-header", "url": "https://update.dsesecurity.com/updates/google-workspace-recipient-map-original-delivery-header/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-recipient-map-original-delivery-header.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-recipient-map-original-delivery-header/" }, "title": "Choose whether a Google recipient map redirects or also delivers the original message", "summary": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:33:59+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 277, "potentially_affected": "This applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.", "dse_recommendation": "DSE recommends recording the business purpose and delivery outcome before creating an address map.", "primary_source": { "name": "Google — Recipient address maps", "url": "https://knowledge.workspace.google.com/admin/gmail/advanced/redirect-or-forward-gmail-messages-to-another-user?hl=en", "published_on": null, "authority": "knowledge.workspace.google.com" }, "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": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.
\nGoogle Workspace recipient address maps can redirect incoming mail or forward it to additional recipients. The Also route to original destination option preserves delivery to the original mailbox; without it, a redirect can send the message only to the mapped destination. The rule can cover all incoming messages, including internal mail, or only external incoming messages. An optional X-Gm-Original-To header preserves the original recipient for header-based processing and diagnostics. Google documents this administrator mapping under Gmail Routing, distinct from Default routing and user-managed automatic forwarding.
\nSource: Google — Recipient address maps.
\nThis applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.
\nDSE recommends recording the business purpose and delivery outcome before creating an address map. For an absence, decide whether both mailboxes should receive new messages; for a replacement workflow, confirm who owns the destination and how long the map should remain. Review internal and external message scope separately. Preserve original-recipient information when approved downstream processing needs it. Check existing mappings for loops or duplicate delivery paths and assign a removal or review date so temporary forwarding does not become an unowned data-sharing arrangement.
\nSend approved synthetic messages from both internal and external test senders. Confirm delivery at every intended mailbox and inspect the optional original-recipient header where enabled. Verify that no unintended duplicate or redirect loop occurs and distinguish new-message routing from access to historical mailbox data.
\nGoogle — Recipient address maps. Reviewed October 15, 2026.
", "content_text": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.\nSource facts\nGoogle Workspace recipient address maps can redirect incoming mail or forward it to additional recipients. The Also route to original destination option preserves delivery to the original mailbox; without it, a redirect can send the message only to the mapped destination. The rule can cover all incoming messages, including internal mail, or only external incoming messages. An optional X-Gm-Original-To header preserves the original recipient for header-based processing and diagnostics. Google documents this administrator mapping under Gmail Routing, distinct from Default routing and user-managed automatic forwarding.\nSource: Google — Recipient address maps.\nApplicability\nThis applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.\nDSE recommendation\nDSE recommends recording the business purpose and delivery outcome before creating an address map. For an absence, decide whether both mailboxes should receive new messages; for a replacement workflow, confirm who owns the destination and how long the map should remain. Review internal and external message scope separately. Preserve original-recipient information when approved downstream processing needs it. Check existing mappings for loops or duplicate delivery paths and assign a removal or review date so temporary forwarding does not become an unowned data-sharing arrangement.\nVerification\nSend approved synthetic messages from both internal and external test senders. Confirm delivery at every intended mailbox and inspect the optional original-recipient header where enabled. Verify that no unintended duplicate or redirect loop occurs and distinguish new-message routing from access to historical mailbox data.\nOfficial reference\nGoogle — Recipient address maps. Reviewed October 15, 2026.", "content_markdown": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.\n\n## Source facts\n\nGoogle Workspace recipient address maps can redirect incoming mail or forward it to additional recipients. The Also route to original destination option preserves delivery to the original mailbox; without it, a redirect can send the message only to the mapped destination. The rule can cover all incoming messages, including internal mail, or only external incoming messages. An optional X-Gm-Original-To header preserves the original recipient for header-based processing and diagnostics. Google documents this administrator mapping under Gmail Routing, distinct from Default routing and user-managed automatic forwarding.\n\nSource: [Google — Recipient address maps](https://knowledge.workspace.google.com/admin/gmail/advanced/redirect-or-forward-gmail-messages-to-another-user?hl=en).\n\n## Applicability\n\nThis applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.\n\n## DSE recommendation\n\nDSE recommends recording the business purpose and delivery outcome before creating an address map. For an absence, decide whether both mailboxes should receive new messages; for a replacement workflow, confirm who owns the destination and how long the map should remain. Review internal and external message scope separately. Preserve original-recipient information when approved downstream processing needs it. Check existing mappings for loops or duplicate delivery paths and assign a removal or review date so temporary forwarding does not become an unowned data-sharing arrangement.\n\n## Verification\n\nSend approved synthetic messages from both internal and external test senders. Confirm delivery at every intended mailbox and inspect the optional original-recipient header where enabled. Verify that no unintended duplicate or redirect loop occurs and distinguish new-message routing from access to historical mailbox data.\n\n## Official reference\n\n[Google — Recipient address maps](https://knowledge.workspace.google.com/admin/gmail/advanced/redirect-or-forward-gmail-messages-to-another-user?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-role-scope-two-approval-requests/", "slug": "google-workspace-role-scope-two-approval-requests", "url": "https://update.dsesecurity.com/updates/google-workspace-role-scope-two-approval-requests/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-role-scope-two-approval-requests.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-role-scope-two-approval-requests/" }, "title": "Expect two approvals when changing Google Workspace admin-role scope under multi-party review", "summary": "A move between organizational-unit scopes can remain pending until both generated requests are approved.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:33:58+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 268, "potentially_affected": "This concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.", "dse_recommendation": "DSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change.", "primary_source": { "name": "Google — Assign admin roles", "url": "https://knowledge.workspace.google.com/admin/users/assign-specific-admin-roles?hl=en", "published_on": null, "authority": "knowledge.workspace.google.com" }, "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": "A move between organizational-unit scopes can remain pending until both generated requests are approved.
\nGoogle Workspace can require multi-party review for administrator-role assignments. A requesting administrator initiates the change and a super administrator reviews it. The documented role-management controls can cover Admin console changes and API changes through separate settings. Changing an existing role assignment from one organizational-unit scope to another creates two approval requests, and both must be approved for the scope change to take effect. Not every role supports organizational-unit scoping; the assignment interface indicates whether that scope can be edited.
\nSource: Google — Assign admin roles.
\nThis concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.
\nDSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change. Tell reviewers to expect the related pair of requests and assess them as one access change. Review the console and API approval settings separately so automation follows the intended governance. Maintain a pending-request checklist for the helpdesk, and avoid repeated resubmission while an existing request is awaiting its second decision. Recheck the final assignment rather than assuming one approval completed the move.
\nWith a low-impact test role and two test organizational units, observe the requests generated by an approved scope change. Confirm the effective scope before and after both decisions. Check the documented console and API settings and verify that an unsupported role is not mistakenly described as organizational-unit restricted.
\nGoogle — Assign admin roles. Reviewed October 15, 2026.
", "content_text": "A move between organizational-unit scopes can remain pending until both generated requests are approved.\nSource facts\nGoogle Workspace can require multi-party review for administrator-role assignments. A requesting administrator initiates the change and a super administrator reviews it. The documented role-management controls can cover Admin console changes and API changes through separate settings. Changing an existing role assignment from one organizational-unit scope to another creates two approval requests, and both must be approved for the scope change to take effect. Not every role supports organizational-unit scoping; the assignment interface indicates whether that scope can be edited.\nSource: Google — Assign admin roles.\nApplicability\nThis concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.\nDSE recommendation\nDSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change. Tell reviewers to expect the related pair of requests and assess them as one access change. Review the console and API approval settings separately so automation follows the intended governance. Maintain a pending-request checklist for the helpdesk, and avoid repeated resubmission while an existing request is awaiting its second decision. Recheck the final assignment rather than assuming one approval completed the move.\nVerification\nWith a low-impact test role and two test organizational units, observe the requests generated by an approved scope change. Confirm the effective scope before and after both decisions. Check the documented console and API settings and verify that an unsupported role is not mistakenly described as organizational-unit restricted.\nOfficial reference\nGoogle — Assign admin roles. Reviewed October 15, 2026.", "content_markdown": "A move between organizational-unit scopes can remain pending until both generated requests are approved.\n\n## Source facts\n\nGoogle Workspace can require multi-party review for administrator-role assignments. A requesting administrator initiates the change and a super administrator reviews it. The documented role-management controls can cover Admin console changes and API changes through separate settings. Changing an existing role assignment from one organizational-unit scope to another creates two approval requests, and both must be approved for the scope change to take effect. Not every role supports organizational-unit scoping; the assignment interface indicates whether that scope can be edited.\n\nSource: [Google — Assign admin roles](https://knowledge.workspace.google.com/admin/users/assign-specific-admin-roles?hl=en).\n\n## Applicability\n\nThis concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.\n\n## DSE recommendation\n\nDSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change. Tell reviewers to expect the related pair of requests and assess them as one access change. Review the console and API approval settings separately so automation follows the intended governance. Maintain a pending-request checklist for the helpdesk, and avoid repeated resubmission while an existing request is awaiting its second decision. Recheck the final assignment rather than assuming one approval completed the move.\n\n## Verification\n\nWith a low-impact test role and two test organizational units, observe the requests generated by an approved scope change. Confirm the effective scope before and after both decisions. Check the documented console and API settings and verify that an unsupported role is not mistakenly described as organizational-unit restricted.\n\n## Official reference\n\n[Google — Assign admin roles](https://knowledge.workspace.google.com/admin/users/assign-specific-admin-roles?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-2sv-enforcement-date-grace-window/", "slug": "google-workspace-2sv-enforcement-date-grace-window", "url": "https://update.dsesecurity.com/updates/google-workspace-2sv-enforcement-date-grace-window/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-2sv-enforcement-date-grace-window.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-2sv-enforcement-date-grace-window/" }, "title": "Plan Google Workspace 2SV enforcement around enrollment grace and scheduling behavior", "summary": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:33:56+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 266, "potentially_affected": "This concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.", "dse_recommendation": "DSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline.", "primary_source": { "name": "Google — Deploy 2-Step Verification", "url": "https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification?hl=en", "published_on": null, "authority": "knowledge.workspace.google.com" }, "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": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.
\nGoogle’s 2-Step Verification deployment guide separates allowing enrollment from enforcing it. Administrators can enforce immediately or select a future date; the scheduled-date option can begin within 24–48 hours rather than at an exact chosen time. A configured new-user enrollment period permits password-only sign-in during that period. Google recommends checking enrollment before enforcement, and changing allowed methods can lock out users who have not prepared another eligible method. Enrollment reports and individual security settings provide different ways to review readiness.
\nSource: Google — Deploy 2-Step Verification.
\nThis concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.
\nDSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline. Use a pilot group to check onboarding and recovery procedures. If the business needs a precise cutover, account for the documented difference between immediate enforcement and the date-based option. Resolve users relying on a soon-disallowed method before changing it. Treat new-user grace as a deliberate access exception with an owner, and provide helpdesk guidance for distinguishing incomplete enrollment from an actual authentication failure.
\nUse test users with complete enrollment, incomplete enrollment, and the intended new-user grace status. Verify behavior for each allowed method before expanding enforcement. Review both report data and current individual settings where needed, and document activation timing instead of inferring it from the selected calendar date.
\nGoogle — Deploy 2-Step Verification. Reviewed October 15, 2026.
", "content_text": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.\nSource facts\nGoogle’s 2-Step Verification deployment guide separates allowing enrollment from enforcing it. Administrators can enforce immediately or select a future date; the scheduled-date option can begin within 24–48 hours rather than at an exact chosen time. A configured new-user enrollment period permits password-only sign-in during that period. Google recommends checking enrollment before enforcement, and changing allowed methods can lock out users who have not prepared another eligible method. Enrollment reports and individual security settings provide different ways to review readiness.\nSource: Google — Deploy 2-Step Verification.\nApplicability\nThis concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.\nDSE recommendation\nDSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline. Use a pilot group to check onboarding and recovery procedures. If the business needs a precise cutover, account for the documented difference between immediate enforcement and the date-based option. Resolve users relying on a soon-disallowed method before changing it. Treat new-user grace as a deliberate access exception with an owner, and provide helpdesk guidance for distinguishing incomplete enrollment from an actual authentication failure.\nVerification\nUse test users with complete enrollment, incomplete enrollment, and the intended new-user grace status. Verify behavior for each allowed method before expanding enforcement. Review both report data and current individual settings where needed, and document activation timing instead of inferring it from the selected calendar date.\nOfficial reference\nGoogle — Deploy 2-Step Verification. Reviewed October 15, 2026.", "content_markdown": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.\n\n## Source facts\n\nGoogle’s 2-Step Verification deployment guide separates allowing enrollment from enforcing it. Administrators can enforce immediately or select a future date; the scheduled-date option can begin within 24–48 hours rather than at an exact chosen time. A configured new-user enrollment period permits password-only sign-in during that period. Google recommends checking enrollment before enforcement, and changing allowed methods can lock out users who have not prepared another eligible method. Enrollment reports and individual security settings provide different ways to review readiness.\n\nSource: [Google — Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification?hl=en).\n\n## Applicability\n\nThis concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.\n\n## DSE recommendation\n\nDSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline. Use a pilot group to check onboarding and recovery procedures. If the business needs a precise cutover, account for the documented difference between immediate enforcement and the date-based option. Resolve users relying on a soon-disallowed method before changing it. Treat new-user grace as a deliberate access exception with an owner, and provide helpdesk guidance for distinguishing incomplete enrollment from an actual authentication failure.\n\n## Verification\n\nUse test users with complete enrollment, incomplete enrollment, and the intended new-user grace status. Verify behavior for each allowed method before expanding enforcement. Review both report data and current individual settings where needed, and document activation timing instead of inferring it from the selected calendar date.\n\n## Official reference\n\n[Google — Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-web-session-exclusions-idp-renewal/", "slug": "google-workspace-web-session-exclusions-idp-renewal", "url": "https://update.dsesecurity.com/updates/google-workspace-web-session-exclusions-idp-renewal/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-web-session-exclusions-idp-renewal.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-web-session-exclusions-idp-renewal/" }, "title": "Account for Google web-session exclusions and the upstream IdP session", "summary": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:33:55+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 270, "potentially_affected": "This applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.", "dse_recommendation": "DSE recommends describing the desired reauthentication outcome for each client class.", "primary_source": { "name": "Google — Session length", "url": "https://knowledge.workspace.google.com/admin/security/set-session-length-for-google-services?hl=en", "published_on": null, "authority": "knowledge.workspace.google.com" }, "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": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.
\nGoogle Workspace web-session settings do not cover every client. Google documents exclusions for OAuth-authenticated applications, native mobile apps, and ChromeOS, with separate ChromeOS controls. A changed duration takes effect after users sign out and sign back in; existing sessions keep their prior duration until then. With a third-party identity provider, a still-valid IdP session can renew Google authentication without another interactive sign-in. The Google Admin console has its own fixed one-hour session, separate from the configurable sessions for other Google services.
\nSource: Google — Session length.
\nThis applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.
\nDSE recommends describing the desired reauthentication outcome for each client class. Inventory browser sessions, native mobile apps, and integrations rather than treating them as one population. Coordinate the Google and IdP lifetimes with the identity owner, and plan how existing users will receive the new setting. If an immediate transition is required, review the documented sign-in-cookie reset process and its user impact. Keep the Admin console’s fixed behavior separate in support guidance so its prompt is not mistaken for a failed organization-wide policy.
\nUse controlled test accounts to compare a newly signed-in web session, an existing session, and a native client. Repeat through the third-party IdP if used. Record the actual prompt and relevant session state, and confirm the policy outcome without assuming every client follows the web-browser rule.
\nGoogle — Session length. Reviewed October 15, 2026.
", "content_text": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.\nSource facts\nGoogle Workspace web-session settings do not cover every client. Google documents exclusions for OAuth-authenticated applications, native mobile apps, and ChromeOS, with separate ChromeOS controls. A changed duration takes effect after users sign out and sign back in; existing sessions keep their prior duration until then. With a third-party identity provider, a still-valid IdP session can renew Google authentication without another interactive sign-in. The Google Admin console has its own fixed one-hour session, separate from the configurable sessions for other Google services.\nSource: Google — Session length.\nApplicability\nThis applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.\nDSE recommendation\nDSE recommends describing the desired reauthentication outcome for each client class. Inventory browser sessions, native mobile apps, and integrations rather than treating them as one population. Coordinate the Google and IdP lifetimes with the identity owner, and plan how existing users will receive the new setting. If an immediate transition is required, review the documented sign-in-cookie reset process and its user impact. Keep the Admin console’s fixed behavior separate in support guidance so its prompt is not mistaken for a failed organization-wide policy.\nVerification\nUse controlled test accounts to compare a newly signed-in web session, an existing session, and a native client. Repeat through the third-party IdP if used. Record the actual prompt and relevant session state, and confirm the policy outcome without assuming every client follows the web-browser rule.\nOfficial reference\nGoogle — Session length. Reviewed October 15, 2026.", "content_markdown": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.\n\n## Source facts\n\nGoogle Workspace web-session settings do not cover every client. Google documents exclusions for OAuth-authenticated applications, native mobile apps, and ChromeOS, with separate ChromeOS controls. A changed duration takes effect after users sign out and sign back in; existing sessions keep their prior duration until then. With a third-party identity provider, a still-valid IdP session can renew Google authentication without another interactive sign-in. The Google Admin console has its own fixed one-hour session, separate from the configurable sessions for other Google services.\n\nSource: [Google — Session length](https://knowledge.workspace.google.com/admin/security/set-session-length-for-google-services?hl=en).\n\n## Applicability\n\nThis applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.\n\n## DSE recommendation\n\nDSE recommends describing the desired reauthentication outcome for each client class. Inventory browser sessions, native mobile apps, and integrations rather than treating them as one population. Coordinate the Google and IdP lifetimes with the identity owner, and plan how existing users will receive the new setting. If an immediate transition is required, review the documented sign-in-cookie reset process and its user impact. Keep the Admin console’s fixed behavior separate in support guidance so its prompt is not mistaken for a failed organization-wide policy.\n\n## Verification\n\nUse controlled test accounts to compare a newly signed-in web session, an existing session, and a native client. Repeat through the third-party IdP if used. Record the actual prompt and relevant session state, and confirm the policy outcome without assuming every client follows the web-browser rule.\n\n## Official reference\n\n[Google — Session length](https://knowledge.workspace.google.com/admin/security/set-session-length-for-google-services?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-oauth-specific-data-versus-trusted/", "slug": "google-workspace-oauth-specific-data-versus-trusted", "url": "https://update.dsesecurity.com/updates/google-workspace-oauth-specific-data-versus-trusted/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-oauth-specific-data-versus-trusted.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-oauth-specific-data-versus-trusted/" }, "title": "Choose scope-specific Google Workspace app access before marking an integration Trusted", "summary": "An application that needs one service does not automatically need permission to request every Workspace scope.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:33:54+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 272, "potentially_affected": "This applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.", "dse_recommendation": "DSE recommends identifying the exact OAuth client before approving an integration.", "primary_source": { "name": "Google — App access controls", "url": "https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=en", "published_on": null, "authority": "knowledge.workspace.google.com" }, "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": "An application that needs one service does not automatically need permission to request every Workspace scope.
\nGoogle Workspace API controls distinguish Trusted, Specific Google data, Limited, and Blocked application access. Trusted allows access across Workspace services, including restricted ones. Specific Google data limits an app to the scopes configured by the administrator, while Limited allows only unrestricted services. The Admin console exposes the OAuth client ID and requested scopes for review. Google warns that the scope list shown during configuration can include everything an app has ever requested; the app’s details view shows the exact scopes currently configured.
\nSource: Google — App access controls.
\nThis applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.
\nDSE recommends identifying the exact OAuth client before approving an integration. Obtain the vendor’s required scope list and map each permission to the business task it enables. Prefer a scope-specific decision where it satisfies the approved requirement, and preserve necessary sign-in scopes. Review inherited organizational-unit settings and any explicit exceptions before expanding access. Record the approver, client ID, intended user population, and review date. Recheck scopes after integration changes instead of assuming the original app name represents an unchanged permission request.
\nUse a test user in the intended organizational unit to complete the approved integration workflow. Confirm the configured client and scopes in the details view, then test that an unapproved data operation remains unavailable. Record results without exporting user tokens or live data from unrelated services.
\nGoogle — App access controls. Reviewed October 15, 2026.
", "content_text": "An application that needs one service does not automatically need permission to request every Workspace scope.\nSource facts\nGoogle Workspace API controls distinguish Trusted, Specific Google data, Limited, and Blocked application access. Trusted allows access across Workspace services, including restricted ones. Specific Google data limits an app to the scopes configured by the administrator, while Limited allows only unrestricted services. The Admin console exposes the OAuth client ID and requested scopes for review. Google warns that the scope list shown during configuration can include everything an app has ever requested; the app’s details view shows the exact scopes currently configured.\nSource: Google — App access controls.\nApplicability\nThis applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.\nDSE recommendation\nDSE recommends identifying the exact OAuth client before approving an integration. Obtain the vendor’s required scope list and map each permission to the business task it enables. Prefer a scope-specific decision where it satisfies the approved requirement, and preserve necessary sign-in scopes. Review inherited organizational-unit settings and any explicit exceptions before expanding access. Record the approver, client ID, intended user population, and review date. Recheck scopes after integration changes instead of assuming the original app name represents an unchanged permission request.\nVerification\nUse a test user in the intended organizational unit to complete the approved integration workflow. Confirm the configured client and scopes in the details view, then test that an unapproved data operation remains unavailable. Record results without exporting user tokens or live data from unrelated services.\nOfficial reference\nGoogle — App access controls. Reviewed October 15, 2026.", "content_markdown": "An application that needs one service does not automatically need permission to request every Workspace scope.\n\n## Source facts\n\nGoogle Workspace API controls distinguish Trusted, Specific Google data, Limited, and Blocked application access. Trusted allows access across Workspace services, including restricted ones. Specific Google data limits an app to the scopes configured by the administrator, while Limited allows only unrestricted services. The Admin console exposes the OAuth client ID and requested scopes for review. Google warns that the scope list shown during configuration can include everything an app has ever requested; the app’s details view shows the exact scopes currently configured.\n\nSource: [Google — App access controls](https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=en).\n\n## Applicability\n\nThis applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.\n\n## DSE recommendation\n\nDSE recommends identifying the exact OAuth client before approving an integration. Obtain the vendor’s required scope list and map each permission to the business task it enables. Prefer a scope-specific decision where it satisfies the approved requirement, and preserve necessary sign-in scopes. Review inherited organizational-unit settings and any explicit exceptions before expanding access. Record the approver, client ID, intended user population, and review date. Recheck scopes after integration changes instead of assuming the original app name represents an unchanged permission request.\n\n## Verification\n\nUse a test user in the intended organizational unit to complete the approved integration workflow. Confirm the configured client and scopes in the details view, then test that an unapproved data operation remains unavailable. Record results without exporting user tokens or live data from unrelated services.\n\n## Official reference\n\n[Google — App access controls](https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/cloudflare-access-oidc-required-claim-mapping/", "slug": "cloudflare-access-oidc-required-claim-mapping", "url": "https://update.dsesecurity.com/updates/cloudflare-access-oidc-required-claim-mapping/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/cloudflare-access-oidc-required-claim-mapping.md", "json": "https://update.dsesecurity.com/api/v1/posts/cloudflare-access-oidc-required-claim-mapping/" }, "title": "Review required OIDC claims before connecting a SaaS application through Cloudflare Access", "summary": "A missing required claim can block authentication even after the user signs in successfully.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:33:30+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 266, "potentially_affected": "This concerns Cloudflare Access acting as an OIDC provider for a SaaS application. The SaaS vendor determines which claims and identifiers it requires and how it assigns permissions.", "dse_recommendation": "DSE recommends getting the SaaS vendor’s exact claim contract before enabling production sign-in.", "primary_source": { "name": "Cloudflare — Generic OIDC SaaS", "url": "https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/saas-apps/generic-oidc-saas/", "published_on": null, "authority": "developers.cloudflare.com" }, "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": "A missing required claim can block authentication even after the user signs in successfully.
\nCloudflare’s generic OIDC SaaS integration sends selected identity scopes and claims to the application. Administrators can remove an unnecessary groups scope, filter the groups passed onward, and map an identity-provider attribute to a named OIDC claim. If a mapped claim is marked required and the identity provider does not provide it, Cloudflare fails the authentication request. Where multiple identity providers are enabled, per-provider claim mappings can override the parent mapping. The application’s callback URL and Access policy are separate required integration settings.
\nSource: Cloudflare — Generic OIDC SaaS.
\nThis concerns Cloudflare Access acting as an OIDC provider for a SaaS application. The SaaS vendor determines which claims and identifiers it requires and how it assigns permissions.
\nDSE recommends getting the SaaS vendor’s exact claim contract before enabling production sign-in. Record claim name, source attribute, expected format, and whether absence should block entry. Review each allowed identity provider, especially where group names or employee identifiers differ. Share only attributes the application needs. Keep an approved recovery account or procedure available during the cutover, and document callback URLs independently of launcher URLs so a user-facing shortcut is not mistaken for the protocol endpoint.
\nUse test identities with complete claims, a missing required attribute, and the permitted alternative identity provider. Confirm the expected rejection and successful mapping without exposing full tokens in tickets. Review application-side account matching and authorization as well as successful completion of the Access login screen.
\nCloudflare — Generic OIDC SaaS. Reviewed October 15, 2026.
", "content_text": "A missing required claim can block authentication even after the user signs in successfully.\nSource facts\nCloudflare’s generic OIDC SaaS integration sends selected identity scopes and claims to the application. Administrators can remove an unnecessary groups scope, filter the groups passed onward, and map an identity-provider attribute to a named OIDC claim. If a mapped claim is marked required and the identity provider does not provide it, Cloudflare fails the authentication request. Where multiple identity providers are enabled, per-provider claim mappings can override the parent mapping. The application’s callback URL and Access policy are separate required integration settings.\nSource: Cloudflare — Generic OIDC SaaS.\nApplicability\nThis concerns Cloudflare Access acting as an OIDC provider for a SaaS application. The SaaS vendor determines which claims and identifiers it requires and how it assigns permissions.\nDSE recommendation\nDSE recommends getting the SaaS vendor’s exact claim contract before enabling production sign-in. Record claim name, source attribute, expected format, and whether absence should block entry. Review each allowed identity provider, especially where group names or employee identifiers differ. Share only attributes the application needs. Keep an approved recovery account or procedure available during the cutover, and document callback URLs independently of launcher URLs so a user-facing shortcut is not mistaken for the protocol endpoint.\nVerification\nUse test identities with complete claims, a missing required attribute, and the permitted alternative identity provider. Confirm the expected rejection and successful mapping without exposing full tokens in tickets. Review application-side account matching and authorization as well as successful completion of the Access login screen.\nOfficial reference\nCloudflare — Generic OIDC SaaS. Reviewed October 15, 2026.", "content_markdown": "A missing required claim can block authentication even after the user signs in successfully.\n\n## Source facts\n\nCloudflare’s generic OIDC SaaS integration sends selected identity scopes and claims to the application. Administrators can remove an unnecessary groups scope, filter the groups passed onward, and map an identity-provider attribute to a named OIDC claim. If a mapped claim is marked required and the identity provider does not provide it, Cloudflare fails the authentication request. Where multiple identity providers are enabled, per-provider claim mappings can override the parent mapping. The application’s callback URL and Access policy are separate required integration settings.\n\nSource: [Cloudflare — Generic OIDC SaaS](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/saas-apps/generic-oidc-saas/).\n\n## Applicability\n\nThis concerns Cloudflare Access acting as an OIDC provider for a SaaS application. The SaaS vendor determines which claims and identifiers it requires and how it assigns permissions.\n\n## DSE recommendation\n\nDSE recommends getting the SaaS vendor’s exact claim contract before enabling production sign-in. Record claim name, source attribute, expected format, and whether absence should block entry. Review each allowed identity provider, especially where group names or employee identifiers differ. Share only attributes the application needs. Keep an approved recovery account or procedure available during the cutover, and document callback URLs independently of launcher URLs so a user-facing shortcut is not mistaken for the protocol endpoint.\n\n## Verification\n\nUse test identities with complete claims, a missing required attribute, and the permitted alternative identity provider. Confirm the expected rejection and successful mapping without exposing full tokens in tickets. Review application-side account matching and authorization as well as successful completion of the Access login screen.\n\n## Official reference\n\n[Cloudflare — Generic OIDC SaaS](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/saas-apps/generic-oidc-saas/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/cloudflare-access-session-precedence-reauthentication/", "slug": "cloudflare-access-session-precedence-reauthentication", "url": "https://update.dsesecurity.com/updates/cloudflare-access-session-precedence-reauthentication/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/cloudflare-access-session-precedence-reauthentication.md", "json": "https://update.dsesecurity.com/api/v1/posts/cloudflare-access-session-precedence-reauthentication/" }, "title": "Match Cloudflare Access session settings to the authentication prompt you expect", "summary": "A short application token does not always mean another identity-provider login.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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-10-15T13:33:21+00:00", "modified_at": "2026-10-15T13:36:16+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 262, "potentially_affected": "This concerns Cloudflare Access session behavior, especially self-hosted browser applications and SaaS sign-in. Infrastructure applications and active remote sessions have additional documented behavior that must be reviewed separately.", "dse_recommendation": "DSE recommends writing the desired outcome in user terms before adjusting a timeout: another policy evaluation, another IdP login, or termination of an application session.", "primary_source": { "name": "Cloudflare — Session management", "url": "https://developers.cloudflare.com/cloudflare-one/access-controls/access-settings/session-management/", "published_on": null, "authority": "developers.cloudflare.com" }, "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": "A short application token does not always mean another identity-provider login.
\nCloudflare Access distinguishes global identity sessions from application tokens. An application token can be renewed without another identity-provider login while the global session remains valid and the stored identity still passes policy. A policy-specific duration overrides the application default. When authentication through a Cloudflare One Client session is enabled, that client session takes precedence over application, policy, and global durations. SaaS applications issue their own session cookies, so Access application durations govern their authentication front door rather than every minute spent inside the SaaS application.
\nSource: Cloudflare — Session management.
\nThis concerns Cloudflare Access session behavior, especially self-hosted browser applications and SaaS sign-in. Infrastructure applications and active remote sessions have additional documented behavior that must be reviewed separately.
\nDSE recommends writing the desired outcome in user terms before adjusting a timeout: another policy evaluation, another IdP login, or termination of an application session. Inventory which authentication path each application actually uses. Record client-session authentication, matching policy durations, application defaults, and IdP session settings together. For SaaS, review the application’s own session controls with its owner. Avoid treating a successful sign-in test immediately after a policy edit as proof that an existing session will end at the expected time.
\nUse a controlled test account to observe a fresh sign-in, application-token renewal, and expiry of the relevant identity session. Repeat with client-session authentication if enabled. Record which prompt appeared and why, without copying live bearer tokens into the test record.
\nCloudflare — Session management. Reviewed October 15, 2026.
", "content_text": "A short application token does not always mean another identity-provider login.\nSource facts\nCloudflare Access distinguishes global identity sessions from application tokens. An application token can be renewed without another identity-provider login while the global session remains valid and the stored identity still passes policy. A policy-specific duration overrides the application default. When authentication through a Cloudflare One Client session is enabled, that client session takes precedence over application, policy, and global durations. SaaS applications issue their own session cookies, so Access application durations govern their authentication front door rather than every minute spent inside the SaaS application.\nSource: Cloudflare — Session management.\nApplicability\nThis concerns Cloudflare Access session behavior, especially self-hosted browser applications and SaaS sign-in. Infrastructure applications and active remote sessions have additional documented behavior that must be reviewed separately.\nDSE recommendation\nDSE recommends writing the desired outcome in user terms before adjusting a timeout: another policy evaluation, another IdP login, or termination of an application session. Inventory which authentication path each application actually uses. Record client-session authentication, matching policy durations, application defaults, and IdP session settings together. For SaaS, review the application’s own session controls with its owner. Avoid treating a successful sign-in test immediately after a policy edit as proof that an existing session will end at the expected time.\nVerification\nUse a controlled test account to observe a fresh sign-in, application-token renewal, and expiry of the relevant identity session. Repeat with client-session authentication if enabled. Record which prompt appeared and why, without copying live bearer tokens into the test record.\nOfficial reference\nCloudflare — Session management. Reviewed October 15, 2026.", "content_markdown": "A short application token does not always mean another identity-provider login.\n\n## Source facts\n\nCloudflare Access distinguishes global identity sessions from application tokens. An application token can be renewed without another identity-provider login while the global session remains valid and the stored identity still passes policy. A policy-specific duration overrides the application default. When authentication through a Cloudflare One Client session is enabled, that client session takes precedence over application, policy, and global durations. SaaS applications issue their own session cookies, so Access application durations govern their authentication front door rather than every minute spent inside the SaaS application.\n\nSource: [Cloudflare — Session management](https://developers.cloudflare.com/cloudflare-one/access-controls/access-settings/session-management/).\n\n## Applicability\n\nThis concerns Cloudflare Access session behavior, especially self-hosted browser applications and SaaS sign-in. Infrastructure applications and active remote sessions have additional documented behavior that must be reviewed separately.\n\n## DSE recommendation\n\nDSE recommends writing the desired outcome in user terms before adjusting a timeout: another policy evaluation, another IdP login, or termination of an application session. Inventory which authentication path each application actually uses. Record client-session authentication, matching policy durations, application defaults, and IdP session settings together. For SaaS, review the application’s own session controls with its owner. Avoid treating a successful sign-in test immediately after a policy edit as proof that an existing session will end at the expected time.\n\n## Verification\n\nUse a controlled test account to observe a fresh sign-in, application-token renewal, and expiry of the relevant identity session. Repeat with client-session authentication if enabled. Record which prompt appeared and why, without copying live bearer tokens into the test record.\n\n## Official reference\n\n[Cloudflare — Session management](https://developers.cloudflare.com/cloudflare-one/access-controls/access-settings/session-management/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-195-resolve-a-duplicate-ios-mail-profile-before-expecting-intune-to-replace-it/", "slug": "dse-20260909-195-resolve-a-duplicate-ios-mail-profile-before-expecting-intune-to-replace-it", "url": "https://update.dsesecurity.com/updates/dse-20260909-195-resolve-a-duplicate-ios-mail-profile-before-expecting-intune-to-replace-it/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-195-resolve-a-duplicate-ios-mail-profile-before-expecting-intune-to-replace-it.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-195-resolve-a-duplicate-ios-mail-profile-before-expecting-intune-to-replace-it/" }, "title": "Resolve a duplicate iOS mail profile before expecting Intune to replace it", "summary": "Why can an existing iOS email profile prevent an Intune email configuration from arriving?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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:28:41+00:00", "modified_at": "2026-09-10T00:55:36+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 248, "potentially_affected": "Use this check for Intune email-profile assignment to iOS or iPadOS devices with an existing mail configuration. Treat this as a profile-collision investigation, not as a diagnosis of every mail-client, authentication or message-delivery failure.", "dse_recommendation": "Inspect the existing profile before retrying deployment or changing authentication policy.", "primary_source": { "name": "Configure email settings in Microsoft Intune - Microsoft Intune | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/intune/device-configuration/templates/configure-email", "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": "On iOS and iPadOS, Intune identifies a duplicate email profile by its host name and email address. Microsoft says that duplicate blocks assignment of the Intune profile. Company Portal reports the resulting noncompliance and asks the user to remove the existing configuration manually. Microsoft recommends enrolling before installing an email profile to help avoid this collision. Microsoft Learn.
\nUse this check for Intune email-profile assignment to iOS or iPadOS devices with an existing mail configuration. Treat this as a profile-collision investigation, not as a diagnosis of every mail-client, authentication or message-delivery failure.
\nInspect the existing profile before retrying deployment or changing authentication policy. Compare its host name and email identity with the managed configuration that should arrive. Have the support owner confirm which account and profile are involved and agree the supported removal and reconfiguration sequence with the user. Review any preservation requirements before removing a working mail configuration. For new-device instructions, put enrollment before the separate email-profile setup rather than asking users to create both independently.
\nOn an authorized test device, capture the relevant Company Portal notice and the matching profile identities. After the approved collision-resolution step, verify that the intended managed configuration arrives and that the user can complete the required mail workflow. Record a remaining assignment error separately from a later sign-in or mail-flow problem. Do not erase unrelated accounts or the whole device to test this narrow hypothesis.
\nMicrosoft Learn: Configure email settings in Microsoft Intune.
", "content_text": "Source facts\nOn iOS and iPadOS, Intune identifies a duplicate email profile by its host name and email address. Microsoft says that duplicate blocks assignment of the Intune profile. Company Portal reports the resulting noncompliance and asks the user to remove the existing configuration manually. Microsoft recommends enrolling before installing an email profile to help avoid this collision. Microsoft Learn.\nApplicability\nUse this check for Intune email-profile assignment to iOS or iPadOS devices with an existing mail configuration. Treat this as a profile-collision investigation, not as a diagnosis of every mail-client, authentication or message-delivery failure.\nDSE recommendation\nInspect the existing profile before retrying deployment or changing authentication policy. Compare its host name and email identity with the managed configuration that should arrive. Have the support owner confirm which account and profile are involved and agree the supported removal and reconfiguration sequence with the user. Review any preservation requirements before removing a working mail configuration. For new-device instructions, put enrollment before the separate email-profile setup rather than asking users to create both independently.\nVerification\nOn an authorized test device, capture the relevant Company Portal notice and the matching profile identities. After the approved collision-resolution step, verify that the intended managed configuration arrives and that the user can complete the required mail workflow. Record a remaining assignment error separately from a later sign-in or mail-flow problem. Do not erase unrelated accounts or the whole device to test this narrow hypothesis.\nOfficial references\nMicrosoft Learn: Configure email settings in Microsoft Intune.", "content_markdown": "## Source facts\n\nOn iOS and iPadOS, Intune identifies a duplicate email profile by its host name and email address. Microsoft says that duplicate blocks assignment of the Intune profile. Company Portal reports the resulting noncompliance and asks the user to remove the existing configuration manually. Microsoft recommends enrolling before installing an email profile to help avoid this collision. [Microsoft Learn](https://learn.microsoft.com/en-us/intune/device-configuration/templates/configure-email).\n\n## Applicability\n\nUse this check for Intune email-profile assignment to iOS or iPadOS devices with an existing mail configuration. Treat this as a profile-collision investigation, not as a diagnosis of every mail-client, authentication or message-delivery failure.\n\n## DSE recommendation\n\nInspect the existing profile before retrying deployment or changing authentication policy. Compare its host name and email identity with the managed configuration that should arrive. Have the support owner confirm which account and profile are involved and agree the supported removal and reconfiguration sequence with the user. Review any preservation requirements before removing a working mail configuration. For new-device instructions, put enrollment before the separate email-profile setup rather than asking users to create both independently.\n\n## Verification\n\nOn an authorized test device, capture the relevant Company Portal notice and the matching profile identities. After the approved collision-resolution step, verify that the intended managed configuration arrives and that the user can complete the required mail workflow. Record a remaining assignment error separately from a later sign-in or mail-flow problem. Do not erase unrelated accounts or the whole device to test this narrow hypothesis.\n\n## Official references\n\n[Microsoft Learn: Configure email settings in Microsoft Intune](https://learn.microsoft.com/en-us/intune/device-configuration/templates/configure-email)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-556-separate-elastic-san-private-endpoint-creation-authority-from-connection-approval/", "slug": "dse-20260909-556-separate-elastic-san-private-endpoint-creation-authority-from-connection-approval", "url": "https://update.dsesecurity.com/updates/dse-20260909-556-separate-elastic-san-private-endpoint-creation-authority-from-connection-approval/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-556-separate-elastic-san-private-endpoint-creation-authority-from-connection-approval.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-556-separate-elastic-san-private-endpoint-creation-authority-from-connection-approval/" }, "title": "Separate Elastic SAN private-endpoint creation authority from connection approval", "summary": "The role used to create the volume-group endpoint and the operation used to approve its connection are distinct checks.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "managed-it", "label": "Managed IT operations", "alt": "A controlled technology lifecycle progressing from assessment to approved production.", "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "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:22:40+00:00", "modified_at": "2026-09-10T02:14:30+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 230, "potentially_affected": "Elastic SAN private-endpoint provisioning and approval workflows, including cross-subscription deployments.", "dse_recommendation": "Identify the endpoint creator and connection approver before starting the workflow.", "primary_source": { "name": "Configure private endpoints for Azure Elastic SAN | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-private-endpoints", "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": "Microsoft requires the Elastic SAN Volume Group Owner role to create the volume-group private endpoint. Approving a new connection requires Microsoft.ElasticSan/elasticSans/PrivateEndpointConnectionsApproval/action. Elastic SAN Network Admin includes that operation, and a custom role can also grant it.
\nIf the SAN and private endpoint are in different subscriptions, Microsoft.ElasticSan must be registered in the subscription containing the endpoint. Microsoft Learn.
\nRecord the SAN, volume group, endpoint subscription and each participating identity. Review the actual role permissions and scopes instead of treating a successful creation step as evidence that the approval step is authorized.
\nDSE recommends assigning responsibility for creation and approval explicitly in the network change record. Use the documented operation and scope to diagnose a pending or denied approval before requesting a broader administrative role. Coordinate cross-subscription provider registration with its owner. Keep the approval decision tied to the intended endpoint and network, not merely to a recognizable requester name.
\nInspect the endpoint’s target resource and connection state, then have the authorized approver review the precise request. After approval, test the intended connection independently; a permitted approval operation is not itself a connectivity test. Retain creator and approver evidence with resource identifiers and confirm that any temporary grants are handled through the organization’s approved access lifecycle.
\nMicrosoft Learn: Configure private endpoints for Azure Elastic SAN. Source retrieved September 9, 2026.
", "content_text": "Source facts\nMicrosoft requires the Elastic SAN Volume Group Owner role to create the volume-group private endpoint. Approving a new connection requires Microsoft.ElasticSan/elasticSans/PrivateEndpointConnectionsApproval/action. Elastic SAN Network Admin includes that operation, and a custom role can also grant it.\nIf the SAN and private endpoint are in different subscriptions, Microsoft.ElasticSan must be registered in the subscription containing the endpoint. Microsoft Learn.\nApplicability\nRecord the SAN, volume group, endpoint subscription and each participating identity. Review the actual role permissions and scopes instead of treating a successful creation step as evidence that the approval step is authorized.\nDSE recommendation\nDSE recommends assigning responsibility for creation and approval explicitly in the network change record. Use the documented operation and scope to diagnose a pending or denied approval before requesting a broader administrative role. Coordinate cross-subscription provider registration with its owner. Keep the approval decision tied to the intended endpoint and network, not merely to a recognizable requester name.\nVerification\nInspect the endpoint’s target resource and connection state, then have the authorized approver review the precise request. After approval, test the intended connection independently; a permitted approval operation is not itself a connectivity test. Retain creator and approver evidence with resource identifiers and confirm that any temporary grants are handled through the organization’s approved access lifecycle.\nOfficial references\nMicrosoft Learn: Configure private endpoints for Azure Elastic SAN. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft requires the Elastic SAN Volume Group Owner role to create the volume-group private endpoint. Approving a new connection requires Microsoft.ElasticSan/elasticSans/PrivateEndpointConnectionsApproval/action. Elastic SAN Network Admin includes that operation, and a custom role can also grant it.\n\nIf the SAN and private endpoint are in different subscriptions, Microsoft.ElasticSan must be registered in the subscription containing the endpoint. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-private-endpoints).\n\n## Applicability\n\nRecord the SAN, volume group, endpoint subscription and each participating identity. Review the actual role permissions and scopes instead of treating a successful creation step as evidence that the approval step is authorized.\n\n## DSE recommendation\n\nDSE recommends assigning responsibility for creation and approval explicitly in the network change record. Use the documented operation and scope to diagnose a pending or denied approval before requesting a broader administrative role. Coordinate cross-subscription provider registration with its owner. Keep the approval decision tied to the intended endpoint and network, not merely to a recognizable requester name.\n\n## Verification\n\nInspect the endpoint’s target resource and connection state, then have the authorized approver review the precise request. After approval, test the intended connection independently; a permitted approval operation is not itself a connectivity test. Retain creator and approver evidence with resource identifiers and confirm that any temporary grants are handled through the organization’s approved access lifecycle.\n\n## Official references\n\n[Microsoft Learn: Configure private endpoints for Azure Elastic SAN](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-private-endpoints). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-578-supply-the-principal-type-when-a-just-created-identity-s-azure-role-assignment/", "slug": "dse-20260909-578-supply-the-principal-type-when-a-just-created-identity-s-azure-role-assignment", "url": "https://update.dsesecurity.com/updates/dse-20260909-578-supply-the-principal-type-when-a-just-created-identity-s-azure-role-assignment/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-578-supply-the-principal-type-when-a-just-created-identity-s-azure-role-assignment.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-578-supply-the-principal-type-when-a-just-created-identity-s-azure-role-assignment/" }, "title": "Supply the principal type when a just-created identity's Azure role assignment races replication", "summary": "A newly created service principal can be unavailable to a role-assignment operation in another region.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-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/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "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:22:18+00:00", "modified_at": "2026-09-10T02:14:31+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 240, "potentially_affected": "Azure CLI automation creating a service principal or managed identity and immediately assigning an Azure role.", "dse_recommendation": "Use the confirmed object ID and ServicePrincipal type for the documented creation-race case without broadening the role.", "primary_source": { "name": "Assign Azure roles using Azure CLI - Azure RBAC | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-cli", "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": "Microsoft documents that role assignment can fail immediately after service-principal creation because replication to another region may not yet have completed. A script that creates a managed identity and then assigns a role can encounter this condition; replication delay is a possible cause, not a diagnosis for every failure.
\nFor this scenario, the documented Azure CLI request supplies –assignee-object-id and sets –assignee-principal-type to ServicePrincipal. The intended role and scope remain separate inputs. Microsoft Learn.
\nConfirm that the failing assignment follows new identity creation and that the object ID belongs to the intended principal. Examine the actual error and caller’s assignment authority before selecting the remedy.
\nDSE recommends making object identity and principal type explicit in the supported automation path. Preserve the least-privileged role and approved scope rather than substituting a broader role to work around a timing problem. If the failure persists, investigate its specific cause instead of repeatedly creating identities or assuming every authorization error is replication lag.
\nIn an approved test, inspect the created identity and resulting assignment using their stable identifiers. Confirm that the assignment references the expected principal, role and scope, then test the intended access separately. Record failures and timing without claiming a fixed replication delay. A successful assignment should not be reported as proof that all resource-specific access prerequisites have been met.
\nMicrosoft Learn: Assign Azure roles using Azure CLI – Azure RBAC. Source retrieved September 9, 2026.
", "content_text": "Source facts\nMicrosoft documents that role assignment can fail immediately after service-principal creation because replication to another region may not yet have completed. A script that creates a managed identity and then assigns a role can encounter this condition; replication delay is a possible cause, not a diagnosis for every failure.\nFor this scenario, the documented Azure CLI request supplies –assignee-object-id and sets –assignee-principal-type to ServicePrincipal. The intended role and scope remain separate inputs. Microsoft Learn.\nApplicability\nConfirm that the failing assignment follows new identity creation and that the object ID belongs to the intended principal. Examine the actual error and caller’s assignment authority before selecting the remedy.\nDSE recommendation\nDSE recommends making object identity and principal type explicit in the supported automation path. Preserve the least-privileged role and approved scope rather than substituting a broader role to work around a timing problem. If the failure persists, investigate its specific cause instead of repeatedly creating identities or assuming every authorization error is replication lag.\nVerification\nIn an approved test, inspect the created identity and resulting assignment using their stable identifiers. Confirm that the assignment references the expected principal, role and scope, then test the intended access separately. Record failures and timing without claiming a fixed replication delay. A successful assignment should not be reported as proof that all resource-specific access prerequisites have been met.\nOfficial references\nMicrosoft Learn: Assign Azure roles using Azure CLI – Azure RBAC. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft documents that role assignment can fail immediately after service-principal creation because replication to another region may not yet have completed. A script that creates a managed identity and then assigns a role can encounter this condition; replication delay is a possible cause, not a diagnosis for every failure.\n\nFor this scenario, the documented Azure CLI request supplies –assignee-object-id and sets –assignee-principal-type to ServicePrincipal. The intended role and scope remain separate inputs. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-cli).\n\n## Applicability\n\nConfirm that the failing assignment follows new identity creation and that the object ID belongs to the intended principal. Examine the actual error and caller’s assignment authority before selecting the remedy.\n\n## DSE recommendation\n\nDSE recommends making object identity and principal type explicit in the supported automation path. Preserve the least-privileged role and approved scope rather than substituting a broader role to work around a timing problem. If the failure persists, investigate its specific cause instead of repeatedly creating identities or assuming every authorization error is replication lag.\n\n## Verification\n\nIn an approved test, inspect the created identity and resulting assignment using their stable identifiers. Confirm that the assignment references the expected principal, role and scope, then test the intended access separately. Record failures and timing without claiming a fixed replication delay. A successful assignment should not be reported as proof that all resource-specific access prerequisites have been met.\n\n## Official references\n\n[Microsoft Learn: Assign Azure roles using Azure CLI – Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-cli). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/scope-monitoring-active-directory-for-signs-of-compromise-in-observed-ad-dns-state/", "slug": "scope-monitoring-active-directory-for-signs-of-compromise-in-observed-ad-dns-state", "url": "https://update.dsesecurity.com/updates/scope-monitoring-active-directory-for-signs-of-compromise-in-observed-ad-dns-state/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/scope-monitoring-active-directory-for-signs-of-compromise-in-observed-ad-dns-state.md", "json": "https://update.dsesecurity.com/api/v1/posts/scope-monitoring-active-directory-for-signs-of-compromise-in-observed-ad-dns-state/" }, "title": "Scope Monitoring Active Directory for Signs of Compromise in observed AD/DNS state", "summary": "Microsoft states: “Law Number Five: Eternal vigilance is the price of security. - 10 Immutable Laws of Security Administration).”", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "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-08-27T17:07:25+00:00", "modified_at": "2026-10-19T11:57:18+00:00", "reviewed_on": "2026-08-27", "reading_minutes": 3, "word_count": 567, "potentially_affected": "Teams, systems, services, or facilities within the stated scope of Monitoring Active Directory for Signs of Compromise", "dse_recommendation": "Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards.", "primary_source": { "name": "Monitoring Active Directory for Signs of Compromise", "url": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/Monitoring-Active-Directory-for-Signs-of-Compromise", "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": "Use this document to resolve one bounded operational decision: Scope Monitoring Active Directory for Signs of Compromise in observed AD/DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting.
\nThe official Monitoring Active Directory for Signs of Compromise from Microsoft supports the following bounded statements:
\nThese statements are the factual basis for this document. Do not extend them into a broader assurance. Review forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles only where the source and recorded environment align.
\nThe cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity are healthy. Documented options are review inputs, not universal mandates.
\nDSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation.
\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.
\nEvidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Introduction below H1; Introduction below H1. Favor directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, linked to stable identifiers, time, and operator.
\nLabel this evidence set DSE-20260827-001 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review.
\nKeep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.
\n