Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.
\r\n\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.
\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.
\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.
\r\n\r\n| Finding | Affected product | Vendor-directed update |
|---|---|---|
| CVE-2026-21655 | C-CURE 9000 3.10.1 and earlier | Upgrade to 3.20 or later |
| CVE-2026-21655 | victor Application Server 4.10 and earlier | Upgrade to 4.20 or later |
| CVE-2026-21655 | victor 7.0 and earlier | Upgrade to 8.0 or later |
| CVE-2026-21653 | victor Web versions before 7.0 | Upgrade to 7.0 or later |
| CVE-2026-34496 | victor Web 7.1 and earlier | Use the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator |
The Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.
\r\n\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.
\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.
\r\n\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.
For CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.
\r\n\r\nThe following steps are DSE recommendations based on the official advisories.
\r\nSoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.Source review completed August 12, 2026. Recheck the official advisories before changing production systems.
\r\n", "content_text": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\r\n\r\nSource fact: what CISA Update A covers\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\r\n\r\nAffected versions and vendor-directed updates\r\n\r\nFindingAffected productVendor-directed update\r\n\r\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\r\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\r\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\r\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\r\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\r\n\r\n\r\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\r\n\r\nWhy “adjacent network” still deserves urgency\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\r\n\r\nVendor-provided temporary mitigations\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\r\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\r\n\r\nDSE recommendation: prioritized response\r\nThe following steps are DSE recommendations based on the official advisories.\r\n\r\nConfirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\r\nContain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\r\nExpedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\r\nProtect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\r\nReview available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\r\nDocument closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\r\n\r\n\r\nOfficial reference\r\n\r\nCISA ICSA-26-204-01 Update A, updated August 11, 2026\r\nJohnson Controls JCI-PSA-2026-13 v2, updated August 6, 2026\r\nJohnson Controls JCI-PSA-2026-07\r\nJohnson Controls JCI-PSA-2026-16\r\nJohnson Controls Product Security Advisory register\r\n\r\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems.", "content_markdown": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\n\n## Source fact: what CISA Update A covers\n\n[CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01) covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\n\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its [product advisory](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2) also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\n\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\n\n## Affected versions and vendor-directed updates\n\nFindingAffected productVendor-directed update\n\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\n\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\n\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\n\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\n\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\n\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\n\n## Why “adjacent network” still deserves urgency\n\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\n\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\n\n## Vendor-provided temporary mitigations\n\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\n\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\n\n## DSE recommendation: prioritized response\n\nThe following steps are DSE recommendations based on the official advisories.\n\n- Confirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\n\n- Contain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\n\n- Expedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\n\n- Protect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\n\n- Review available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\n\n- Document closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\n\n## Official reference\n\n- [CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01), updated August 11, 2026\n\n- [Johnson Controls JCI-PSA-2026-13 v2](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2), updated August 6, 2026\n\n- [Johnson Controls JCI-PSA-2026-07](https://tyco.widen.net/s/n5vdddqbcs/jci-psa-2026-07)\n\n- [Johnson Controls JCI-PSA-2026-16](https://tyco.widen.net/s/s9cchrkg87/jci-psa-2026-16)\n\n- [Johnson Controls Product Security Advisory register](https://www.johnsoncontrols.com/trust-center/cybersecurity/security-advisories)\n\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems." }, { "id": "https://update.dsesecurity.com/updates/welcome-to-dse-updates/", "slug": "welcome-to-dse-updates", "url": "https://update.dsesecurity.com/updates/welcome-to-dse-updates/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/welcome-to-dse-updates.md", "json": "https://update.dsesecurity.com/api/v1/posts/welcome-to-dse-updates/" }, "title": "Welcome to DSE Updates: security guidance without the noise", "summary": "A public, read-only knowledge hub where DSE turns selected, source-backed physical security, IT, and cybersecurity developments into practical guidance.", "format": { "slug": "explainer", "name": "Explainer" }, "priority": { "slug": "info", "name": "Information" }, "featured": true, "image": { "theme": "dse-engineering", "label": "DSE engineering", "alt": "Physical security, networks, and engineered systems converging into one integrated platform.", "card_url": "https://update.dsesecurity.com/assets/editorial/dse-engineering-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/dse-engineering-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/dse-engineering-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "dse-world", "name": "DSE World", "url": "https://update.dsesecurity.com/topic/dse-world/" } ], "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-07-17T09:00:00+00:00", "modified_at": "2026-07-19T19:29:33+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 1, "word_count": 215, "potentially_affected": "DSE customers and Michigan organizations responsible for surveillance, access control, networks, endpoints, cloud services, and cybersecurity operations.", "dse_recommendation": "Bookmark this publication, share it with the people who own your security and technology systems, and contact DSE when an update may affect your environment.", "primary_source": { "name": "DSE Updates editorial methodology", "url": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "published_on": null, "authority": "DSE Security editorial guidance" }, "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": "Security and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.
\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.
\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable.
", "content_text": "What this publication is for\nSecurity and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.\nWhat we cover\n\nVideo surveillance: device firmware, video-management platforms, recording infrastructure, and secure deployment practices.\nAccess control: controllers, readers, credentials, management software, and connected door hardware.\nIT: operating systems, networks, cloud platforms, endpoints, servers, and business applications.\nCybersecurity: exploited vulnerabilities, defensive guidance, identity, hardening, and recovery readiness.\nDSE World: service announcements, new capabilities, and guidance from Detection Systems & Engineering.\n\nOur editorial standard\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.\nA focused, read-only customer experience\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable.", "content_markdown": "## What this publication is for\n\nSecurity and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.\n\n## What we cover\n\n- Video surveillance: device firmware, video-management platforms, recording infrastructure, and secure deployment practices.\n\n- Access control: controllers, readers, credentials, management software, and connected door hardware.\n\n- IT: operating systems, networks, cloud platforms, endpoints, servers, and business applications.\n\n- Cybersecurity: exploited vulnerabilities, defensive guidance, identity, hardening, and recovery readiness.\n\n- DSE World: service announcements, new capabilities, and guidance from Detection Systems & Engineering.\n\n## Our editorial standard\n\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.\n\n## A focused, read-only customer experience\n\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-001-validate-autopilot-registration-csvs-before-assigning-users/", "slug": "dse-20260909-001-validate-autopilot-registration-csvs-before-assigning-users", "url": "https://update.dsesecurity.com/updates/dse-20260909-001-validate-autopilot-registration-csvs-before-assigning-users/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-001-validate-autopilot-registration-csvs-before-assigning-users.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-001-validate-autopilot-registration-csvs-before-assigning-users/" }, "title": "Validate Autopilot registration CSVs before assigning users", "summary": "What must be checked beyond a successful Autopilot CSV upload?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:55+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 1, "word_count": 219, "potentially_affected": "Use this review for an approved limited manual-registration exercise. Identify the devices, intended tenant, account assignments, and person responsible for the import before collecting their hardware hashes.", "dse_recommendation": "Keep the hardware-hash file in a restricted working location.", "primary_source": { "name": "Manually Register Devices with Windows Autopilot | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/autopilot/add-devices", "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 limits its recommendation for 4K hardware-hash registration through Intune to testing or other limited uses. The import checks the assigned user’s domain, not whether the individual UPN identifies the intended existing user. An invalid assignment can make the device inaccessible until that assignment is removed. Microsoft also requires the CSV to be edited as plain text rather than saved with Excel. Microsoft Learn.
\nUse this review for an approved limited manual-registration exercise. Identify the devices, intended tenant, account assignments, and person responsible for the import before collecting their hardware hashes.
\nKeep the hardware-hash file in a restricted working location. Have a second operator compare each proposed user assignment with the authoritative account record and approved device allocation. Review the complete file against the source’s formatting requirements after editing. Begin with a small, explicitly identified set and keep a record of which rows were submitted.
\nInspect the resulting Autopilot entries and compare serial numbers and user assignments with the approved input. Test the intended sign-in on a designated pilot device before releasing the remainder. If an unexpected assignment appears, stop further imports and have the enrollment owner correct that specific record. Preserve sanitized validation results, not hardware hashes in ordinary support tickets.
\nMicrosoft Learn: Manually Register Devices with Windows Autopilot.
", "content_text": "Source facts\nMicrosoft limits its recommendation for 4K hardware-hash registration through Intune to testing or other limited uses. The import checks the assigned user’s domain, not whether the individual UPN identifies the intended existing user. An invalid assignment can make the device inaccessible until that assignment is removed. Microsoft also requires the CSV to be edited as plain text rather than saved with Excel. Microsoft Learn.\nApplicability\nUse this review for an approved limited manual-registration exercise. Identify the devices, intended tenant, account assignments, and person responsible for the import before collecting their hardware hashes.\nDSE recommendation\nKeep the hardware-hash file in a restricted working location. Have a second operator compare each proposed user assignment with the authoritative account record and approved device allocation. Review the complete file against the source’s formatting requirements after editing. Begin with a small, explicitly identified set and keep a record of which rows were submitted.\nVerification\nInspect the resulting Autopilot entries and compare serial numbers and user assignments with the approved input. Test the intended sign-in on a designated pilot device before releasing the remainder. If an unexpected assignment appears, stop further imports and have the enrollment owner correct that specific record. Preserve sanitized validation results, not hardware hashes in ordinary support tickets.\nOfficial references\nMicrosoft Learn: Manually Register Devices with Windows Autopilot.", "content_markdown": "## Source facts\n\nMicrosoft limits its recommendation for 4K hardware-hash registration through Intune to testing or other limited uses. The import checks the assigned user’s domain, not whether the individual UPN identifies the intended existing user. An invalid assignment can make the device inaccessible until that assignment is removed. Microsoft also requires the CSV to be edited as plain text rather than saved with Excel. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/add-devices).\n\n## Applicability\n\nUse this review for an approved limited manual-registration exercise. Identify the devices, intended tenant, account assignments, and person responsible for the import before collecting their hardware hashes.\n\n## DSE recommendation\n\nKeep the hardware-hash file in a restricted working location. Have a second operator compare each proposed user assignment with the authoritative account record and approved device allocation. Review the complete file against the source’s formatting requirements after editing. Begin with a small, explicitly identified set and keep a record of which rows were submitted.\n\n## Verification\n\nInspect the resulting Autopilot entries and compare serial numbers and user assignments with the approved input. Test the intended sign-in on a designated pilot device before releasing the remainder. If an unexpected assignment appears, stop further imports and have the enrollment owner correct that specific record. Preserve sanitized validation results, not hardware hashes in ordinary support tickets.\n\n## Official references\n\n[Microsoft Learn: Manually Register Devices with Windows Autopilot](https://learn.microsoft.com/en-us/autopilot/add-devices)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair/", "slug": "dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair", "url": "https://update.dsesecurity.com/updates/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair/" }, "title": "Plan the Autopilot identity handoff before motherboard repair", "summary": "Who will restore the repaired device’s Autopilot identity before it returns to its user?", "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": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:54+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 233, "potentially_affected": "Use this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.", "dse_recommendation": "Agree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment.", "primary_source": { "name": "Windows Autopilot motherboard replacement | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/autopilot/autopilot-motherboard-replacement", "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 recommends deregistering an Autopilot device before motherboard replacement, then capturing a new hardware hash, registering the repaired device again, and returning it to its out-of-box state. A repaired device registered through Partner Center needs its new 4K hardware hash; a product key identifier or serial/manufacturer/model tuple is insufficient. Microsoft also warns that motherboard-repair scenarios often lose data. Microsoft Learn.
\nUse this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.
\nAgree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment. Protect required user data through the approved recovery process. Record who will handle deregistration, verify the repaired firmware information, capture the replacement identity, and confirm registration. Give the facility the approved operating-system requirement and a clear return-state acceptance record, without supplying user passwords.
\nBefore returning the device to normal use, reconcile the repaired physical unit with the newly registered identity and intended tenant. Check that the unit reaches the expected out-of-box experience rather than an inaccessible previous installation. Perform an authorized enrollment and sign-in test. Hold the return if the tenant, hardware identity, or repair evidence is inconsistent, and route the discrepancy to the responsible registration owner.
\nMicrosoft Learn: Windows Autopilot motherboard replacement.
", "content_text": "Source facts\nMicrosoft recommends deregistering an Autopilot device before motherboard replacement, then capturing a new hardware hash, registering the repaired device again, and returning it to its out-of-box state. A repaired device registered through Partner Center needs its new 4K hardware hash; a product key identifier or serial/manufacturer/model tuple is insufficient. Microsoft also warns that motherboard-repair scenarios often lose data. Microsoft Learn.\nApplicability\nUse this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.\nDSE recommendation\nAgree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment. Protect required user data through the approved recovery process. Record who will handle deregistration, verify the repaired firmware information, capture the replacement identity, and confirm registration. Give the facility the approved operating-system requirement and a clear return-state acceptance record, without supplying user passwords.\nVerification\nBefore returning the device to normal use, reconcile the repaired physical unit with the newly registered identity and intended tenant. Check that the unit reaches the expected out-of-box experience rather than an inaccessible previous installation. Perform an authorized enrollment and sign-in test. Hold the return if the tenant, hardware identity, or repair evidence is inconsistent, and route the discrepancy to the responsible registration owner.\nOfficial references\nMicrosoft Learn: Windows Autopilot motherboard replacement.", "content_markdown": "## Source facts\n\nMicrosoft recommends deregistering an Autopilot device before motherboard replacement, then capturing a new hardware hash, registering the repaired device again, and returning it to its out-of-box state. A repaired device registered through Partner Center needs its new 4K hardware hash; a product key identifier or serial/manufacturer/model tuple is insufficient. Microsoft also warns that motherboard-repair scenarios often lose data. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/autopilot-motherboard-replacement).\n\n## Applicability\n\nUse this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.\n\n## DSE recommendation\n\nAgree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment. Protect required user data through the approved recovery process. Record who will handle deregistration, verify the repaired firmware information, capture the replacement identity, and confirm registration. Give the facility the approved operating-system requirement and a clear return-state acceptance record, without supplying user passwords.\n\n## Verification\n\nBefore returning the device to normal use, reconcile the repaired physical unit with the newly registered identity and intended tenant. Check that the unit reaches the expected out-of-box experience rather than an inaccessible previous installation. Perform an authorized enrollment and sign-in test. Hold the return if the tenant, hardware identity, or repair evidence is inconsistent, and route the discrepancy to the responsible registration owner.\n\n## Official references\n\n[Microsoft Learn: Windows Autopilot motherboard replacement](https://learn.microsoft.com/en-us/autopilot/autopilot-motherboard-replacement)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-003-check-procurement-registration-before-promising-dfci-management/", "slug": "dse-20260909-003-check-procurement-registration-before-promising-dfci-management", "url": "https://update.dsesecurity.com/updates/dse-20260909-003-check-procurement-registration-before-promising-dfci-management/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-003-check-procurement-registration-before-promising-dfci-management.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-003-check-procurement-registration-before-promising-dfci-management/" }, "title": "Check procurement registration before promising DFCI management", "summary": "Does the device’s firmware and registration history make it eligible for DFCI?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:53+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 231, "potentially_affected": "Use this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.", "dse_recommendation": "Ask procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory.", "primary_source": { "name": "DFCI Management | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/autopilot/dfci-management", "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": "DFCI lets Intune manage firmware settings on supported Autopilot devices. Microsoft requires compatible manufacturer firmware and registration performed by the OEM or a Cloud Solution Provider partner. Devices registered manually with a CSV are excluded because the feature requires external evidence of commercial acquisition. The source also documents an out-of-box enrollment restriction for Windows 11 version 24H2 Professional editions, with a separate updated-device path after provisioning. Microsoft Learn.
\nUse this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.
\nAsk procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory. Obtain the manufacturer’s supported firmware guidance for the selected models. Review the source’s edition-specific exception before planning out-of-box enforcement. Treat a missing eligibility record as a question to resolve with the supplier, not as permission to repeat a manual import.
\nUse a representative eligible device to inspect DFCI readiness and the resulting management state after the approved provisioning path. Confirm that a selected firmware setting behaves as intended under the agreed test conditions. Keep hardware, registration, and operating-system evidence together so an enrollment failure can be assigned to the correct owner. Do not expand the purchase or deployment assumption to unverified models.
\nMicrosoft Learn: DFCI Management.
", "content_text": "Source facts\nDFCI lets Intune manage firmware settings on supported Autopilot devices. Microsoft requires compatible manufacturer firmware and registration performed by the OEM or a Cloud Solution Provider partner. Devices registered manually with a CSV are excluded because the feature requires external evidence of commercial acquisition. The source also documents an out-of-box enrollment restriction for Windows 11 version 24H2 Professional editions, with a separate updated-device path after provisioning. Microsoft Learn.\nApplicability\nUse this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.\nDSE recommendation\nAsk procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory. Obtain the manufacturer’s supported firmware guidance for the selected models. Review the source’s edition-specific exception before planning out-of-box enforcement. Treat a missing eligibility record as a question to resolve with the supplier, not as permission to repeat a manual import.\nVerification\nUse a representative eligible device to inspect DFCI readiness and the resulting management state after the approved provisioning path. Confirm that a selected firmware setting behaves as intended under the agreed test conditions. Keep hardware, registration, and operating-system evidence together so an enrollment failure can be assigned to the correct owner. Do not expand the purchase or deployment assumption to unverified models.\nOfficial references\nMicrosoft Learn: DFCI Management.", "content_markdown": "## Source facts\n\nDFCI lets Intune manage firmware settings on supported Autopilot devices. Microsoft requires compatible manufacturer firmware and registration performed by the OEM or a Cloud Solution Provider partner. Devices registered manually with a CSV are excluded because the feature requires external evidence of commercial acquisition. The source also documents an out-of-box enrollment restriction for Windows 11 version 24H2 Professional editions, with a separate updated-device path after provisioning. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/dfci-management).\n\n## Applicability\n\nUse this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.\n\n## DSE recommendation\n\nAsk procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory. Obtain the manufacturer’s supported firmware guidance for the selected models. Review the source’s edition-specific exception before planning out-of-box enforcement. Treat a missing eligibility record as a question to resolve with the supplier, not as permission to repeat a manual import.\n\n## Verification\n\nUse a representative eligible device to inspect DFCI readiness and the resulting management state after the approved provisioning path. Confirm that a selected firmware setting behaves as intended under the agreed test conditions. Keep hardware, registration, and operating-system evidence together so an enrollment failure can be assigned to the correct owner. Do not expand the purchase or deployment assumption to unverified models.\n\n## Official references\n\n[Microsoft Learn: DFCI Management](https://learn.microsoft.com/en-us/autopilot/dfci-management)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset/", "slug": "dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset", "url": "https://update.dsesecurity.com/updates/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset/" }, "title": "Check device ownership after a local or remote Autopilot Reset", "summary": "Will the primary-user and device-owner records match the intended reassignment after Autopilot Reset?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:52+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 235, "potentially_affected": "Use this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.", "dse_recommendation": "Record the intended post-reset ownership before authorizing an action that removes user material.", "primary_source": { "name": "Windows Autopilot Reset | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset", "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": "Autopilot Reset removes personal files, applications, and settings while retaining the connections to Entra ID and Intune. A local reset leaves the primary user and Entra device owner unchanged. A remote reset removes those associations and assigns the next signing-in user; shared devices remain shared. Microsoft requires a working Windows Recovery Environment and excludes hybrid-joined devices and Surface Hub from this reset method. Microsoft Learn.
\nUse this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.
\nRecord the intended post-reset ownership before authorizing an action that removes user material. Arrange protection of required data and verify the recovery-environment prerequisite through the approved support process. For a local reset, include an explicit administrator review of the unchanged ownership records. For a remote reset, coordinate which authorized person should complete the next sign-in. Keep shared-device intent visible in the handoff.
\nAfter the reset completes, inspect both the Intune primary-user record and the Entra device owner against the handoff plan. Confirm the expected management connection and perform the agreed user or shared-device workflow. Do not close the reassignment merely because the desktop opens. Resolve an unexpected owner before issuing the device, and retain identifiers and observed outcomes without copying credentials into the record.
\nMicrosoft Learn: Windows Autopilot Reset.
", "content_text": "Source facts\nAutopilot Reset removes personal files, applications, and settings while retaining the connections to Entra ID and Intune. A local reset leaves the primary user and Entra device owner unchanged. A remote reset removes those associations and assigns the next signing-in user; shared devices remain shared. Microsoft requires a working Windows Recovery Environment and excludes hybrid-joined devices and Surface Hub from this reset method. Microsoft Learn.\nApplicability\nUse this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.\nDSE recommendation\nRecord the intended post-reset ownership before authorizing an action that removes user material. Arrange protection of required data and verify the recovery-environment prerequisite through the approved support process. For a local reset, include an explicit administrator review of the unchanged ownership records. For a remote reset, coordinate which authorized person should complete the next sign-in. Keep shared-device intent visible in the handoff.\nVerification\nAfter the reset completes, inspect both the Intune primary-user record and the Entra device owner against the handoff plan. Confirm the expected management connection and perform the agreed user or shared-device workflow. Do not close the reassignment merely because the desktop opens. Resolve an unexpected owner before issuing the device, and retain identifiers and observed outcomes without copying credentials into the record.\nOfficial references\nMicrosoft Learn: Windows Autopilot Reset.", "content_markdown": "## Source facts\n\nAutopilot Reset removes personal files, applications, and settings while retaining the connections to Entra ID and Intune. A local reset leaves the primary user and Entra device owner unchanged. A remote reset removes those associations and assigns the next signing-in user; shared devices remain shared. Microsoft requires a working Windows Recovery Environment and excludes hybrid-joined devices and Surface Hub from this reset method. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset).\n\n## Applicability\n\nUse this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.\n\n## DSE recommendation\n\nRecord the intended post-reset ownership before authorizing an action that removes user material. Arrange protection of required data and verify the recovery-environment prerequisite through the approved support process. For a local reset, include an explicit administrator review of the unchanged ownership records. For a remote reset, coordinate which authorized person should complete the next sign-in. Keep shared-device intent visible in the handoff.\n\n## Verification\n\nAfter the reset completes, inspect both the Intune primary-user record and the Entra device owner against the handoff plan. Confirm the expected management connection and perform the agreed user or shared-device workflow. Do not close the reassignment merely because the desktop opens. Resolve an unexpected owner before issuing the device, and retain identifiers and observed outcomes without copying credentials into the record.\n\n## Official references\n\n[Microsoft Learn: Windows Autopilot Reset](https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-005-refresh-a-key-based-azure-function-action-after-rotating-its-access-key/", "slug": "dse-20260909-005-refresh-a-key-based-azure-function-action-after-rotating-its-access-key", "url": "https://update.dsesecurity.com/updates/dse-20260909-005-refresh-a-key-based-azure-function-action-after-rotating-its-access-key/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-005-refresh-a-key-based-azure-function-action-after-rotating-its-access-key.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-005-refresh-a-key-based-azure-function-action-after-rotating-its-access-key/" }, "title": "Refresh a key-based Azure Function action after rotating its access key", "summary": "What must change in an action group when the key saved for its Azure Function endpoint is rotated?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "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:31:51+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 234, "potentially_affected": "Azure Monitor action groups invoking Azure Functions through a saved endpoint and access key.", "dse_recommendation": "Include recreation and testing of the function action in the approved key-rotation procedure.", "primary_source": { "name": "Create and manage action groups in Azure Monitor - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups", "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": "For the documented key-based Function action, Azure Monitor saves the HTTP-trigger endpoint and its access key in the action definition. Microsoft instructs administrators to remove and recreate that action after changing the Function key. The endpoint must accept HTTP POST. Microsoft Learn.
\nAn action group must be saved before testing, including after edits. Its test provides Success or Failed status and error details when unsuccessful. Closing the running test window stops the test and prevents results from being returned. Microsoft Learn.
\nUse this procedure for Azure Monitor action groups invoking Azure Functions through a saved endpoint and access key. It is not a procedure for the separately documented managed-identity preview. Identify the authentication actually configured before choosing a rotation path.
\nDSE recommends adding the dependent function action to the key owner’s rotation record. Arrange a safe test payload and notify the workflow owner before recreating it. Keep secrets out of tickets and screenshots; record only the action identity, change reference and outcome. Do not assume that changing the Function key automatically updates an existing action definition.
\nSave the replacement action, run the selected action-group test and leave its result view open. Correlate the reported outcome with the Function owner’s observed invocation and intended downstream result. Retain sanitized errors if either observation fails, and keep the change open until the two sides agree.
\nMicrosoft Learn: Action groups.
", "content_text": "Source facts\nFor the documented key-based Function action, Azure Monitor saves the HTTP-trigger endpoint and its access key in the action definition. Microsoft instructs administrators to remove and recreate that action after changing the Function key. The endpoint must accept HTTP POST. Microsoft Learn.\nAn action group must be saved before testing, including after edits. Its test provides Success or Failed status and error details when unsuccessful. Closing the running test window stops the test and prevents results from being returned. Microsoft Learn.\nApplicability\nUse this procedure for Azure Monitor action groups invoking Azure Functions through a saved endpoint and access key. It is not a procedure for the separately documented managed-identity preview. Identify the authentication actually configured before choosing a rotation path.\nDSE recommendation\nDSE recommends adding the dependent function action to the key owner’s rotation record. Arrange a safe test payload and notify the workflow owner before recreating it. Keep secrets out of tickets and screenshots; record only the action identity, change reference and outcome. Do not assume that changing the Function key automatically updates an existing action definition.\nVerification\nSave the replacement action, run the selected action-group test and leave its result view open. Correlate the reported outcome with the Function owner’s observed invocation and intended downstream result. Retain sanitized errors if either observation fails, and keep the change open until the two sides agree.\nOfficial references\nMicrosoft Learn: Action groups.", "content_markdown": "## Source facts\n\nFor the documented key-based Function action, Azure Monitor saves the HTTP-trigger endpoint and its access key in the action definition. Microsoft instructs administrators to remove and recreate that action after changing the Function key. The endpoint must accept HTTP POST. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups).\n\nAn action group must be saved before testing, including after edits. Its test provides Success or Failed status and error details when unsuccessful. Closing the running test window stops the test and prevents results from being returned. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups).\n\n## Applicability\n\nUse this procedure for Azure Monitor action groups invoking Azure Functions through a saved endpoint and access key. It is not a procedure for the separately documented managed-identity preview. Identify the authentication actually configured before choosing a rotation path.\n\n## DSE recommendation\n\nDSE recommends adding the dependent function action to the key owner’s rotation record. Arrange a safe test payload and notify the workflow owner before recreating it. Keep secrets out of tickets and screenshots; record only the action identity, change reference and outcome. Do not assume that changing the Function key automatically updates an existing action definition.\n\n## Verification\n\nSave the replacement action, run the selected action-group test and leave its result view open. Correlate the reported outcome with the Function owner’s observed invocation and intended downstream result. Retain sanitized errors if either observation fails, and keep the change open until the two sides agree.\n\n## Official references\n\n[Microsoft Learn: Action groups](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/", "slug": "dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend", "url": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/" }, "title": "Check missing summary-rule intervals before accepting a Log Analytics trend", "summary": "How should an operator distinguish a quiet interval from an unsuccessful summary-rule bin?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "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:31:50+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 255, "potentially_affected": "Log Analytics workspaces using summary rules in the public cloud.", "dse_recommendation": "Reconcile successful bin execution with the reporting interval before accepting an aggregate trend.", "primary_source": { "name": "Aggregate data in a Log Analytics workspace with summary rules - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Summary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. Microsoft Learn.
\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. Microsoft Learn.
\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. Microsoft Learn. Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.
\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.
\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.
\nMicrosoft Learn: Aggregate data with summary rules.
", "content_text": "Source facts\nSummary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. Microsoft Learn.\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. Microsoft Learn.\nApplicability\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. Microsoft Learn. Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.\nDSE recommendation\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.\nVerification\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.\nOfficial references\nMicrosoft Learn: Aggregate data with summary rules.", "content_markdown": "## Source facts\n\nSummary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules).\n\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules).\n\n## Applicability\n\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules). Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.\n\n## DSE recommendation\n\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.\n\n## Verification\n\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.\n\n## Official references\n\n[Microsoft Learn: Aggregate data with summary rules](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link/", "slug": "dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link", "url": "https://update.dsesecurity.com/updates/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link/" }, "title": "Make a workbook ARM action visibly different from a navigation link", "summary": "What should a workbook reviewer inspect before exposing a link that executes an ARM request?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "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:31:49+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 239, "potentially_affected": "Azure Monitor workbooks with ARM action links.", "dse_recommendation": "Expose the intended target and operation clearly, and inspect the resolved request before enabling an operational workbook action.", "primary_source": { "name": "Azure Workbooks link actions - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions", "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": "Workbook link actions include both navigation and ARM operations. The ARM action configuration specifies an API path, method, parameters, headers and JSON body; its method choices include POST, PUT, PATCH and DELETE. Parameters and grid-column values can supply request content. Microsoft Learn.
\nSelecting the link opens a configured run view. The action executes when the user selects its run button. View Request Details exposes the request method and endpoint, while an Azure portal notification reports progress and outcome. Microsoft Learn.
\nThis review concerns Azure Monitor workbooks with ARM action links. Keep it separate from ordinary resource navigation and workbook formatting. Do not describe an action as a harmless detail view merely because both begin with a click.
\nDSE recommends wording the link and run button around the actual operation. Include the intended resource in the description and identify which row or parameter supplies it. Review every dynamic input against the operator’s intended selection. For a destructive request, require the existing change-approval process and an explicit target check; publishing a workbook is not approval to execute its actions.
\nUse a disposable resource and inspect the resolved request before execution. Compare the displayed target with the endpoint and body, then record the notification and resulting resource state. Repeat with a different row to detect a fixed or incorrectly bound target. Keep the reviewed workbook version with these observations.
\nMicrosoft Learn: Workbook link actions.
", "content_text": "Source facts\nWorkbook link actions include both navigation and ARM operations. The ARM action configuration specifies an API path, method, parameters, headers and JSON body; its method choices include POST, PUT, PATCH and DELETE. Parameters and grid-column values can supply request content. Microsoft Learn.\nSelecting the link opens a configured run view. The action executes when the user selects its run button. View Request Details exposes the request method and endpoint, while an Azure portal notification reports progress and outcome. Microsoft Learn.\nApplicability\nThis review concerns Azure Monitor workbooks with ARM action links. Keep it separate from ordinary resource navigation and workbook formatting. Do not describe an action as a harmless detail view merely because both begin with a click.\nDSE recommendation\nDSE recommends wording the link and run button around the actual operation. Include the intended resource in the description and identify which row or parameter supplies it. Review every dynamic input against the operator’s intended selection. For a destructive request, require the existing change-approval process and an explicit target check; publishing a workbook is not approval to execute its actions.\nVerification\nUse a disposable resource and inspect the resolved request before execution. Compare the displayed target with the endpoint and body, then record the notification and resulting resource state. Repeat with a different row to detect a fixed or incorrectly bound target. Keep the reviewed workbook version with these observations.\nOfficial references\nMicrosoft Learn: Workbook link actions.", "content_markdown": "## Source facts\n\nWorkbook link actions include both navigation and ARM operations. The ARM action configuration specifies an API path, method, parameters, headers and JSON body; its method choices include POST, PUT, PATCH and DELETE. Parameters and grid-column values can supply request content. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions).\n\nSelecting the link opens a configured run view. The action executes when the user selects its run button. View Request Details exposes the request method and endpoint, while an Azure portal notification reports progress and outcome. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions).\n\n## Applicability\n\nThis review concerns Azure Monitor workbooks with ARM action links. Keep it separate from ordinary resource navigation and workbook formatting. Do not describe an action as a harmless detail view merely because both begin with a click.\n\n## DSE recommendation\n\nDSE recommends wording the link and run button around the actual operation. Include the intended resource in the description and identify which row or parameter supplies it. Review every dynamic input against the operator’s intended selection. For a destructive request, require the existing change-approval process and an explicit target check; publishing a workbook is not approval to execute its actions.\n\n## Verification\n\nUse a disposable resource and inspect the resolved request before execution. Compare the displayed target with the endpoint and body, then record the notification and resulting resource state. Repeat with a different row to detect a fixed or incorrectly bound target. Keep the reviewed workbook version with these observations.\n\n## Official references\n\n[Microsoft Learn: Workbook link actions](https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/", "slug": "dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request", "url": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/" }, "title": "Validate the HANA host role before submitting a NetApp volume-group request", "summary": "Can the same NetApp application-volume-group payload be reused for the first and every additional HANA host?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "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:31:48+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 247, "potentially_affected": "Use this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source's networking, placement and protocol requirements before deployment.", "dse_recommendation": "Make host role and expected volume roles explicit inputs to the deployment review.", "primary_source": { "name": "Configure application volume groups for SAP HANA using REST API | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api", "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": "An Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. Microsoft Learn.
\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.
\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.
\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.
\nMicrosoft Learn: Configure application volume groups for SAP HANA using REST API.
", "content_text": "Source facts\nAn Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. Microsoft Learn.\nApplicability\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.\nDSE recommendation\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.\nVerification\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.\nOfficial references\nMicrosoft Learn: Configure application volume groups for SAP HANA using REST API.", "content_markdown": "## Source facts\n\nAn Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api).\n\n## Applicability\n\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.\n\n## DSE recommendation\n\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.\n\n## Verification\n\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.\n\n## Official references\n\n[Microsoft Learn: Configure application volume groups for SAP HANA using REST API](https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack/", "slug": "dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack", "url": "https://update.dsesecurity.com/updates/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack/" }, "title": "Choose what happens when a resource leaves an Azure deployment stack", "summary": "Make removal from a stack an explicit detach-or-delete decision, with special scrutiny for resource-group deletion.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "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:31:47+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 1, "word_count": 211, "potentially_affected": "Azure resources managed by deployment stacks.", "dse_recommendation": "Approve the intended detach-or-delete outcome for each removed resource before updating the stack.", "primary_source": { "name": "Create and deploy Azure deployment stacks in Bicep - Azure Resource Manager | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks", "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": "Removing a resource from a deployment stack’s template can detach that resource or delete it; the stack’s actionOnUnmanage setting determines the outcome.
\nMicrosoft warns that deleting managed resource groups with deleteAll also deletes everything inside those groups. The impact therefore extends beyond an individual resource removed from a template. Microsoft Learn.
\nUse this review for a stack update or retirement. Identify the stack scope, managed resources, underlying template, and proposed removal behavior. Include group contents in the review whenever a resource group could be deleted.
\nDSE recommends a removal manifest with one intended outcome per resource: retain outside the stack or delete under an approved retirement. Have the workload owner confirm dependencies and data-retention needs. Keep the reviewed template and stack settings together, and reject an unexplained change from retention to deletion. Do not use environment cleanup as implicit approval to remove shared resources.
\nRehearse the exact removal in a disposable stack. Compare the surviving Azure resources with the stack’s managed-resource list, then check the intended retained resource directly. For a group-deletion rehearsal, inventory every child beforehand and reconcile the result afterward. Preserve that evidence before approving the production update.
\nMicrosoft Learn: Create and deploy Azure deployment stacks in Bicep. Source retrieved September 9, 2026.
", "content_text": "Source facts\nRemoving a resource from a deployment stack’s template can detach that resource or delete it; the stack’s actionOnUnmanage setting determines the outcome.\nMicrosoft warns that deleting managed resource groups with deleteAll also deletes everything inside those groups. The impact therefore extends beyond an individual resource removed from a template. Microsoft Learn.\nApplicability\nUse this review for a stack update or retirement. Identify the stack scope, managed resources, underlying template, and proposed removal behavior. Include group contents in the review whenever a resource group could be deleted.\nDSE recommendation\nDSE recommends a removal manifest with one intended outcome per resource: retain outside the stack or delete under an approved retirement. Have the workload owner confirm dependencies and data-retention needs. Keep the reviewed template and stack settings together, and reject an unexplained change from retention to deletion. Do not use environment cleanup as implicit approval to remove shared resources.\nVerification\nRehearse the exact removal in a disposable stack. Compare the surviving Azure resources with the stack’s managed-resource list, then check the intended retained resource directly. For a group-deletion rehearsal, inventory every child beforehand and reconcile the result afterward. Preserve that evidence before approving the production update.\nOfficial references\nMicrosoft Learn: Create and deploy Azure deployment stacks in Bicep. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nRemoving a resource from a deployment stack’s template can detach that resource or delete it; the stack’s actionOnUnmanage setting determines the outcome.\n\nMicrosoft warns that deleting managed resource groups with deleteAll also deletes everything inside those groups. The impact therefore extends beyond an individual resource removed from a template. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks).\n\n## Applicability\n\nUse this review for a stack update or retirement. Identify the stack scope, managed resources, underlying template, and proposed removal behavior. Include group contents in the review whenever a resource group could be deleted.\n\n## DSE recommendation\n\nDSE recommends a removal manifest with one intended outcome per resource: retain outside the stack or delete under an approved retirement. Have the workload owner confirm dependencies and data-retention needs. Keep the reviewed template and stack settings together, and reject an unexplained change from retention to deletion. Do not use environment cleanup as implicit approval to remove shared resources.\n\n## Verification\n\nRehearse the exact removal in a disposable stack. Compare the surviving Azure resources with the stack’s managed-resource list, then check the intended retained resource directly. For a group-deletion rehearsal, inventory every child beforehand and reconcile the result afterward. Preserve that evidence before approving the production update.\n\n## Official references\n\n[Microsoft Learn: Create and deploy Azure deployment stacks in Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store/", "slug": "dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store", "url": "https://update.dsesecurity.com/updates/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store/" }, "title": "Distinguish a managed-application package URL from its BYOS definition store", "summary": "Which storage location retains the managed-application definition after a BYOS publication?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "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:31:46+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 242, "potentially_affected": "Azure Managed Applications service-catalog definitions using bring-your-own storage.", "dse_recommendation": "DSE recommends recording both locations and the writer identity before publication.", "primary_source": { "name": "Bring your own storage to create and publish an Azure Managed Application definition - Azure Managed Applications | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage", "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": "In a managed-application BYOS definition, packageFileUri identifies the input ZIP, while storageAccountId identifies the account used to retain definition files. Deployment creates an applicationdefinitions container there and copies the package’s files into it. Microsoft requires the Appliance Resource Provider identity to have Contributor at that storage account so it can write those files. BYOS definition deployment supports ARM templates or REST. Microsoft Learn.
\nManaged Applications accepts ARM languageVersion 1.0, not 2.0. Microsoft Learn.
\nIdentify the package source and the definition-storage destination as separate roles, even if a design places them close together. This review concerns definition publication, not the later application’s runtime storage or the publisher’s access to a customer’s managed resource group.
\nDSE recommends recording both locations and the writer identity before publication. Have the storage owner verify the destination account and scoped role assignment, and compare the package URL against the approved release artifact. Review the complete supported deployment path rather than substituting a source URL for the destination account identifier. Keep storage-security changes under their own approval.
\nAfter an approved definition deployment, inspect the destination account’s applicationdefinitions container and confirm the expected definition files are present. Compare that evidence with the input archive and publication record. Verify the intended reader can access the definition separately from the service identity’s write access. Do not report a successful upload to the package-source container as proof that BYOS definition publication completed.
\nMicrosoft Learn. Source retrieved September 9, 2026.
", "content_text": "Source facts\nIn a managed-application BYOS definition, packageFileUri identifies the input ZIP, while storageAccountId identifies the account used to retain definition files. Deployment creates an applicationdefinitions container there and copies the package’s files into it. Microsoft requires the Appliance Resource Provider identity to have Contributor at that storage account so it can write those files. BYOS definition deployment supports ARM templates or REST. Microsoft Learn.\nApplicability\nManaged Applications accepts ARM languageVersion 1.0, not 2.0. Microsoft Learn.\nIdentify the package source and the definition-storage destination as separate roles, even if a design places them close together. This review concerns definition publication, not the later application’s runtime storage or the publisher’s access to a customer’s managed resource group.\nDSE recommendation\nDSE recommends recording both locations and the writer identity before publication. Have the storage owner verify the destination account and scoped role assignment, and compare the package URL against the approved release artifact. Review the complete supported deployment path rather than substituting a source URL for the destination account identifier. Keep storage-security changes under their own approval.\nVerification\nAfter an approved definition deployment, inspect the destination account’s applicationdefinitions container and confirm the expected definition files are present. Compare that evidence with the input archive and publication record. Verify the intended reader can access the definition separately from the service identity’s write access. Do not report a successful upload to the package-source container as proof that BYOS definition publication completed.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nIn a managed-application BYOS definition, packageFileUri identifies the input ZIP, while storageAccountId identifies the account used to retain definition files. Deployment creates an applicationdefinitions container there and copies the package’s files into it. Microsoft requires the Appliance Resource Provider identity to have Contributor at that storage account so it can write those files. BYOS definition deployment supports ARM templates or REST. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage).\n\n## Applicability\n\nManaged Applications accepts ARM languageVersion 1.0, not 2.0. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage).\n\nIdentify the package source and the definition-storage destination as separate roles, even if a design places them close together. This review concerns definition publication, not the later application’s runtime storage or the publisher’s access to a customer’s managed resource group.\n\n## DSE recommendation\n\nDSE recommends recording both locations and the writer identity before publication. Have the storage owner verify the destination account and scoped role assignment, and compare the package URL against the approved release artifact. Review the complete supported deployment path rather than substituting a source URL for the destination account identifier. Keep storage-security changes under their own approval.\n\n## Verification\n\nAfter an approved definition deployment, inspect the destination account’s applicationdefinitions container and confirm the expected definition files are present. Compare that evidence with the input archive and publication record. Verify the intended reader can access the definition separately from the service identity’s write access. Do not report a successful upload to the package-source container as proof that BYOS definition publication completed.\n\n## Official references\n\n[Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/", "slug": "dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup", "url": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/" }, "title": "Do not equate a MARS volume snapshot with application-consistent backup", "summary": "Does the MARS agent's use of VSS establish application-consistent recovery for the files it protects?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "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:31:45+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 235, "potentially_affected": "Identify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server's stored data.", "dse_recommendation": "Match the required application recovery behavior to the selected backup method before accepting coverage.", "primary_source": { "name": "Architecture Overview - Azure Backup | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/backup/backup-architecture", "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": "For direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. Microsoft Learn.
\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.
\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.
\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.
\nMicrosoft Learn: Architecture Overview.
", "content_text": "Source facts\nFor direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. Microsoft Learn.\nApplicability\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.\nDSE recommendation\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.\nVerification\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.\nOfficial references\nMicrosoft Learn: Architecture Overview.", "content_markdown": "## Source facts\n\nFor direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/backup/backup-architecture).\n\n## Applicability\n\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.\n\n## DSE recommendation\n\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.\n\n## Verification\n\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.\n\n## Official references\n\n[Microsoft Learn: Architecture Overview](https://learn.microsoft.com/en-us/azure/backup/backup-architecture)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull/", "slug": "dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull", "url": "https://update.dsesecurity.com/updates/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull/" }, "title": "Check the registry support boundary before retrying a private ACI image pull", "summary": "Will private network reachability make any private registry usable by Azure Container Instances?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "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:31:44+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 232, "potentially_affected": "Apply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.", "dse_recommendation": "Confirm the registry type before expanding network access or repeating deployment.", "primary_source": { "name": "Troubleshoot common issues - Azure Container Instances | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting", "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 says ACI supports image pulls from registries without a public IP only through Azure Container Registry with a private endpoint and managed identity. Non-ACR private registries remain unsupported even when network connectivity exists. An unsuccessful image pull is retried before deployment eventually fails, and the container group’s events expose pull and failure information. Microsoft Learn.
\nApply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.
\nConfirm the registry type before expanding network access or repeating deployment. Record the registry endpoint, intended image identity and the supported authentication arrangement. If the design uses a non-ACR private registry, raise the unsupported architecture with the application owner and plan an approved image-publication route. Do not expose a private registry publicly just to test whether the deployment succeeds. Keep any registry migration separate from the immediate failure investigation.
\nInspect the failed group’s pull events and correlate them with the intended registry and image. In an authorized pilot of the supported ACR design, confirm that the expected artifact is obtained through the approved private endpoint and identity. Retain deployment and registry evidence together. A successful reachability probe should not be reported as proof that ACI supports the selected private-registry architecture.
\nMicrosoft Learn: Troubleshoot common issues.
", "content_text": "Source facts\nMicrosoft says ACI supports image pulls from registries without a public IP only through Azure Container Registry with a private endpoint and managed identity. Non-ACR private registries remain unsupported even when network connectivity exists. An unsuccessful image pull is retried before deployment eventually fails, and the container group’s events expose pull and failure information. Microsoft Learn.\nApplicability\nApply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.\nDSE recommendation\nConfirm the registry type before expanding network access or repeating deployment. Record the registry endpoint, intended image identity and the supported authentication arrangement. If the design uses a non-ACR private registry, raise the unsupported architecture with the application owner and plan an approved image-publication route. Do not expose a private registry publicly just to test whether the deployment succeeds. Keep any registry migration separate from the immediate failure investigation.\nVerification\nInspect the failed group’s pull events and correlate them with the intended registry and image. In an authorized pilot of the supported ACR design, confirm that the expected artifact is obtained through the approved private endpoint and identity. Retain deployment and registry evidence together. A successful reachability probe should not be reported as proof that ACI supports the selected private-registry architecture.\nOfficial references\nMicrosoft Learn: Troubleshoot common issues.", "content_markdown": "## Source facts\n\nMicrosoft says ACI supports image pulls from registries without a public IP only through Azure Container Registry with a private endpoint and managed identity. Non-ACR private registries remain unsupported even when network connectivity exists. An unsuccessful image pull is retried before deployment eventually fails, and the container group’s events expose pull and failure information. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting).\n\n## Applicability\n\nApply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.\n\n## DSE recommendation\n\nConfirm the registry type before expanding network access or repeating deployment. Record the registry endpoint, intended image identity and the supported authentication arrangement. If the design uses a non-ACR private registry, raise the unsupported architecture with the application owner and plan an approved image-publication route. Do not expose a private registry publicly just to test whether the deployment succeeds. Keep any registry migration separate from the immediate failure investigation.\n\n## Verification\n\nInspect the failed group’s pull events and correlate them with the intended registry and image. In an authorized pilot of the supported ACR design, confirm that the expected artifact is obtained through the approved private endpoint and identity. Retain deployment and registry evidence together. A successful reachability probe should not be reported as proof that ACI supports the selected private-registry architecture.\n\n## Official references\n\n[Microsoft Learn: Troubleshoot common issues](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access/", "slug": "dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access", "url": "https://update.dsesecurity.com/updates/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access/" }, "title": "Separate Machine Configuration service access from custom package access", "summary": "Review the service path and package location separately when restricting Machine Configuration network access.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "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:31:43+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 223, "potentially_affected": "Azure VMs and Arc-enabled servers using Machine Configuration.", "dse_recommendation": "Record the service connection and every custom package location before approving egress restrictions.", "primary_source": { "name": "Azure Machine Configuration network requirements - Azure Machine Configuration | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview/03-network-requirements", "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": "For the Azure virtual-network path, Microsoft requires outbound port 443 access and identifies both AzureArcInfrastructure and Storage service tags. Storage is needed because it hosts configuration packages.
\nAzure VMs using the documented private-link path do not need publicly reachable regional GAS endpoints. However, a custom package at a public Storage or non-Azure URL still needs a reachable, allowed URL. Built-in packages on Arc-enabled servers using private link follow that link without additional server tags.
\nThe Arc built-in-package behavior is documented separately from the Azure VM tagging procedure. Microsoft Learn.
\nIdentify whether each target is an Azure VM or an Arc-enabled server, and whether its package is built in or custom. Do not copy one platform’s network assumptions to the other.
\nDSE recommends a two-column access record: service communication and package download. Record the actual package URI from the assignment, its hosting boundary, and the approved route. Review public package dependencies before closing egress. Ask the configuration owner to identify a representative assignment for each distinct package-hosting pattern.
\nOn approved test machines, compare service reporting with package retrieval and assignment execution. Preserve the target type, assignment, observed destination, and outcome separately. Investigate a successful service connection alongside a failed package download before declaring the restricted design ready.
\nMicrosoft Learn: Azure Machine Configuration network requirements. Source retrieved September 9, 2026.
", "content_text": "Source facts\nFor the Azure virtual-network path, Microsoft requires outbound port 443 access and identifies both AzureArcInfrastructure and Storage service tags. Storage is needed because it hosts configuration packages.\nAzure VMs using the documented private-link path do not need publicly reachable regional GAS endpoints. However, a custom package at a public Storage or non-Azure URL still needs a reachable, allowed URL. Built-in packages on Arc-enabled servers using private link follow that link without additional server tags.\nThe Arc built-in-package behavior is documented separately from the Azure VM tagging procedure. Microsoft Learn.\nApplicability\nIdentify whether each target is an Azure VM or an Arc-enabled server, and whether its package is built in or custom. Do not copy one platform’s network assumptions to the other.\nDSE recommendation\nDSE recommends a two-column access record: service communication and package download. Record the actual package URI from the assignment, its hosting boundary, and the approved route. Review public package dependencies before closing egress. Ask the configuration owner to identify a representative assignment for each distinct package-hosting pattern.\nVerification\nOn approved test machines, compare service reporting with package retrieval and assignment execution. Preserve the target type, assignment, observed destination, and outcome separately. Investigate a successful service connection alongside a failed package download before declaring the restricted design ready.\nOfficial references\nMicrosoft Learn: Azure Machine Configuration network requirements. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nFor the Azure virtual-network path, Microsoft requires outbound port 443 access and identifies both AzureArcInfrastructure and Storage service tags. Storage is needed because it hosts configuration packages.\n\nAzure VMs using the documented private-link path do not need publicly reachable regional GAS endpoints. However, a custom package at a public Storage or non-Azure URL still needs a reachable, allowed URL. Built-in packages on Arc-enabled servers using private link follow that link without additional server tags.\n\nThe Arc built-in-package behavior is documented separately from the Azure VM tagging procedure. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview/03-network-requirements).\n\n## Applicability\n\nIdentify whether each target is an Azure VM or an Arc-enabled server, and whether its package is built in or custom. Do not copy one platform’s network assumptions to the other.\n\n## DSE recommendation\n\nDSE recommends a two-column access record: service communication and package download. Record the actual package URI from the assignment, its hosting boundary, and the approved route. Review public package dependencies before closing egress. Ask the configuration owner to identify a representative assignment for each distinct package-hosting pattern.\n\n## Verification\n\nOn approved test machines, compare service reporting with package retrieval and assignment execution. Preserve the target type, assignment, observed destination, and outcome separately. Investigate a successful service connection alongside a failed package download before declaring the restricted design ready.\n\n## Official references\n\n[Microsoft Learn: Azure Machine Configuration network requirements](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview/03-network-requirements). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection/", "slug": "dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection", "url": "https://update.dsesecurity.com/updates/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection/" }, "title": "Place NAT Gateway behind Azure Firewall without bypassing spoke inspection", "summary": "Keep the spoke route, firewall policy, and NAT association aligned when expanding outbound connectivity.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "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:31:42+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 1, "word_count": 219, "potentially_affected": "Azure Firewall hub-and-spoke networks considering NAT Gateway integration.", "dse_recommendation": "Review spoke-to-firewall routing and the AzureFirewallSubnet NAT association as one egress change.", "primary_source": { "name": "Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network - Azure NAT Gateway | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/nat-gateway/tutorial-hub-spoke-nat-firewall", "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 example associates NAT Gateway with AzureFirewallSubnet. The spoke route table points to Azure Firewall’s private address, and firewall policy must permit the spoke traffic. NAT integration therefore accompanies an explicit route through the firewall.
\nThis placement does not extend to a Virtual WAN hub: Microsoft says NAT Gateway is unsupported there and instead must be attached directly to the relevant spoke networks for that architecture. Microsoft Learn.
\nConfirm that the design is a conventional hub-and-spoke network before adopting this tutorial. Record each spoke subnet, its route table, the firewall address, and the proposed NAT association; keep Virtual WAN designs in a separate review.
\nDSE recommends treating this as an egress-path change, not just creation of a NAT resource. Obtain the application owner’s approved destinations and the network owner’s expected translated address. Compare the route and firewall policy before associating the gateway. Retain the previous configuration and an agreed rollback decision.
\nFrom a test spoke, exercise an allowed internet destination and a deliberately prohibited one. Check the observed outbound address and firewall evidence together. A successful internet request alone should not satisfy acceptance; reconcile the actual next hop and policy result with the approved design.
\nMicrosoft Learn: Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network. Source retrieved September 9, 2026.
", "content_text": "Source facts\nMicrosoft’s example associates NAT Gateway with AzureFirewallSubnet. The spoke route table points to Azure Firewall’s private address, and firewall policy must permit the spoke traffic. NAT integration therefore accompanies an explicit route through the firewall.\nThis placement does not extend to a Virtual WAN hub: Microsoft says NAT Gateway is unsupported there and instead must be attached directly to the relevant spoke networks for that architecture. Microsoft Learn.\nApplicability\nConfirm that the design is a conventional hub-and-spoke network before adopting this tutorial. Record each spoke subnet, its route table, the firewall address, and the proposed NAT association; keep Virtual WAN designs in a separate review.\nDSE recommendation\nDSE recommends treating this as an egress-path change, not just creation of a NAT resource. Obtain the application owner’s approved destinations and the network owner’s expected translated address. Compare the route and firewall policy before associating the gateway. Retain the previous configuration and an agreed rollback decision.\nVerification\nFrom a test spoke, exercise an allowed internet destination and a deliberately prohibited one. Check the observed outbound address and firewall evidence together. A successful internet request alone should not satisfy acceptance; reconcile the actual next hop and policy result with the approved design.\nOfficial references\nMicrosoft Learn: Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft’s example associates NAT Gateway with AzureFirewallSubnet. The spoke route table points to Azure Firewall’s private address, and firewall policy must permit the spoke traffic. NAT integration therefore accompanies an explicit route through the firewall.\n\nThis placement does not extend to a Virtual WAN hub: Microsoft says NAT Gateway is unsupported there and instead must be attached directly to the relevant spoke networks for that architecture. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/nat-gateway/tutorial-hub-spoke-nat-firewall).\n\n## Applicability\n\nConfirm that the design is a conventional hub-and-spoke network before adopting this tutorial. Record each spoke subnet, its route table, the firewall address, and the proposed NAT association; keep Virtual WAN designs in a separate review.\n\n## DSE recommendation\n\nDSE recommends treating this as an egress-path change, not just creation of a NAT resource. Obtain the application owner’s approved destinations and the network owner’s expected translated address. Compare the route and firewall policy before associating the gateway. Retain the previous configuration and an agreed rollback decision.\n\n## Verification\n\nFrom a test spoke, exercise an allowed internet destination and a deliberately prohibited one. Check the observed outbound address and firewall evidence together. A successful internet request alone should not satisfy acceptance; reconcile the actual next hop and policy result with the approved design.\n\n## Official references\n\n[Microsoft Learn: Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network](https://learn.microsoft.com/en-us/azure/nat-gateway/tutorial-hub-spoke-nat-firewall). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/", "slug": "dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery", "url": "https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/" }, "title": "Return the right state-change result from Service Fabric data-loss recovery", "summary": "What should a Service Fabric OnDataLossAsync implementation return after examining or restoring surviving state?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:41+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 236, "potentially_affected": "Custom stateful Service Fabric services implementing OnDataLossAsync recovery handling.", "dse_recommendation": "DSE recommends making the handler's return value an explicit state-change contract.", "primary_source": { "name": "Azure Service Fabric disaster recovery - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery", "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": "Service Fabric calls OnDataLossAsync for suspected, not necessarily proven, data loss and chooses the remaining replica with the most progress. After examination and any restoration, the handler returns true if it changed state and false if it did not. A true result causes other remaining replicas to be dropped and rebuilt from that replica; false lets them retain their state. Microsoft Learn.
\nUse this review for application-owned recovery code, not as permission to force system services out of quorum loss. Establish how the implementation decides whether state changed. Keep the decision to restore a backup separate from the meaning of the Boolean result.
\nDSE recommends making the handler’s return value an explicit state-change contract. Have the service owner review the paths for no change, successful restoration and incomplete investigation. Define how coordinated services will be checked before recovery is accepted, and preserve enough evidence to explain which state was selected. Do not return a success-looking value merely because the handler reached its final line.
\nIn a disposable failure simulation, exercise both an unchanged surviving replica and a path that actually modifies state. Inspect the returned value and resulting handling of the remaining replicas. Verify application data and cross-service consistency after the test, not just replica availability. Record why the handler concluded that a change did or did not occur before approving the implementation.
\nMicrosoft Learn. Source retrieved September 9, 2026.
", "content_text": "Source facts\nService Fabric calls OnDataLossAsync for suspected, not necessarily proven, data loss and chooses the remaining replica with the most progress. After examination and any restoration, the handler returns true if it changed state and false if it did not. A true result causes other remaining replicas to be dropped and rebuilt from that replica; false lets them retain their state. Microsoft Learn.\nApplicability\nUse this review for application-owned recovery code, not as permission to force system services out of quorum loss. Establish how the implementation decides whether state changed. Keep the decision to restore a backup separate from the meaning of the Boolean result.\nDSE recommendation\nDSE recommends making the handler’s return value an explicit state-change contract. Have the service owner review the paths for no change, successful restoration and incomplete investigation. Define how coordinated services will be checked before recovery is accepted, and preserve enough evidence to explain which state was selected. Do not return a success-looking value merely because the handler reached its final line.\nVerification\nIn a disposable failure simulation, exercise both an unchanged surviving replica and a path that actually modifies state. Inspect the returned value and resulting handling of the remaining replicas. Verify application data and cross-service consistency after the test, not just replica availability. Record why the handler concluded that a change did or did not occur before approving the implementation.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nService Fabric calls OnDataLossAsync for suspected, not necessarily proven, data loss and chooses the remaining replica with the most progress. After examination and any restoration, the handler returns true if it changed state and false if it did not. A true result causes other remaining replicas to be dropped and rebuilt from that replica; false lets them retain their state. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery).\n\n## Applicability\n\nUse this review for application-owned recovery code, not as permission to force system services out of quorum loss. Establish how the implementation decides whether state changed. Keep the decision to restore a backup separate from the meaning of the Boolean result.\n\n## DSE recommendation\n\nDSE recommends making the handler’s return value an explicit state-change contract. Have the service owner review the paths for no change, successful restoration and incomplete investigation. Define how coordinated services will be checked before recovery is accepted, and preserve enough evidence to explain which state was selected. Do not return a success-looking value merely because the handler reached its final line.\n\n## Verification\n\nIn a disposable failure simulation, exercise both an unchanged surviving replica and a path that actually modifies state. Inspect the returned value and resulting handling of the remaining replicas. Verify application data and cross-service consistency after the test, not just replica availability. Record why the handler concluded that a change did or did not occur before approving the implementation.\n\n## Official references\n\n[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials/", "slug": "dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials", "url": "https://update.dsesecurity.com/updates/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials/" }, "title": "Register a manually installed Mobility agent without discovery credentials", "summary": "How should a modernized Site Recovery agent be registered when machine and virtualization discovery credentials cannot be supplied?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:40+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 229, "potentially_affected": "Consider this workflow for on-premises VMware or physical-machine protection using the modernized architecture. Establish which appliance should own the registration, and confirm the source operating system and installation permissions before choosing the manual path.", "dse_recommendation": "Document the machine-to-appliance pairing before distributing installation material.", "primary_source": { "name": "About the Mobility service for disaster recovery of VMware VMs and physical servers with Azure Site Recovery - Azure Site Recovery | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-mobility-service-overview", "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": "Modernized Azure Site Recovery offers credential-less discovery when the machine and vCenter or ESXi credentials cannot be provided. This path requires manually installing the Mobility service and enabling its credential-less discovery option. Registration uses a configuration file generated on the chosen appliance from the source machine’s unique details string. The configuration file is then supplied to the agent on that source machine. Microsoft Learn.
\nConsider this workflow for on-premises VMware or physical-machine protection using the modernized architecture. Establish which appliance should own the registration, and confirm the source operating system and installation permissions before choosing the manual path.
\nDocument the machine-to-appliance pairing before distributing installation material. Keep each source identifier associated with its own generated configuration file; do not circulate one convenient file as a fleet-wide registration package. Separate approval to install the service from the decision to supply discovery credentials, and record which documented installation mode was selected.
\nOn a controlled candidate machine, verify the identifier used to generate the file, the intended appliance, and the registration result. Reconcile the registered source with the inventory before enabling replication. Treat a completed software installation as an intermediate checkpoint: do not close onboarding until the correct machine has registered through the chosen workflow.
\nData Lake Storage keeps an item’s permissions on that item. A directory’s default ACL supplies inheritance when a child is created; changing the default afterward does not update existing children. Existing access ACLs and default ACLs therefore require their own review.
\nWhen access is granted only through ACLs, a file reader or writer also needs Execute permission on the container root and every intervening directory. That qualification matters when testing the resulting access path. Microsoft Learn.
\nApply this distinction to ACL-based directory permissions. Identify the caller and authorization route before testing, and record any broader role grants rather than assuming an access result came from the ACL alone.
\nDSE recommends separating the change request into future-child defaults and the explicitly approved existing-child population. Inventory both before making changes. Have the data owner specify intended access for each population, and preserve the original ACLs so an incorrect broad change can be investigated and reversed deliberately.
\nUse a controlled directory containing a preexisting file, then create a second file after the default change. Compare the stored permissions and actual authorized-user access for both. Check directory traversal separately, and include an unintended user in the denial test. Retain object paths and ACL evidence without copying sensitive file contents.
\nMicrosoft Learn: Access control lists (ACLs) in Azure Data Lake Storage. Source retrieved September 9, 2026.
", "content_text": "Source facts\nData Lake Storage keeps an item’s permissions on that item. A directory’s default ACL supplies inheritance when a child is created; changing the default afterward does not update existing children. Existing access ACLs and default ACLs therefore require their own review.\nWhen access is granted only through ACLs, a file reader or writer also needs Execute permission on the container root and every intervening directory. That qualification matters when testing the resulting access path. Microsoft Learn.\nApplicability\nApply this distinction to ACL-based directory permissions. Identify the caller and authorization route before testing, and record any broader role grants rather than assuming an access result came from the ACL alone.\nDSE recommendation\nDSE recommends separating the change request into future-child defaults and the explicitly approved existing-child population. Inventory both before making changes. Have the data owner specify intended access for each population, and preserve the original ACLs so an incorrect broad change can be investigated and reversed deliberately.\nVerification\nUse a controlled directory containing a preexisting file, then create a second file after the default change. Compare the stored permissions and actual authorized-user access for both. Check directory traversal separately, and include an unintended user in the denial test. Retain object paths and ACL evidence without copying sensitive file contents.\nOfficial references\nMicrosoft Learn: Access control lists (ACLs) in Azure Data Lake Storage. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nData Lake Storage keeps an item’s permissions on that item. A directory’s default ACL supplies inheritance when a child is created; changing the default afterward does not update existing children. Existing access ACLs and default ACLs therefore require their own review.\n\nWhen access is granted only through ACLs, a file reader or writer also needs Execute permission on the container root and every intervening directory. That qualification matters when testing the resulting access path. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control).\n\n## Applicability\n\nApply this distinction to ACL-based directory permissions. Identify the caller and authorization route before testing, and record any broader role grants rather than assuming an access result came from the ACL alone.\n\n## DSE recommendation\n\nDSE recommends separating the change request into future-child defaults and the explicitly approved existing-child population. Inventory both before making changes. Have the data owner specify intended access for each population, and preserve the original ACLs so an incorrect broad change can be investigated and reversed deliberately.\n\n## Verification\n\nUse a controlled directory containing a preexisting file, then create a second file after the default change. Compare the stored permissions and actual authorized-user access for both. Check directory traversal separately, and include an unintended user in the denial test. Retain object paths and ACL evidence without copying sensitive file contents.\n\n## Official references\n\n[Microsoft Learn: Access control lists (ACLs) in Azure Data Lake Storage](https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/", "slug": "dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group", "url": "https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/" }, "title": "Choose the key identity before creating an encrypted Elastic SAN volume group", "summary": "Distinguish customer-managed-key setup during volume-group creation from configuration of an existing group.", "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": "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:31:38+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 226, "potentially_affected": "Azure Elastic SAN volume groups using customer-managed encryption keys.", "dse_recommendation": "Prepare a user-assigned identity for creation-time key access, and review later identity changes separately.", "primary_source": { "name": "Configure Customer-Managed Keys for Azure Elastic SAN | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys", "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": "A new Elastic SAN volume group using customer-managed keys requires a user-assigned identity. A system-assigned identity is not available before the group exists, so that identity can be configured for key access only afterward, with appropriate permissions.
\nThe key vault must have both soft delete and purge protection enabled. These are prerequisites for the documented customer-managed-key configuration, not substitutes for granting the chosen identity access to the key. Microsoft Learn.
\nUse this review when deciding whether encryption is configured during creation or added to an existing volume group. Record the group, identity, vault, key, and selected key-version update method before adapting the source’s examples.
\nDSE recommends making identity readiness a deployment prerequisite. Have the storage and key-vault owners agree which identity should retain access, then document the approved grant and its scope. Do not silently switch identity types to work around an authorization failure. Treat any later identity replacement as a separate change with dependency evidence.
\nRehearse the chosen creation or update path in a nonproduction volume group. Inspect the resulting encryption configuration, the actual identity identifier, and the corresponding vault grant. Check an approved read/write workload afterward and retain the result. Record key identifiers and permissions, never secret key material, in the deployment evidence.
\nMicrosoft Learn: Configure Customer-Managed Keys for Azure Elastic SAN. Source retrieved September 9, 2026.
", "content_text": "Source facts\nA new Elastic SAN volume group using customer-managed keys requires a user-assigned identity. A system-assigned identity is not available before the group exists, so that identity can be configured for key access only afterward, with appropriate permissions.\nThe key vault must have both soft delete and purge protection enabled. These are prerequisites for the documented customer-managed-key configuration, not substitutes for granting the chosen identity access to the key. Microsoft Learn.\nApplicability\nUse this review when deciding whether encryption is configured during creation or added to an existing volume group. Record the group, identity, vault, key, and selected key-version update method before adapting the source’s examples.\nDSE recommendation\nDSE recommends making identity readiness a deployment prerequisite. Have the storage and key-vault owners agree which identity should retain access, then document the approved grant and its scope. Do not silently switch identity types to work around an authorization failure. Treat any later identity replacement as a separate change with dependency evidence.\nVerification\nRehearse the chosen creation or update path in a nonproduction volume group. Inspect the resulting encryption configuration, the actual identity identifier, and the corresponding vault grant. Check an approved read/write workload afterward and retain the result. Record key identifiers and permissions, never secret key material, in the deployment evidence.\nOfficial references\nMicrosoft Learn: Configure Customer-Managed Keys for Azure Elastic SAN. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nA new Elastic SAN volume group using customer-managed keys requires a user-assigned identity. A system-assigned identity is not available before the group exists, so that identity can be configured for key access only afterward, with appropriate permissions.\n\nThe key vault must have both soft delete and purge protection enabled. These are prerequisites for the documented customer-managed-key configuration, not substitutes for granting the chosen identity access to the key. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys).\n\n## Applicability\n\nUse this review when deciding whether encryption is configured during creation or added to an existing volume group. Record the group, identity, vault, key, and selected key-version update method before adapting the source’s examples.\n\n## DSE recommendation\n\nDSE recommends making identity readiness a deployment prerequisite. Have the storage and key-vault owners agree which identity should retain access, then document the approved grant and its scope. Do not silently switch identity types to work around an authorization failure. Treat any later identity replacement as a separate change with dependency evidence.\n\n## Verification\n\nRehearse the chosen creation or update path in a nonproduction volume group. Inspect the resulting encryption configuration, the actual identity identifier, and the corresponding vault grant. Check an approved read/write workload afterward and retain the result. Record key identifiers and permissions, never secret key material, in the deployment evidence.\n\n## Official references\n\n[Microsoft Learn: Configure Customer-Managed Keys for Azure Elastic SAN](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys). Source retrieved September 9, 2026." } ] }